Feature request : Decoupling parent rotation

[Lil Margin]

Hey,
I wanted to request a feature for Irrlicht which is to decouple a parent rotation so the child node don't get effected by the parents rotation
Thanks in advanced.

[hybrid]

Just the rotation? Rotation and Scale are tightly related, hence it would be either or. But it would be much simpler to avoid parenting and maybe update the positions each frame in an animator.

[Halifax]

Just the rotation? Rotation and Scale are tightly related, hence it would be either or. But it would be much simpler to avoid parenting and maybe update the positions each frame in an animator.

What do you mean either or? At any rate, I think this should be added to the ISceneNode interface. Creating an animator, for what the scene graph should already do, seems a little bit hackish. Not to mention, IrrEdit wouldn't be as coherent.

But overall, two flags would suffice: inheritScale and inheritRotation. This makes real FPS cameras actually possible without having to hack an animator to do it. For example, parenting a node to an FPS camera to inherit position, but not orientation.

[hybrid]

Yeah, and someone wants no translation, but only rotation and/or scale, and a third one wants only two levels of child awareness, but not deeper. This makes the whole interface rather clumsy, and I don't see a reason for this feature.
What I meant with either or is that in transformation matrices, rotation and scale are interleaved, so if you want to ignore the scale, you have to decompose the values, which is non-trivial. So adding just the two values would already introduce a large overhead to ISceneNode for just some rather uncommon corner case.

[Halifax]

For some reason your full post doesn't show up on the forums, but it does in the quote.

Yeah, and someone wants no translation, but only rotation and/or scale, and a third one wants only two levels of child awareness, but not deeper.

That's a bit ridiculous, I couldn't see anyone requesting that. Even if they did, it's a senseless request.

This makes the whole interface rather clumsy, and I don't see a reason for this feature.

I don't see anything clumsy at all. You add four member functions: {get,set}InheritRotation, {get,set}InheritScale.

And the reasoning behind this feature is the fact that it is required in any compliant FPS game. Not to mention, Ogre already has it implemented.

What I meant with either or is that in transformation matrices, rotation and scale are interleaved, so if you want to ignore the scale, you have to decompose the values, which is non-trivial. So adding just the two values would already introduce a large overhead to ISceneNode for just some rather uncommon corner case.

Yes, with the current design, you would introduce non-trivial overhead. This requires a small rewrite for the system. At any rate, all I'm saying is that I'm pretty sure an animator was not meant for things such as decoupling parent rotation from translation. It's a problem that is inherent to the scene graph.

[hybrid]

Yes, it's inherent to the scene graph because the scene graph is meant to work as such. It's simply the defining spec for our graph, and hence there's no way around it. And no, we won't rebuild the graph with quaternions because some other engine might do. Our parent/child relation is working as such, and this won't change.
Moreover, what about the Irrlicht FPS games already made. Did they do something wrong? At least there seems a way around this situation besides changing the most fundamental Irrlicht structure.

[christianclavet]

As said previously, just copy the value of the node you want to be parented to the node to be affected (Kinda of a "follower")

A more elaborated use of this would be to create an animator that would follow a node, you could even put an offset to it if you want. If the value is taken from a directional vector, this could serve to "attach" wagons to a train.

[Halifax]

And no, we won't rebuild the graph with quaternions because some other engine might do.

I don't recall ever saying rebuild the scene graph with quaternions because Ogre does. At any rate, I would profile the situation and weigh the pros vs. cons to see which one is more beneficial though, if I was suggesting it.

Moreover, what about the Irrlicht FPS games already made. Did they do something wrong? At least there seems a way around this situation besides changing the most fundamental Irrlicht structure.

No one is saying that they did anything wrong, maybe they don't need the same requirements that 2 people have already spoke of in #irrlicht. My question is why are we striving for "at least there seems a way around this situation"?

[bitplane]

I agree with Hybrid. Simply including a follow animator by default would be far less messy.

[Halifax]

I agree with Hybrid. Simply including a follow animator by default would be far less messy.

Eh, I guess it's settled then, this topic is closed.