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.

In the vein of a few other threads, I've decided to start a thread that will cover the current progress of my FM mapping and serves for troubleshooting the issues I run into. While the newbie questions thread is a good place to seek advice, I often get the impression that it's not adequate to solve the perennial mistakes I seem to run into while trying to learn certain aspects of mapping. I'll gladly welcome any advice in this thread. Screenshots of what I'm currently working on coming soon.

Hi guys. This is my first post. I'm using DarkRadiant 2.0.2. I've run into a problem with Visportals or I'm doing something wrong. DarkRadiant seems to delete the brush I've made for Visportals after clicking on Make Visportal. Applying the Visportal texture also seems to delete the brush. I'm going to try the DarkRadiant 2.0.3 pre-build.