I am once again re-architecting my hobby engine and have a philosophical/design question about whether or not game objects/entities should have hierarchical transforms. In other words, if object A is a parent to object B, should object B's transformation be defined relative to object A, or should it be defined relative to the world space?

Obviously we need some kind of hierarchy to organize entities into logical groups, but it's not clear that the entity transformations should also be hierarchical. The use of hierarchical transforms causes various problems when interfacing with other systems that operate exclusively in world space (e.g. physics engine). It adds a lot to the overall complexity of the engine due to various edge cases. When I have used Unity, I have often been annoyed at how its impossible to group objects without having the transforms be hierarchical. It often seems counter productive.

Whenever I need to access the world-space transform of an entity, I have to check if the local transform or any parents have been modified and then recompute the world-space transform by walking upwards to the hierarchy root and concatenating matrices. I can do this either once per frame (missing any sub-frame modifications to transforms), or do it on-demand with a dirty flag. The first possibility is easier to make fast by batch processing, but could have incorrect results in the middle of the frame. The second possibility would always produce correct results, but would be slower (due to checking dirty flags on each access). Both options are vastly slower than just regarding all transforms as being relative to the world space and doing nothing special. Hierarchical transforms also result in larger object sizes due to having at least 2 copies of the transform matrix, more cache misses due to hierarchy walking, and other inefficiencies.

The only argument I can see for having hierarchical transforms is for rigid assemblages of multiple objects (i.e. static scene geometry), where it might be convenient to move all objects with a single transform. However, this can be also be easily done in the game engine editor by just applying the same transform edits to all objects that are part of a group. These marginal benefits don't seem to outweigh the added complexity and headache that hierarchical transforms add to the engine.

Am I being crazy here, or are hierarchical transforms really needed in a modern game engine?

Aressera said:
The only argument I can see for having hierarchical transforms is for rigid assemblages of multiple objects (i.e. static scene geometry), where it might be convenient to move all objects with a single transform. However, this can be also be easily done in the game engine editor by just applying the same transform edits to all objects that are part of a group. These marginal benefits don't seem to outweigh the added complexity and headache that hierarchical transforms add to the engine.

Thinking the same, i have changed my editor some months ago to all world space.
Everything is still organized in a tree, so it's easy to transform child objects if we move a parent.
Also, i do much more range queries than actual edits, and the range queries benefit from having no need to calculate final world space while traversing the tree.

However, my editor currently is more of a modeling tool to build a static world, than an actual game editor dealing with dynamic articulations like characters, doors, elevators, moving platforms, etc.
So i'm still quite unsure about my decision. Not sure if i want to use the same tree for them, or if i'll make them local models with their own hierarchical transformation data structures.
Both would work, technically. So yes, up to this point, it's mainly philosophical.

But there is one technical argument for me: Floating point precision.
If we want a large open world but still use 32 bit floats, having all in worldspace does not work.
An easy solution would be to use an infinite regular grid, where all objects are children of the closest grid cell. Their transforms are relative to the cell center, so 32bits are enough.
To process our data, we then transform objects of adjacent cells to the current cell. Because cells form a regular grid, we don't need worldspace at all. It is enough to know that an adjacent cell has a (still small) offset we get from cell size and adjacency.
This way we can have a world of infinite size with 32bit, assuming we never care about cells which are very distant to the current cell.

That's just an example, but to me it shows the main limitation of working conveniently all in worldspace.
It gives me the most doubts on my decision. Currently i'm unsure if i want to do such space partition only in the game, or also already in the editor.
Porting the editor to 64bit floats would be less work, but it will have a large cost on processing times, meaning longer waits.

So if you have large worlds in mind, i think that's the biggest issue to think about.

You have a hierarchy of entities. Each entity has a local transform (relative to its parent) and a global transform (relative to the world). Both ultimately encode the same information. Both are occasionally useful to have. Basically your options are:

• Store both and update them together.
• Store one and dynamically calculate the other when/if it's needed.
• Store both but only update one of them and mark the other as “dirty”, then recalculate it when/if it's needed. Basically equivalent to only storing one and dynamically calculating the other, except that the result of the calculation is cached.

It seems to me that you don't need to make an up-front decision at all. All of these options could expose the same interface, so you can just implement them all, choose from among them based on a compile-time option, and actually measure their relative performance. Then you would actually know which one works best in your particular case instead of guessing.

Aressera said:

The only argument I can see for having hierarchical transforms is for rigid assemblages of multiple objects (i.e. static scene geometry), where it might be convenient to move all objects with a single transform.

Most characters are implemented as a hierarchy of transforms. Animations are done at the bone level which implies that each bone is relative to its parent. And when I move the whole character I need every part of the character to move relative to that.

In particular, “this can be also be easily done in the game engine editor by just applying the same transform edits to all objects that are part of a group” is fine for translations but doesn't work well for rotations.

So it's unclear to me how you'd handle complex animating objects like this if every part of it is defined in world space.

Kylotan said:
Most characters are implemented as a hierarchy of transforms. Animations are done at the bone level which implies that each bone is relative to its parent. And when I move the whole character I need every part of the character to move relative to that.

This doesn't necessitate the whole skeleton be represented by hierachical game-objects in the scene-graph though. I know Unity does it that way, but I find it rather clunky (in general scenes in unity are filled with so much clutter). Unreal hides the bones away, meaning the character itself will only be one “SkeletalMesh”-component, and the bones are represented as an interal, hierachical structure, independant from the “scene-graph”. For attaching things to the skeleton, you use sockets.

While I prefer the second system specifically for skeleton, unreal does have a basic transform-hierachy for actors as well, which I still find to be invaluable. For the 2d-engine/game I'm working on, there are just so many things that can easily be solved by a parent→child transform hierachy. Spell-effects for the player (fire-shield), vehicles that transport NPCs from A to B… So the solution for me would not mean getting rid of the transform-hierachy, but implementing a solution that doesn't have so many redundant/unnecessary game-objects like Unity has. For example, implement Folder as actual Folders and not just parent-GameObjects (which again Unreal also does).

There's definitely a good argument for not giving everything that needs a transform its own GameObject. Unity does suffer from clutter while also making it hard to make logical groupings that don't affect transforms, as mentioned in the original post. But the question was about objects that explicitly already have that hierarchical relationship, so even if you make a decision to hide some of these relationships in the editor like Unreal does, the relationship is still there and is still hierarchical.

I can imagine an engine where character hierarchies are solved as a special case and every other relationship is done in world space with more special case logic to move things relative to parents in the few occasions it's necessary. Some of the ECS style engines seem to do this by necessity (as they can't easily represent an unbounded hierarchy), sometimes hard-coding the maximum depth that the hierarchy can take so that a fixed number of batched updates will always work with no dependencies within each batch. (This is mentioned in the book Game Engine Architecture, where an example makes the assumption that there are 3 levels - vehicles/mounts/platforms, characters (who might be on a vehicle, mount, or platform), and attached objects (which might be on a character)).

Aressera said:
I am once again re-architecting my hobby engine and have a philosophical/design question about whether or not game objects/entities should have hierarchical transforms. In other words, if object A is a parent to object B, should object B's transformation be defined relative to object A, or should it be defined relative to the world space? … Am I being crazy here, or are hierarchical transforms really needed in a modern game engine?

I'd say you're focused too much on your one specific case, rather than the general case.

Attaching objects is the most obvious. We attach objects like weapons and accessories to the character so those items move correctly. We can mount a gun or a pennant to a jeep. Keeping the positions relative to their parent makes everything just work.

As buildings are composed in levels you place all the items into the building you want all the parts to move together, rather than having to move every item individually. You don't want to have to move every flag, banner, pillar, firepit and fire/smoke effect, and similar item one at a time, just move the shared root for the structure. Similarly you can have a small base that you want to clone and move elsewhere, you can move all the buildings, towers, and everything else as a group. Moving around rooms, especially when you clone or instance a room, same story.

While big games will have piles of game objects and collection storage nodes kept at {0,0,0}, and it is true many objects don't need the hierarchy, there are so many cases where it is critical to have hierarchies of objects all attached to each other, where moving one thing would mean moving thousands of things otherwise.

For a project I am working on, I had to use hierarchy becasue the object involved are basically mechanic, it would have been very difficult to model as rigged mode. So basically I think that a hierarchy model is mandatory for every decent pet-engine,

Thanks everyone for your input and examples. It seems like hierarchical transforms are needed in at least some cases, and thus should be supported by the engine, though perhaps discouraged for performance reasons.

I have decided to go with the on-demand computation of world transform matrices with dirty flags.

Kylotan said:
Most characters are implemented as a hierarchy of transforms. Animations are done at the bone level which implies that each bone is relative to its parent. And when I move the whole character I need every part of the character to move relative to that.

I agree with Juliean, that character skeletons should be implemented in a separate hierarchy, not in the Unity way of everything-is-a-game-object. By keeping the matrices with the mesh, it's very easy and efficient to calculate a packed array of bone matrices that can be uploaded directly to a uniform buffer for shader consumption.

For the case of attaching objects to characters, I'm not convinced that the hierarchy is the best solution. I think I'd prefer explicit attachments for weapon-in-hand type of stuff. I'd like to push the engine to physically simulate as much as possible (e.g. using breakable constraints), rather than using rigid parent/child relationships. For instance, a character might carry a weapon on their back. It would produce more natural movement for the weapon to be a rigid body (simulated in world space) attached with physical constraints to the character's back, so that it will move around naturally as the character moves. When the character grabs the weapon, the back attachments are disabled/removed, and an attachment is added to the hand(s). These joints might be broken by a large force (e.g. explosion or enemy attack), which would cause the weapon to be knocked out of their hands. So, my point is that in some cases transform hierarchies can be convenient, but also a crutch that might lead to more rigidity in motion, that would be more natural if it was physically simulated in world space.