renderer Support AreaLock based on location info, solution to cull building modules poking through walls and being rendered when hidden

[MirceaKitsune]

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.

[stgatilov]

Maybe we can invent something more reliable than recommending mappers to assign entities to areas manually?

[MirceaKitsune]

Sure, I'm open for the best solution of course. I suggested an upgrade to AreaLock as it's the only system we already have that culls models based on visleaf: A solution would likely have similar results though it doesn't need to be implemented the same way.

Merely binding to a location info seems like the simplest way. Though we should probably use a separate ID not the location info directly, that way entities aren't restricted to one outdoor area else you can't have location separators in between buildings: The "info_location" would have a spawnarg of the form "show_area the_outside" then any entity can also be given "show_area the_outside" to bind it to that zone.

An alternative would be to trace the path taken by the origin / center through open portals touching the bounding box, similar to how lights are optimized as to not needlessly calculate surfaces from rooms they intersect but can't shine in. An "areaLock center_trace" or "areaLock origin_trace" would allow the model to be rendered only in visleafs the origin / center can travel to through open doors. The advantage is we can probably reuse the same code as light optimization, also the mapper doesn't need to define areas manually... the disadvantage is this offers less control, the origin of a model or the center of its bounding box may fall in the visleaf you want to hide.

[stgatilov]

Maybe we can try what I proposed in the other thread: a flag which says "this model is continuous and cannot pierce area
boundaries".

Anyway, I don't really know how the modules are organized.
Is every module a wall which is only visible on one side?

[MirceaKitsune]

18 hours ago, stgatilov said:

Maybe we can try what I proposed in the other thread: a flag which says "this model is continuous and cannot pierce area
boundaries".

Anyway, I don't really know how the modules are organized.
Is every module a wall which is only visible on one side?

The question then becomes: Which is the model's intended area and which is the pierced area? The existing AreaLock lets you determine using either the model's origin or the center of its bounding box. In my tests I found both may fail at detecting the intended area in a few cases.

One reason is the answer to the second question: Most modules are walls, but others are corner pillars which are even more problematic. On the outside you need to line them up so the edges of two wall panels don't show up, which almost always requires pushing them inside a room. This image shows it clearly if I hide the interior walls... note how the pillar's origin also falls inside the room in this case.

The wall brush is 4 units thin which is very small but what I found works; Some would ask why I don't just make the walls thicker which would technically solve the problem. The issue then is you can't get the exterior modules to line up with the interior ones, they're meant to be placed back-to-back. Only way is to make unrealistically thick walls so you skip an entire panel, meaning a wall would have 5 panels on the outside but 4 on the inside positioned midway: One panel is usually is 128 units long, for modules that offer a half-wall 64... for them to line up you need your walls to be 64 or at best 32 units thick which looks like it's over 1 / 0.5 meters, that's a lot of space to waste and only makes sense for something like a castle or giant cathedral.

Even then it won't work as the door frame of an interior module needs to poke through the exterior so you don't see a gap: The modules include their own door frames and expect you to use those instead of adding your own. The interior and exterior door panels need to slide into each other perfectly like a socket in a power outlet; If the door panel of the outside isn't glued to the one of the inside just right, you'll get an empty space in which you see caulk where the door sits in the door frame.

The second image also shows the problem with center detection: The door frame that must poke out belongs to the indoor panel, and it's long enough to cause its bounding box to be present outside the room more than it is inside. If I use the model's origin then it works, but for a few modules the origin of an interior panel may be flipped and lands outside. Modules with door and window frames are the only ones that need to render both inside and out, everything else should be restricted to its intended area.

Edited December 8, 2024 by MirceaKitsune

[stgatilov]

Ok, let's suppose we only consider wall modules which should be rendered on one side only.
Are they provided together with brushes which are supposed to seal the area?

If they are just the models, wouldn't it be risky to force some specific engine optimization on them?
You probably think they are always used as proper walls, but other people might think differently.
Also my experience with portal diagnostics shows that occasional mapping errors are quite inevitable.

[MirceaKitsune]

The building modules don't come with any prefabs to my knowledge: You need to guess how they're supposed to be used. It actually took me some experimenting to figure out how they're meant to fit together, when I first learned them I had to try many different wall sizes. They're quite beautiful but issues were made in their designing: Many don't have a proper origin and got bad offsets, which would be risky to fix now since existing FM's are already using them and could end up broken.

In my case I know how they're supposed to be used. At least the way I configure them on my maps, the answer may not be universal for everyone. Which is why it should be a well designed spawnarg for mappers that know what they're doing when they're certain they need it.

In the cases above I know I don't need the exterior wall to show from an enclosed room, it's never possible to see and only wastes precious performance. I actually discovered this by accident while noclipping and peeking behind the interior panels, even if I knew the bounding boxes may poke through the walls at times.