[SOLVED] Surface Activation and Immovable flag (and other cullings...)

[K.Wagrez]

Hello everyone,

I don't really know which category this question belongs, but I believed it's maybe rendering/physics, so here it is.
This time I have a question about the Immovable flag, the spatial tree and possible conflicts with frustum/occlusion/lod culling.

As I understand, written here (https://developer.unigine.com/en/docs/2.19.1/editor2/node_parameters/transformation_common), the Immovable flag causes the node to be sent to a separate static spatial tree.

My first question is: what kind of improvement does this "different" spatial tree brings ? Less requests on checking if the node's position has changed ? 

Then there is the mention of "prohibition" of certain actions, like turning on/off a surface from the object. Why is that ? And also it seems I can still do it, but it's prohibited ? Does it causes a recomputation of the static spatial tree when we do that ?

Since turning On/off a surface causes problem on the spatial tree, is there any problem when using culling methods such as frustum/occlusion or lods on an Immovable object ?

To give a little context, I have a use case where to "animate" something, we actually turn On/Off one of its surface (which could be replaced by swapping materials, but that's a battle yet to come for me), which I suppose causes problems if I set said object to "Immovable". I'm trying to push performance at the maximum, so any little gain is good.

Maybe the answers are in the forum/documentation, but I didn't found them. It's possible that I lack the keywords :)

Thanks in advance !

Edited June 30, 2025 by K.Wagrez

[bmyagkov]

Hello!

@K.WagrezSetting a node to Immovable moves it into a special static spatial tree. The big benefit is performance — nothing moves there, so the engine always knows where everything is, and doesn’t need to recalculate that tree. That makes handling the rest of the scene (with dynamic objects) faster and simpler.

Now, regarding surface toggling, culling, etc. — technically everything works fine, nothing will break, and culling will behave as expected. But if you start changing things that affect the spatial tree (like turning surfaces on/off), the engine is forced to rebuild the static tree — which takes time. So, while it’s not strictly forbidden, it does reduce the performance gain you’d get from using Immovable in the first place.

That’s why the engine warns you in the log — it’s a hint that you might be hurting your own optimization by modifying a supposedly “static” object.

Hope that clears it up :)

Thanks! 

[K.Wagrez]

That's pretty much what I expected, thanks for clearing it up :). That would explain some of the problems I had with optimization of "animated" objects.

Does frustum/occlusion culling use the static spatial tree/dynamic spatial tree to find what can be seen ? (I would suppose yes)

[bmyagkov]

2 hours ago, K.Wagrez said:

That's pretty much what I expected, thanks for clearing it up :). That would explain some of the problems I had with optimization of "animated" objects.

Does frustum/occlusion culling use the static spatial tree/dynamic spatial tree to find what can be seen ? (I would suppose yes)

Yes, of course — both spatial trees (static and dynamic) are actively used by the engine. After all, it needs to perform culling and other spatial queries for both immovable and moving objects — there's no way around that. The engine maintains multiple spatial trees and it dynamically chooses which one to use depending on the task at hand.

Thanks!