While the notion of getting realistic simulated motion for character-attached objects is theoretically appealing, things can quickly get quite dicey when you consider that character animations/movement are often way beyond “real world” speeds, which can lead to lots of hairy physics interaction issues. There are obvious cases of characters whose movement is intended to be super-human (think things like “dash”, or double-jumping), but even things that are just tuned to feel responsive for game-feel purposes are often incredibly abrupt and rapid (in-place turn speed, etc.).

This is something nearly everyone has to deal with for things like cloth simulation, where you sometimes just freeze the simulation (or put it into a keyframed state) or do other hacks to prevent it from freaking out due to intense accelerations or body movements. Similarly, using rigid-body physics with constraints can be troublesome too; you can end up needing several spring constraints, etc., just to keep things behaving themselves. If the attached object is intended to interact with body-accurate collision, then you also have the fun of considering what the body parts are supposed to do in response. If they are keyframed, then you now have basically infinite mass body parts moving at incredible speeds hitting (and causing collision response on) dynamic low-mass rigid bodies. In one particular title I worked on, taking out of account cloth and attached objects, just the body-accurate collision interacting with world dynamic objects was so problematic (turning in a pile of boxes causing them to essentially explode outward) that I had to damp/zero the velocity of objects colliding with the body to prevent the character from being a debris launcher.

All that said, it can be done, and I myself have done it in very targeted cases in the past. But I would caution that expecting this to work well in the general case, even for characters that are animated “realistically” and move at semi-sane speeds, is probably overly-optimistic. I also tend to lean in the direction of not having systems quite so reactive/inter-dependent, such that doing something as innocuous as tuning the run speed will have all sorts of knock-on effects on simulation. But things like you mention can be done, just more explicitly ("oh, character just was near an explosion of X magnitude, detach, make dynamic and apply appropriate force").

Programmer71 said:
Unity is the only way.

Unity is very much not the only way. :P

(At the least Unreal seems to have good uptake, and there are other engines that may prove effective, too. And that's before we get to specialist engines like AGS or RPGMaker…)

Aressera said:
I think I'd prefer explicit attachments for weapon-in-hand type of stuff.

That is a fine approach for such purposes, I do think.

I do suspect that it might come with lower performance than the parent-child approach, and it does enforce that the game use rigid-body physics, but as you point out, it does have its advantages, too.

SBD said:
While the notion of getting realistic simulated motion for character-attached objects is theoretically appealing, things can quickly get quite dicey when you consider that character animations/movement are often way beyond “real world” speeds …

Oof, but this is a good point, too.

@Programmer71 That's fair.

But do please be careful: others might take your jests for seriousness, and thus be misled by them.

After all, text carries relatively little tone, and it seems likely that not everyone who reads these posts knows of your history with publishers.

Didn't read all the posts, but to the original: I store a matrix that is local and then one that I label FinalDrawMatrix, what you would see on screen.

Imagine you are on a turret on a spaceship. To rotate the turret on the vertical axis (OpenGL would be Y-Axis). You simply do: NewMatrix = RotationMatrix(y_axis, newAngle). Then you multiply the parent matrix to get what it will look like when finally drawn.

This also helps in restricting limitations of angle. If the turret can only rotate -30 to 30, then this method is much simpler to determine that and compute a new matrix. It's much easier to visualize what the turret it doing in code logically. In order to rotate on the turrets axis in world frame, you have to do some work to compute that rotation about the turrets world y axis. If you have any interesting texturing effects on your turret, you might also want the local y axis for whatever reason.

My engine (loosely called) is completely hierarchical. The reason is I'm dealing with large spaces (think solar systems and larger) using double precision. However on the GPU I don't have the luxury of double. Using world coordinates for everything would limit me to a couple dozen kilometers or force me to do some sort of rebasing hack. Even if I had double GPU side it, would fail when I got to galaxy sized stuff.

I therefore have a hierarchy and always start with the camera when rendering. The camera itself is also somewhere in the hierarchy, usually near a leaf, and I render starting from that point in the tree. In general I have to go up to the root before going down. This ensures that stuff close to the camera doesn't suffer from a loss of precision.

The other thing is I can have things like a moons that orbit planets and planets that orbit suns etc, and everything just kind of falls into place. Even the player is a child of the planet he's currently on. In a small static world I guess it doesn't matter so much but once things start to move, hierarchy seems the way to go IMHO.

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?

I laughed this type of design problem as irrelevant, until i began to write a game with jet aircrafts. after i hacked yaw/roll/pitch type of rotation into the code, i just faced the next problem: the airplane can carry rockets, bombs, fuel tanks. my head probably looked like the face of the dinosaurs when the meteor arrived.