Search the Community

Felt I should post this here before the bug tracker so I can properly explain the limitation and the solution I'm suggesting. I'd love to hear what @stgatilov @Dragofer @nbohr1more and other developers experienced with the graphics system think about this. I'm making extensive use of the building modules since they look amazing, but they can also be quite a drain on performance even when using their LOD models. I noticed a reason for wasted FPS is that often times interior modules will poke into exterior areas, likewise exterior walls may still be rendered out of sight when the player is inside a building. This happens because with their intended alignment the bounding boxes of some models may poke through the brush wall: The rule is that if an entity's bounding box touches a visleaf open to the player it will be rendered, which in this case causes walls and pillars the player can't see to still be processed by the GPU. The screenshot below is from a camera position that's inside the building and past the (shadow)caulk wall but just behind the interior panel, as can be seen the module of the exterior wall is still being rendered from the visleaf of the enclosed room. I asked if there's a way to solve this and was reminded of the areaLock spawnarg which is a powerful concept: It allows restricting an entity so it only renders in the visleaf its center or origin is located in. I gave it a try on the FM I'm working on: Using "areaLock center" or "areaLock origin" on the exterior modules will prevent them from being rendered inside as intended, the outer wall in the above image no longer shows up when peeking behind the inner panel. The problem then becomes that if a module touches more than one visleaf, it will be cut off and disappear from any area its center isn't located in. To resolve this I'd like to suggest a new option for AreaLock or a new spawnarg to complement it: Allow specifying a list of areas defined by their location info, meaning an entity will only be rendered inside every visleaf that's part of that location but nowhere else. This should allow binding exterior walls to the outside and interior walls to the inside, without relying on random chance based on where the bounding box or origin of each particular model falls. Mappers should then be encouraged to use them for all building modules, given there's no way to prevent some of them from poking through solid walls and being rendered on the other side, this can result in a significant performance loss in open areas with many lights and lots of module walls seen at once. Eager to hear what others think and if this solution is possible or maybe there's an even better way.

I recently saw a post about the functionality of the idTech 6 engine, which brought this suggestion to my attention. It's actually a simple and trivial improvement, although I can imagine people missing it and not thinking about its absence. Also keep in mind I don't know the lighting code of TDM, and everything I say is purely out of observation. Like most engines that use dynamic lighting, TDM tends to have considerable performance issues when a lot of lights are rendered at once. This is often because of shadows and possibly other calculations. A common way to prevent extra computation in the renderer is caching all lights, and only updating each one when necessary. Meaning either the light itself has moved, or something is moving in front of the light. If both the light and the geometry it affects are static, there is nothing to recalculate, which offers a significant performance boost. TDM has a serious problem here: Even if the engine already knows how to cache lights, every torch has a moving light source! If you look closely at a torch, you'll notice its shadows constantly bob around. While this makes sense aesthetically, it also means that light will be recalculated each frame... even if the torch is mounted on a wall and no physical object or NPC is currently moving within its radius. Since most maps use torches and have areas where characters don't walk in front of them, I see a notable performance improvement being lost here. My personal suggestion: First of all, does idTech 4 support light caching for static lights + geometry to begin with? If somehow the original engine didn't have that, I definitely think it should be patched in! Once that's solved, I believe moving light sources for flame based lights should be controlled by a cvar; If people are okay with the performance loss, they can enable that to get bobbing shadows... if not, disable to allow torch lights to be cached and improve overall FPS. An idea to compensate for the visual loss: Can't we use an animated light texture to simulate moving flames altogether, as well as pulsating brightness? The light bobbing looks pretty extreme anyway: In real life, candles have a smooth flame that casts a neat shadow, and shadows don't always move that chaotically even when it's a noisier flame like a campfire.

Basically I'm curious who is aware of LOD models in TDM. If you guys realize we have them. If so, do you use them? Do you know where they are? Can we find a better way to manage them so authors can use them easily?