stgatilov

I added cvars for tuning BVH code in runtime: modelBvhShadowsGranularity modelBvhLightTrisGranularity Meshes with size less than X are now processed using the old non-BVH algorithm, so if you set it to huge value, you'll get non-BVH performance (well, almost). Also it limits how much BVH traversal recurses into its subnodes. However, I did not get much difference from tuning them. Also, I have optimized the shadow volume generation algorithm with BVH. Now it should be somewhat faster than before. However, don't expect it to reach full non-BVH speed. The non-BVH algorithm is much simpler (thus less overhead) than BVH-using algorithm, and also it can avoid computing some quantities several times thanks to the fact it always processes all triangles + vertices. So, some slowdown here is the price to pay.

I think reevaluation happens more frequently than on modification... like on every frame maybe. As long as the behavior is the same, I'd not care about the exact way. Maybe updates depend on visible or notime, not sure.

I hope you did set the cvar before starting mission? Just to make sure... because otherise it did not apply. Anyway, it is indeed possible. Locally, I don't see much difference, but I see that shadow computation takes too much, and it seems to take about 1 ms less (out of 14ms) without BVH. I think I'll make BVH shadow computations more coarse, and hopefully it will help.

Map authors are not the authority to decide on optimizations to enable, unless it is behavior-specific We can try to tweak BVH, but I think the results will be scene-specific. It is possible to change leaf size. Also, it might be worthwhile to disable BVH for small meshes.

It uses BVH culling, which is way faster on large meshes:

"Frontend acceleration" causes this work to be done on separate threads, where it no longer matters how long it takes (unless you have a 2-core CPU).

What about "r_modelBvhBuild 0" before starting mission? This cvar is non-archivable, and it takes effect on loading models.

What about "r_softShadowsMipmaps 0"?

Fixed this issue. I added r_volumetricDustMultiplier in slightly different way. Adding cvar is not a big problem, but adding it to the menu would require many people to request that. I admit factor = 0.5 on Hazard Pay looks like what I expected volumetrics to be when I initially worked on them

@Daft Mugi, please test the latest source code SVN. I fixed color banding issue and bumped default number of samples. Of course, shadow maps are still as bad as they where, and you won't get less work for you GPU, but I hope most of artifacts in volumetrics themselves are gone now. By the way, you can further reduce GPU load by setting "r_volumetricLowres 2", which would mean rendering volumetrics and quarter-resolution. You might get more blurry or messy look, but it should be noticeably cheaper.

The story about volumetric lights and stencil shadows is rather messy. Initially, we did not force lights with volumetrics from stencil to shadows. As the result, with stencil shadows volumetrics simply passed through all obstacles. And several mappers were disappointed by that, saying that volumetrics leaking through stuff has bad consequences for gameplay. Then we changed the behavior: if player uses stencil shadows, then volumetrics are simply disabled. But since it many cases (especially where old-school transparent geometry was used) shadows are not necessary, we added a way for a mapper to mark volumetric light as "using shadows in volumetrics not required". As the result, mapper could make some volumetrics work even with stencil shadows. Of course, this markup is not very popular, but the particular light that you found most likely has it. Then after 2.10 we implemented a force-switch from stencil shadows to shadow maps for the lights with volumetrics. At this moment, the markup is probably not necessary. The cvar "r_volumetricEnable 0" simply removes all kind of volumetrics without second thought. So in this case volumetric light was used, but it worked with stencil shadows because mapper allowed it drop shadows completely.

Why do you think so? Apple deprecated OpenGL but never removed it. I think they still support 4.1, which is enough for TDM currently. Actually, I'd second the question: can you run TDM on Wine or one of its variants? I think we are speaking about running x86 Wine + x64 TDM with Rosetta translation.

I added a cvar r_volumetricEnable. Note that you should run reloadModels after changing this cvar, just like you need when you change r_shadows. It seems that you don't like shadow maps in general These are the typical pixelization artefacts which I also hate in shadow maps. When there are too many shadow-mapping lights being rendered, some lights are automatically switched to lower resolution, which makes the issue even worse. And one way to somewhat mask this problem is to use soft shadow maps... which are very expensive in TDM right now. Ideally, we should render shadow map with low resolution, then render stencil shadows as usual and use them for shadowing, but use shadow maps for volumetrics. But I'm not sure having both implementations of shadows fits the renderer architecture, unfortunately. This is not noticeable in a still screenshot, but I found this location and I see the problem. I have found a similar case at 3986.7 2463.3 -222.85. I guess I should look into it. It looks like color banding, because volumetrics are computed in 8-bit FBO. I knew about this problem, but it did not look so bad on testmap, and I thought maybe I could ignore it. But in Hazard Pay, there are many places where color banding is strong. I can "simply bump" FBO to 16 bits, doubling memory bandwidth, or adding dithering... I wonder if there is another option. When I flew around this map, the brightness of security cameras looked over-the-top for me too. But now that I look at the map, it seems that volumetric_dust is set to default here. @Dragofer, maybe we should tone down security cameras by default?... Of course, this issue is greatly magnified by gamma-incorrect rendering pipeline, so when several light sources overlap, their brightness gets much larger than just their sum. Not fixable right now I can't understand how a game can be blamed for increased power consumption. Loud noise... probably means that this particular piece of hardware has bad fans. But I agree that this is a sign of greater performance cost in general, which can lower FPS for you in other cases, or for other people. I guess you need to do reloadModels, since this cvar changed shadows model of some lights. It looks like your GPU increases power consumption when you increase memory bandwidth. Computations don't matter that much. It's no wonder you see no performance drop: you have 60 FPS cap. Given that now volumetrics are rendered at half-resolution, number of samples per pixel does not affect performance so badly. Maybe I should just bump them to e.g. 24, I don't know.

I think none of them are correct in 2.11 and all will produce a warning. To be honest, it's better to test if you want to know that level of detail. For the sake of tutorial, the only way that should be advertised is: float <user_variable> 0 <property> 0 This is what Doom 3 expected, and it works reliably both in Doom 3 and all versions of TDM without warning. All the other syntax is playing with fire, and people should not know about it

Yes, with new changes you can hold Creep button, and you'll surely get not sound from moving/rotating an item. And I recall I added a cvar to configure whether this happens always, on walk, on creep, or never.

Yeah, my reaction is directed not towards you, but towards the original author of Doom 3 GUI engine. I won't mind. Perhaps the third thing, along with calling named event and runScript command. https://bugs.thedarkmod.com/view.php?id=6164

Good story, but it does not explain why they copy/pasted the whole section of C++ code instead of adding second string comparison with OR operator in the condition for the existing section.

Does any version of TDM run properly for you? Like 2.08 for instance?

Radeon 3000 is TeraScale 1 architecture. While it technically supports the required OpenGL version 3.3, nobody has made it run recent TDM thus far. I think @duzenko even got such a card and tried to understand what's going on, but to no avail. The only option is to use older version of TDM (and thus better run older FMs too).

Yes, now volumetric lights with shadows by default force shadow maps, but for the lights with volumetrics only. If you find it surprising, you should recall that some lights (parallel and large ones) are always forced to stencil shadows, even if you choose shadow maps in the menu. It has been working like that since the very beginning of shadow maps in 2.06.

@lowenz, could you explain when the issue started happening?

I extracted @lowenz story about performance into separate thread. I think we also have @Araneidae and @MirceaKitsune with issues around stencil shadows and probably screenshots. @Araneidae, do you still have the problem on the latest build?

I still don't understand where is the problem. What else you can try: r_softShadowsMipmaps 0: the new optimization for soft stencil shadows uses more memory, and in some cases might even be slower. r_volumetricForceShadowMaps 0: this flag is for the change where lights with volumetrics are switched to shadow maps even if you have stencil shadows selected. r_shadowMapSize 512: this means using 2x lower resolution for shadow maps. Shadow maps take quite a lot of memory (144 MB at defaults) and fillrate, so lowering it down might help.

Yeah, there are indeed some. It's nowhere possible to make it pixel-perfect and cheap today. The new volumetric shadows are expected to be faster than ones in 2.10. If you have severe performance degradation (e.g. measured with uncapped FPS and max FPS set to 500), we'd better find out at least approximately where it starts and what causes it. I bet some maps like Hazard Pay will look very wrong if you just disable the volumetrics. You can go to 2.10 state with: "r_volumetricLowres 0" and "r_volumetricBlur 0". Did you try setting "r_volumetricSamples 0" ? That should disable expensive sampling: without it the effect would be very cheap.

The volumetrics code is vastly expanded in the latest dev build. They are blurred, and rendered on half resolution. As the result, the annoying pattern is not visible anymore, and the effect is cheaper in terms of GPU work. Enjoy