Imagine having a huge star-ship, that has X rooms, every room, Y chairs and so on. If you update the star-ship position, you have to sync all the child with he new position. That's very eats a lot of resources and mostly results in FPS drop if done in game loop. I think the only way of solving this is cheating? Updating only what' seen by player(s)?

And why is more expensive (in most engines) to update object with many child's then update a object with lot's of vertices (even more in sum), but as single object?

trsh said:
And why is more expensive (in most engines) to update object with many child's then update a object with lot's of vertices (even more in sum), but as single object?

Because every object needs to have a transform calculated from its own and essentially all its parents combined transforms; while vertex-positions are usually calculated on the GPU when every time the object is rendered so there is no additional cost for updating the object-position (at least none that scales with vertex-count).

Its also more of a problem with generic engines like Unity, because you have to keep in mind that “transform” does not only matter to rendering, but gameplay/scripting as well. If you don't know that objects are only used for rendering, you have to make their transform accessible to scripts, and thus also having to update the transform immediately on every change in the hierachy. Thats especially a problem with unity where everything and their mother is a part of a GameObject. But if you have a more constrained use-case and you can modify the core-engine, you could make a more optimal system.

@juliean

while vertex-positions are usually calculated on the GPU

Still have to update collisions. Even a ConvexHull can get complex for a complex model. So there is a calculation on CPU happening.

trsh said:
Still have to update collisions. Even a ConvexHull can get complex for a complex model. So there is a calculation on CPU happening.

I'm no expert with mesh-colliders, but I suppose ConvexHull will usually be a) simplified geometry, and b) have its vertices be calculated and the transform dynamically applied (instead of calculating the world-space vertices for every move). So again, you are in a situation where the cost is rather static then move←vertex-count based. (at least that how I would implement such collision)

trsh said:
And why is more expensive (in most engines) to update object with many child's then update a object with lot's of vertices (even more in sum), but as single object?

Another reason:

To address all descendants, you probably have to traverse a tree, resulting in random memory access and cache misses.

This could be solved by storing all descendants in linear memory order, so instead traversing a tree you just iterate.
You could make a test to see how performance would change and if this would solve your problem.

But ofc. it's difficult to maintain such linear order within a dynamic game, especially if different systems and algorithms have different requirements for ideal memory orders of shared objects.

trsh said:
I think the only way of solving this is cheating? Updating only what' seen by player(s)?

Why do you think this is “cheating?” Video games are more akin to magic shows than full simulations. Trickery is a normal part of optimization. ?

My approach to this would be to have objects internal to the starship in an entirely different physics space. Nothing outside the ship can really affect them, right? Why would you need to simulate them at the world level? Never mind the CPU usage required to sync them up with the parent every frame, the floating point inaccuracies as the starship got farther from the origin would start to add up (unless you're using fixed point for positioning) and there would be all kinds of problems resulting from that.

Simulate them at their own, local level, where the only things they need to interact with are each other and the hull of the starship. And definitely don't even bother updating them if they aren't in the player's field of view, unless they're actually moving within their physics space.

Anyways, what I always suggest and we do in our huge open-map games inc ase for collision is to cheat whenever possible. We turn real physics on if the object is in certain range so that player can interact with it (like throwing something against a wall) amd else turn it off entirely. Physics caluculations are a heavy beast that eats up performance faster than you can provide it