Great, I thought it would go through alpha. Experimental was in reference to what dpeter99 was asking about but as far as I’m concerned alpha/experimental are basically the same thing.
On another note, are there any plans to fix the issues with the current scene hierarchy. Right now, if you have 100 GameObjects in the hierarchy with no nesting the performance is as expected. If you recursively nested those objects e.g:
You start seeing orders of magnitude difference in performance, I would expect things to scale out in a linear fashion. I’m not sure if anyone is aware this is a problem or not but basically the deeper you nest objects, the worse it gets.
This is off-topic here.
This is not really an “issue”. It is a question about single threaded performance versus multi-threaded. Every hierarchy you build is processed on a separate CPU thread. If you make only one, it will be processed, linearly on one CPU thread. This is why Unity recommend to put your gameobjects into many hierarchies as possible. To process them on multiple threads.
One hierarchy cannot be processed on multiple threads because of book-keeping and because of calculations rely on data from upper levels and data-transfer between CPU threads is complicated and slow.
Which means it wouldn’t really make that much of a difference between single threaded processing and multi-threaded processing on the same one hierarchy.
The solution is to break up your hierarchy into multiples.
Thanks for the info, this seems like it’s a problem that has been thrown by the wayside. If you test this parenting of hierarchy objects in other engines e.g Unreal/Stride/Godot they don’t suffer from this at all which indicates there is a design problem with the current implementation in Unity. With what is described to keep the performance in check, the hierarchy isn’t really fit for purpose if a layman has to dig into those kind of specifics to not pay the cost.
Wouldn’t it be more performant by default to say that any object that has children is treated as it’s own hierarchy (even if that object is parented to another), that way if everything is ultimately parented under a single object, each valid hierarchy under it can be processed multi-threaded without needing to break up the user defined hierarchy structure because the Unity solution is inept?
This is really off topic; I feel a bad talking about this here. Maybe you should open another topic. That said, I think the difference is because hierarchies don’t rely in nested transforms in those engines. There can be a number of things that are nested hierarchically, which aren’t exactly equivalent GameObjects, but every entry doesn’t necessarily have a transform that must propagate its properties when a hierarchy changes. Maybe something like this could be achieved if transform components were optional? Or at least disableable to avoid some breaking changes?
Your info is partially outdated. The talk you’ve linked was in context of older Unity version. Since then, there were multiple crucial changes to transform and how hierarchies and parenting/reparenting work and some of them are optional and can be enabled/enforced to negate the penalty from complex hierarchies by big margin. I dont remember though which Unite talked about it in depth.
Not to hand, this was a spike done by a colleague. All that was done was to spin up a recursively nested structure in the scene hierarchy and access a value every frame in each of the engines respectively. All others show a linear performance difference as you add more to the scene, Unity gets exponentially worse.
As has been mentioned, there are reasons this happens in Unity but I can’t help but feel this should be addressed.