HMart

Ok

Hum that just means the current implementation does not support occlusion, what would happen if you put a object in front of the beam? something like this

with this settings r_testARBPrograms 1 r_shadows 2 r_softShadowsQuality 32 r_softShadowsRadius 5 // this controls shadow blurriness and at 11 like i add before it can cause shadows to almost disappear. r_shadowMapSize 1024 Shadow maps look good enough to me and performance is much better, where i add 26fps before now i got 55+fps. Btw I forgot to test this right now but i think you guys need to debug changing shadows at run time, on my last test when changing from stencil to shadow maps, some shadows vanished, perhaps caused by the high r_softShadowsRadius, but when returning to stencil, r_shadows 1, those shadows didn't return?! Perhaps it didn't changed to stencil like it was supposed to and i thought it did? But if so that would mean r_shadows 1 didn't worked.

Nice work guys but some things i saw on my first test. on a AMD RX 570 Mission Volta and the stone 1 playing on a window not fullscreen. The light gem seems to be always bright even when on total shadow! Shadow maps work but they look very pixelated unless you use r_softShadowsRadius 10 but even so they still don't look the best they can be, right now TDM soft stencil shadows do look much better. Shadows very near to the edge casting it shimmer like crazy, the efect is like a moving staircase going up and down, specially when using the player light. This microsoft paper explain many of the things i saw https://docs.microsoft.com/en-us/windows/desktop/dxtecharts/common-techniques-to-improve-shadow-depth-maps Some objects casting stencil shadows stop doing so when changing to shadow maps this doesn't seem right. Performance seems to be high on shadow maps but perhaps it could be caused by the missing shadows above. All Grass/plants, that i saw don't cast any shadow when using shadow maps, it must be the "noshadow" material keyword causing trouble. This was mostly what caught my eye in this rapid test, will test better later. But i'm happy with how this is going, is so good seeing you guys motivated to improve the engine and TDM further. Wait a minute will test that and i will update this... update: playing at 1080p r_testARBPrograms 1 r_shadows 2 r_softShadowsQuality 32 r_softShadowsRadius 11 r_shadowMapSize 2048 Shadow maps look AWESOME performance low has 26 fps in some views Returning to r_shadows 1 Missing shadows are still missing!? performance always at 60 fps (frame rate locked), it seems that for shadow maps to perform has good has soft stencil shadows they need to look worse, .

If you are still thinking about this, you could make a stone block and apply a normal mapped or even better parallax occlusion mapped image of a neptune into it, it will not look has good has a real 3D statue but at least you will have some kind of "sculpture" of him there. It has the potential to look bad tho if the normal map is not of suficient quality. Something like this:

Like others have said no you don't need to know programing to make TDM missions (it does help you make more complex gameplay tho), many stuff can be done just by linking func_entities/triggers around in DR, or by using the stem&response system unique to TDM. About importing static models is like Judith said, but for .lwo models you don't need to edit the file (you also can't easely is a binary format). About animated .md5 models this can be of some help, even if is for a older version of 3Dmax, using older exporter and techniques for rigging, but the export/import for TDM idtech 4 is mostly unchanged: https://www.youtube.com/watch?v=vD1IxSAYRkA Exporting .md5 from Blender is also possible and afaik the modern .md5 exporters are for it but don't take my word, I only know for certain that Doom 3 original 3DMax and Maya exporters are for older versions. In blender depending on the exporter used some things change, for example the exporter i use, that was kindly given by the ( now defunct ) arx end of sun team, requires that bones selected for exporting into the engine, be copied into layer 5, all other extra bones, those used on the rig to facilitate animating, CANNOT exist in layer 5. They made this so you could have two rigs, one complex rig with many helper gismos used only for animation and another simpler rig with the main bones only on layer 5, then you just transfer/remap the animation rig movements into the slimper rig and export, this is not a requirement tho.

Man that was fast and is a nice start! Now if i may, you could make it so the effect is stronger near the flame and gets softer as it gets way and perhaps implement some faint lens flares effect (optional) and imo it will be perfect! https://1yearframes.files.wordpress.com/2011/03/1084_candle-light.jpg minus the lens flare. Btw sorry for the physics lesson but because duzenko "asked", light halos is not 100% caused by volumetric lighting but some of it is, light halos or flares are also caused by light refracting inside your eye's, and spooks imo sun shafts or god rays is volumetric lighting, at least in real life it is, they are caused by the same thing, light dispersing around and illuminating small particulates (dust, ice, etc) in the air. The always "trustworthy" wikipedia... ;P https://en.wikipedia.org/wiki/Volumetric_lighting

Yes deform flare is the most important part and a requirement for the effect, and i know that the parameter afterwards specifies the flare size, i only refereed about _quadratic because even tho some don't use this keyword has a map, the majority of the Doom 3 flare materials do, so to me it indicated that was a important part in the overall look of the effect but not a required one.

Yes a shader is a good idea, making a post process Bloom shader seems the best bet, in that way level designers don't need to make special geometry or materials for it, just make the texture bright and the Bloom shader does the rest. https://learnopengl.com/Advanced-Lighting/Bloom About Storm Engine 2, is based on RBDoom3 BFG so supports full 64 bits HDR lighting and its Bloom features, TDM on the other end is based on the original idtech 4 engine so can't do the same things, but now that custom shaders are possible a HDR (faked) shader is not out of the question... ;P But duzenko already has other shaders to worry about, better not pestering him with many shader requests. ;D

That bigger glow can be faked using the idtech 4 "flare" material, but is really not a post process Bloom shader like UDK is just a material trick, there's many different types of flares materials in Doom 3 because of that. Here is a example textures/sfx/flare2 { noshadows translucent nonsolid deform flare ( 16 + parm4 ) qer_editorimage textures/editor/flare.tga { blend add map _quadratic colored vertexcolor } } Almost all Doom 3 flares have "_quadratic" has the map, so that must be important for the desired effect.

Yes if TDM GLSL version supports those features but i'm sure is not a matter of copy pasting the shader code from shader toy, it needs to be reworked to support TDM engine particularities like lighting, geometry, etc. About shaders one that i would love TDM to have some day is volumetric lighting. https://www.shadertoy.com/view/4dsGRn

Spooks I wouldn't worry about that, like i said a single shader can have many different outcomes, depending on the inputs giving, so it doesn't matter if mission makers don't write new ones. But i'm sure someone will, just having the ability to write or use custom shaders is very good, especially now in GLSL because is like coding in C and there's plenty of examples on the internet. This opens the door to many new possibilities just look to this site shader Toy.

No not normally, but believe it or not, in all honesty I did knew those fragmentMaps calls were texture calls, I've used ARB/GLSL shaders before, i was just telling you what he asked has you didn't understood the question. To be fair to Spooks, making materials that call a shader is not something that a person working with idtech 4 do all the time so anyone could make his mistake. Btw Spooks about shader flexibility, depending on the shader it can have plenty of flexibility, you obviously can't modify the shader code itself through a material call, but by changing the input, you change the outcome of the shader, so with one shader you can have many materials with different looks and behaviors. For example the heatHaze shader, it's used to make glass, water, heat waves for explosions and fire, etc.

I think he is asking if using a shader that calls many materials is really faster than using a normal material with multiple stages.

In my case for TDM both gamma and brightness are at 1.

I use Modo most of the time but I don't stay away from Blender, specially when it has good animation/md5 support for idtech 4 and it's free and powerful. IMO the only reason to stay with 3DMax, even Modo, Maya, Lightwave, etc is like on your case and mine, we just don't want to start from scratch and learn a new tool, we got accustomed to them (Modo is changing so much that is almost a new tool tho) but anyone starting modeling now, in my humble opinion, is pretty much dumb going to any of the paid tools, i love Modo and i would be sad if it died one day (it was close) but i'm also a realist, when Blender does exactly the same thing for free and the interface is miles better than it was before and improving all the time, is becoming very hard to justify Modos price. Specially when you have low cash and want to create a film studio, with Blender you can have anyone use it and not pay a dime, with the others, depending on contracts you could end to have to pay a fee/licence for every artist using the tool at your company.

Could it be the shadow mapping code not being handled by invisible dev materials and so a invisible brush is casting a shadow? This would mean that many more brushes using such materials would have this bug tho.

Very sad to know that, i hope he still stays around even if not on a dev role.

Currently, using stencil shadows the only way for textures with transparent parts (alpha), to "cast" shadows, is to use shadow/light projectors, for that you need to create a extra texture that is meant to simulate the shadow that will be, projected, that is how those small rotating fans are made in Doom 3 for example, with shadow maps, you remove this extra steep, the shadow is automatically created for you, for everything. Here is a example in fhdoom: with stencil shadows https://github.com/eXistence/fhDOOM/blob/master/doc/screenshots/shadowmapping1_off.jpg?raw=true With shadow maps https://github.com/eXistence/fhDOOM/blob/master/doc/screenshots/shadowmapping1_on.jpg?raw=true

Imo you have plenty, they just don't cast shadows now or they are faked with projectors. Any texture with alpha will be a potential "transparent" shadow casting entity, for example trees canopies will be able to cast shadows on the floor, small bushes/plants has well, a grate texture in a flat plane will be able to cast shadows now with no need to use fake projectors or real geometry, etc.

No problem, but you can also "paint" textures into textures on blender not only colors. Also normal maps or bump maps

Vulkan does reduce the draw calls more than modern OpenGL ever could, but you are right modern OpenGL could be a viable option, this does mean that users will need at least DX11 GPUs, dx9 users will need to update. If TDM engine is still using old ARB shaders then imo the priority should be to change those with GLSL versions indeed, i was under the impression that was already done. I never used SEED so i can't really comment on it, but what i'm talking about is something like this, http://blog.wolfire.com/2010/10/Imposters. This would be a system that could come after the terrain system for example.

The only way TDM engine will have improved physics, is if someone totally reworks the included physics engine, i assume not a easy task, or implements a totally new physics engine, personally i would recommend Newton Game Dynamics the same physics engine used in all Frictional Games, games, from what i heard is more accurate and stable than Havok, PhysX or Bullet the later ones are made for quantity not accuracy. Vulkan is now a real possibility, because there's already a oficial vulkan renderer for idtech 4 and is also, one of the greatest possibilities to improve mission complexity, because of the massive savings on draw calls but for that to happen vulkan needs to be the only API available for TDM, if OpenGL is still a option, missions will need to be made thinking on it and so limited in scope has always. Vulkan does need modern dx12 GPUs so before making so radical change, a survey of the community would need to be done to see how many are still on dx11 and dx9 GPUs. Imo forget raytracing, unless you are using hybrid raytracing like D3D12 raytracing or RTX, normal raytracing is impractical for real time games, and from the look of things performance of RTX is not that impressive taking into account the price and power of the GPUs presented. In the near future i would just implement stuff that is already included in some fork's of idtech 4. True 64 bit HDR lighting with adaptive filmic tone mapping and gamma-correct rendering in linear RGB space. (is not the same has bloom). Enhanced Subpixel Morphological Antialiasing Half-Lambert lighting and rim lighting (used for characters in HL2) Shadow maps only or Shadow maps along side the stencil shadows, i mean the ability to use both at the same time, so you can have alpha textures cast shadows even tho you still want to use exclusively soft stencil shadows for the rest. Parallax occlusion mapping (is this not available already in TDM?) SSAO and SSIL - ssao (screen space ambient occlusion) and ssil (screen space indirect lighting) In the future if possible: Light Rays/Light Shafts Dynamic liquid surfaces (remember FEAR water?) Volumetric particles, ability for shadows to cast unto particles in the air. Terrain system Vegetation system PBR - Physical Based Rendering

Nvidia being Nvidia. RTX logo in games doesn't mean they have ray tracing, even tho "R" is on the name and they "failed" to mention that in the initial presentation.

Would love too but please don't take this bad, I don't think there's a need for me to make a video tutorial for that, . I assume you know how to select decal/patch's in DR and export the selection has a .obj? I also assume you know how to import models into blender? I also assume you know how to make TDM materials and copy paste the material name (for example textures/texturefoldername/materialname) into the material name in blender and export models out of Blender into DR/TDM? If so only remains knowing how to texture paint in blender, for that this video is very helpful and imo i wouldn't make better.