Use of areaLock spawnarg

[Frost_Salamander]

Creating a new thread for this as it was being discussed in an old beta-testing thread starting here: https://forums.thedarkmod.com/index.php?/topic/21822-beta-testing-high-expectations/&do=findComment&comment=490751

I suppose the main questions are:

• when should this spawnarg be used, if at all?
• why was it introduced in the first place?
• Can we get it documented properly on the Wiki so misuse isn't propagated?

@stgatilov @Dragofer

 

[MirceaKitsune]

Seems no one's answered this yet. There's a section about it on the wiki page:

https://wiki.thedarkmod.com/index.php?title=Performance:_Essential_Must-Knows#AreaLock_(New_in_2.08)

Essentially it makes a model only render in the visleaf (visportal area) its origin or bounding box center is located in. This is an useful tool to improve performance, by ensuring a model or a light doesn't render through a wall when you don't want it to.

I was trying to use it on building modules to improve FPS which is how I found this thread. Sadly there are some limitations that don't allow customizing it as needed currently. I made a thread explaining the problem here:

 

Edited December 5, 2024 by MirceaKitsune

[Frost_Salamander]

Yeah I'm aware of the use cases - I mainly used it for particles and preventing models from showing up through walls.  The point of the thread was to reveal why it was even created, as the thread I linked contains advice from @stgatilov to NOT use it at all: https://forums.thedarkmod.com/index.php?/topic/21822-beta-testing-high-expectations/page/10/#findComment-490707

If that's the advice, an explanation is needed and the Wiki updated.

 

[peter_spy]

IMO it's more like a last resort kind of thing. Like with using LODs for lights – if you have your models and LODs set up well, you'll never really need it.

[MirceaKitsune]

areaLock should definitely not be used on anything that moves, unless it's something like a func_bobbing or func_rotating that never exits its visleaf: On things like AI it would cause them to get cut off whenever they cross through a visportal, since the model will only show in the vis area its center is located in at that moment.

From what I'm seeing you only need to use it if you have a model / light / particle poking through a wall and know you don't need it to show on the other side of that wall. It's why I want it for building modules: As my thread explains they often poke through structural walls and you have exterior panels rendering from an enclosed room or vice-versa, however using the current implementation causes exterior panels to also not render outside if they cross a visportal between two buildings, hence my suggestion to allow area-locking based on location info too.

[stgatilov]

areaLock can be used for the sake of performance optimization, if you dare.

It was introduced because the engine detects which areas an entity/light belongs to conservatively. The good news is: the engine never fails in this regard. The bad news is: sometimes it puts an object to an area it does not intersect, resulting in more draws.

Of course, you should only apply this to static objects which cannot move.
Also I'd say better don't apply it to lights.
In my opinion the optimization is optional and can be disabled in the future, so you should not use it to change visual behavior. But people do, unfortunately

The main problem with cvar is that it is sometimes rather hard for a human to be sure an object does not poke into other areas. So occasionally we get bugs which are caused by the usage of this optimization. The bugs look suspiciously similar to culling bugs in the engine, which means I have to inspect them myself (since I changed culling code a lot).

Another theoretical issue is that the optimization heavily depends on how dmap produces area/portal graph. As you know, dmap is not very reliable thing There were already many changes to how dmap operates, some of them changed how mission is broken into areas. Such changes can break areaLock-optimized missions.

It was added by @Dragofer for outdoors optimization of his mission. And I am the one who opposes its popularization in the masses.

P.S. I had some ideas about how to improve areas detection in the engine, but most of them eventually stopped. Because I wanted them to work implicitly in 100% of the cases, but it did not work out.

For example, for a solid and connected object it is possible to check that bounding box does not cover visportals. If it does not, then it must be fully within one area and we can do areaLock automatically. That's because if it belongs to two areas, then you can trace a path along its surface which crosses area boundary outside visportals --- basically, the object intersects a wall.

The problem is how to detect which objects are solid and connected.
This optimization could be applied to moveables, but certainly not to particles: particles can punch through walls by design.

[peter_spy]

Shouldn't mappers be able to solve 99% of such problems with either LOD (hide_distance) or func_portals (either with triggers, or portal_dist + func_statics, if they want to cover a closed portal with something)?

[stgatilov]

1 hour ago, peter_spy said:

Shouldn't mappers be able to solve 99% of such problems with either LOD (hide_distance) or func_portals (either with triggers, or portal_dist + func_statics, if they want to cover a closed portal with something)?

No.

Imagine you have an object near a wall. But the bounding box of the object punches through the wall, so it gets rendered even on the other side of the wall. This is typical case when areaLock is used, as far as I know.

And it gets worse if the wall is not axis-aligned, or not even planar.

[MirceaKitsune]

AreaLock seems like an useful feature so I hope it never gets disabled. Rather that mappers have complete information on how it works and what it does as to not misuse it.

The rule of course is you don't set it on anything that moves. Unless it's movement along a fixed path so the object doesn't touch any visportals, that movement should be safe if the entity is guaranteed to remain in the same vis area. You should only not enable it if the entity touches a visportal, as it will then become invisible and get cut off from the side its center isn't in.

[peter_spy]

3 hours ago, stgatilov said:

No.

Imagine you have an object near a wall. But the bounding box of the object punches through the wall, so it gets rendered even on the other side of the wall. This is typical case when areaLock is used, as far as I know.

And it gets worse if the wall is not axis-aligned, or not even planar.

Hmmm, to me it sounds like improper use of assets, or not thinking about playable space with assets in mind, modular or otherwise. Never had these problems because I was always able to make assets with proper origin point placement, and with certain grid in mind. Thanks for the explanation though.

[Dragofer]

5 hours ago, stgatilov said:

And it gets worse if the wall is not axis-aligned, or not even planar.

I observed the majority of issues with objects near diagonal walls, even when they were perfectly grid-aligned with the walls, or even some units apart from the wall. The engine seems to be very conservative by treating the entire bounding box of such diagonal walls as the boundary, rather than the actual wall itself. So objects quickly start to leak to the other side's visleaf when they begin to approach such walls.

You can see a very stark instance of this issue in the ship in Perilous Refuge, where almost the entire ship's contents leak to the exterior visleaf due to the many curved sealing walls. areaLock is crucial there.