nbohr1more

It looks like the auto-generated rotation hack models aren't loading. Try deleting and re-installing the FM. Make sure that TDM has read \ write permissions in the folder where it's deployed.

Well, here is the reference anyway: https://docs.microsoft.com/en-us/windows/win32/direct3d10/d3d10-graphics-programming-guide-resources-block-compression

Ouch. Yeah, probably not worth it for whatever quality uptick you supposedly get.

@OrbWeaver can you also add "GL_COMPRESSED_SIGNED_RG_RGTC2" import support? According to Microsoft the signed format is better suited for normals?

Can you try the latest SVN? Orbweaver commited a fixed BC5 loader

I believe that the current design works like: image_useNormalmapCompression 0 Image is loaded uncompressed, environmental variable is passed to glprogs, GLSL standard branch renders shader image_useNormalmapCompression 1 ( default ) Image is compress on load, environmental variable is passed to glprogs, GLSL RGTC branch renders the shader The open question is: What happens if the cvar is set to 1 and the texture is already compressed? If the detection code bypasses the attempt to compress the image or the compressor recognizes the image as matching the desired destination format the the shader should do it's job since the correct branch is activated

Isn't that what r_shadowMapSinglePass 2 currently does for normal lights? Maybe create a cvar that does the same but only for ambient lights?

OK, sorry to be a pain but I did ponder one other sort of ugly use-case. The mission "Sir Talbot's Collatoral" uses many small and subtle lights referred to as "bounce lights" to improve the look of ambient lit areas. If some author went crazy with this lighting method, performance could be very bad in a large open area such as a warehouse, courtyard or foyer. Turning off these bounce lights at a distance would be far less noticeable since they only add subtle effect anyway.

A little "No Honor Among Thieves" v4 preview. Not too revealing. See if you can spot the new texture I created...

Sorry, forgot one critical edit. Still this answer makes sense. Doom 3 is a fillrate monster and continues to be one in the TDM engine era.

In all previous Doom 3 discussions, one of the main areas of concern was that this renderer is "not deferred" meaning that regardless of whether the entities are visible the engine will attempt to render them. This means that if a light touches entities that are obstructed by geometry but are not culled via visportal then the engine will perform all the setup of all that unseen geometry. This is generally offered as one explanation for why a scene with good visportal design performs dramatically better than one with no visportals that is visually identical. So? Of course we would wish that all maps have perfect visportal design but even if this comes true what about the case where shadow casters exist behind obstructive geometry? As I recall, vanilla Doom 3 treats lights as having possibly infinite shadow casting range ( I believe Doom 3 BFG constrains the potential shadowed area to the light volume cube ). This means that many shadows that are invisible but extend away from the player behind an occluder can consume resources. It has been said that there is no "solution" to shadows behind occluders since there is the potential for incorrect shading on the unobstructed sides behind the occluder but I would offer that mappers might want to try that tradeoff? Especially if the difference is a negligible sliver of light or shadow being removed. ( See a previous discussion about some mappers wanting "antiportals" \ "func_occluder" entities. ) Does this make sense? Of course, Shadow Maps also play a part in removing some of these factors but since shadow map mode is still hybrid the stencil shadow concerns still arise.

To be clear, it is my understanding that lights still perform the following actions: 1. If a light is visible in the view frustum, visleaf, portal view, and scissor calculations 2. Gather all vertex data within the bounding box of the light 3. Skin all vertices gathered in step 2 ( expensive CPU wise ) 4. Upload all skinned triangles to the GPU ( expensive regarding bus data ) 5. Fill pixels for all triangles uploaded in step 4 via a depth pass 6. Calculate object silhouettes on the CPU 7. Extrude the shadow vertices on the GPU 8. Fill the stencil buffer 9. Fill the pixels that are now visible after steps 1 through 8 via the light shader If so, it is your assertion that step 9 is more expensive that steps 3, 4, 5, 6, 7, 8 ?

WOO!!! @Dragofer can you test BC5 normal maps again?

NHAT v4 - Beta 1 - Release Candidate 1 Onedrive: https://1drv.ms/u/s!AuwAFc1gTZzehnrmnPd2SDsHvKVi?e=umPMcb Googledrive: https://drive.google.com/file/d/1285hUOqgKNW96JaQ7MXK59GNs-sDFsOs/view?usp=sharing

We have seen a few mappers optimize lighting performance by creating distance triggers to toggle them off. One thing that legitimately begs for this capability is in the case where light bounding boxes expand beyond the visleaf they are assigned to but do not contribute to lighting in the unintended area. Though this is what the areaLocked keyword is for? Using hide_distance would make this easier than the triggers or scripts currently used for this at least. I think the general objection to this is that mappers could easily make ugly light toggling in the distance. I believe Tels made a demo where he faded lights in\out based on distance and this would also look better than a hide_distance option. His design shrunk the light volume to zero after fading the projection image colors as I recall.