nbohr1more

I think your performance concerns are different than those seen by lowenz. That said, there is probably an argument to be made for using a slider in the GUI. One thing I've noticed is that some quality levels have better looking gradation patterns ( more evenly distributed, no banding between gradients ) thus setting 15 can look even better than one of the built-in settings like 26 ( 25 actually looks better than 26 and many of the higher values ). I only have a 1080P resolution display so I can't confirm whether this behavior holds true for other resolutions but it does seem to hold true for variations in renderscale.

Sorry if this sounds redundant but does changing r_softShadowsQuality change performance at all? ( Eg. Does r_softShadowsQuality 6 perform better than 12, 26, etc or do they all offer equally low performance ? )

I would remove that line. It was probably added out of caution to ensure that the correct area is referenced.

Here is an updated deftdm_cubeLights.mtr

script.zip Here is the latest script folder

This can potentially cause performance degradation if there are too many entities in a scene. We probably don't have up to date cost vs benefits metrics on this one so please test elsewhere and report your comparison findings. Edit: r_useEntityScissors is broken: https://bugs.thedarkmod.com/view.php?id=6099 These should still work but there may be some performance regressions due to scissor changes in 2.11. You are not seeing any benefits from either? This theoretically would improve cache coherency for multi-core rendering. @stgatilov evaluated it compared to our own design and considers the benefit to be dubious since we already have better VBO and SIMD accelerated portal optimizations that vanilla Doom 3 and BFG lack.

The only new performance impacting cvars are listed here: r_modelBvh* --- configures all BVH-related optimizations. r_modelBvhBuild is the "kill switch". r_softShadowsMipmaps --- enables the new bandwidth optimization for soft stencil shadows. For at least one AMD user, setting r_useDebugGroups 0 improved performance so that will be the default in the next build. To my knowledge, the multidraw options don't help much if you don't also have bindless textures ( removed in 2.11 due to AMD driver bugs ). Otherwise look here for options: https://wiki.thedarkmod.com/index.php?title=Performance_Tweaks I would suggest that: tdm_lg_interleave 6 tdm_lg_interleave_min 3 or some variant thereof might help. The trick is to try and tune it so that it roughly matches your game modelling tics and refresh rate. Usually values between 2 and 7 ( whatever feels the smoothest ) Just be aware that it may cause lag in the changes to light level shown in the lightgem. Also, if you enable Frontend Acceleration and want to handoff work to more cores, try experimenting with: jobs_numThreads

A few big changes occurred there. It looks like we didn't commit any binaries to SVN between these releases. Are you able to compile from source? If so, can you try compiling 10037 ( big shadow change )?

Psst! In the latest dev build try setting: r_useDebugGroups 0 This was set to 1 in dev16617-10107

I know it will be spammy but what do you get when you set r_debugGLSL 1 ?

Thanks! Please try Dev Build dev16599-10071

Hmm Try: float lcolmax = max(lightColor.r , max(lightColor.g , lightColor.b)) ; float diffusemax = max(params[var_DrawId].diffuseColor.r, max(params[var_DrawId].diffuseColor.g, params[var_DrawId].diffuseColor.b)); FragColor = min((vec4(lightColor * ssao * interactionColor.rgb, interactionColor.a)), ( lcolmax * diffusemax )); FragColor = max(FragColor, vec4(0));

Sure, but it never hurts to keep outputs clean. Presuming you are using r_useNewBackend 1 go to glprogs/stages/interaction/ interaction.ambient.fs.glsl and try replacing the FragColor line with: float lcolmax = max(lightColor.r , max(lightColor.g , lightColor.b)) ; float diffusemax = max(params[var_DrawId].diffuseColor.r, max(params[var_DrawId].diffuseColor.g, params[var_DrawId].diffuseColor.b)); FragColor = min((vec4(lightColor * ssao * interactionColor.rgb, interactionColor.a)), ( lcolmax * diffusemax ));

Probably need to clamp the shader output values somewhere.

Look below the "dev" section, there should be a beta section.

2.11 beta 01 is currently in the installer list. The thread about it will be out soon but you can test it now. That said, we need to bisect your performance problem by having you test older builds starting with 2.08

See: https://bugs.thedarkmod.com/view.php?id=6090 for the new definition design

@lowenz is that result from 2.08, 2.10 or 2.11 ? stgatilov wanted to see whether the same issue impacts 2.08 for comparison.

Yep, you can make things that are invisible when unlit but you must use a complex material that uses the diffuse stage as an input for a transparent stage. Original discussion here:

The id tech 4 design required the material def and the light material def to have the same spectrum number. The Dark Mod adds the ability to add a spectrum entity flag for both the light and entity.

The spectrum material flag and entity args already exist. No need for x-ray or anything new to achieve a UV light effect.

Yes, I set it before running the mission. I guess I should do my homework about setting up tracy profiling rather than eyeballing FPS. ( I still think the home-grown performance tool in 2.08 was very cool. )

https://www.thedarkmod.com/missiondetails/?internalName=chalice1_1 It's "Thief's Den 2: Chalice of Kings"

Probably not all that useful but in my testing "r_modelBvhBuild 0" did not make the above scene any faster, only Frontend Acceleration helped with performance. I probably have different bottle-necks with a GTX 1050 and an i7-3xxx CPU.