A new way to attach spatials

Development
1

When I was making code that used an elevator, my first idea was to attach the character to the elevator node, move elevator, then reattach the character to the node it was on before, but doing it exactly like this makes the character move to another position (which makes perfect sense, since your position depends on the position of your parent node), so I found this thread:

which does exactly what I want, so I did (basically copied with minor modifications) the method:

public static final void attachChildKeepingHisWorldTransform(Node parent, Spatial child) {
 Transform childTransform = child.getWorldTransform();
 Transform parentTransform = parent.getWorldTransform();

 Vector3f scale = childTransform.getScale().divide(parentTransform.getScale());
 Quaternion rotation = parentTransform.getRotation().inverse().multLocal(childTransform.getRotation());
 Vector3f translation = parentTransform.getRotation().inverse()
 .multLocal(childTransform.getTranslation().subtract(parentTransform.getTranslation()))
 .divideLocal(parentTransform.getScale());

 Transform newLocalTransform = new Transform(translation, rotation, scale);
 parent.attachChild(child);
 child.setLocalTransform(newLocalTransform);
 }

to use in a utility class, but this code could very well be placed in the com.jme3.scene.Node class (it would just remove the parent parameter as it would already be within the class and remove the static and final modifiers), since I believe it would not require much maintenance and It wouldn’t add any compatibility issues, what do you guys think?

1 Like
2

a) isn’t this just hand-coding worldToLocal and localToWorld that already exist?
b) it would never belong on Node. Completely wrong place for it.
c) every line of code is some amount of maintenance burden… every new public API needs to be maintained, documented, answered in forum questions for folks who don’t understand how to use it, etc…

A method like this would be EXTREMELY specific to one rarely used use-case that is already handled by worldToLocal() and localToWorld(), in my opinion.

“Why would this be so rarely used?” a) because the elevator use-case is rare itself and b) because 99% of games would be using physics and the physics would take care of the player-in-elevator motion.

3

First of all, I would like to thank you for your feedback, feedback is always welcome as long as it is constructive.
I agree with you, any line of code is a maintenance burden, so I usually only comment on what I believe would be useful.
This code actually does what localToWorld and worldToLocal do, but it also takes care of rotation and scaling.
I respectfully disagree with the part where code like this would be EXTREMELY specific, because even though the example I gave of an elevator is covered by physics engines, it can still be useful in basically any vehicle that transports other spatials, like cars, motorcycles, horses, mine carts, claws or hooks (like the use of the guy in the post I mentioned), there may not be anyone doing any of this, but there are uses.
Because it is a maintenance burden I completely understand not wanting to add code, but if I were to add code like this (I don’t say this code exactly, as this doesn’t even check if the parameters are null) the Node class would be the class that it makes more sense to me, since it is using it that we attach spatials to the scene.
Finally, I would like to thank you for reading all of this, since our lives have been so busy lately, and I understand that this addition may not be necessary, I just posted it to see what everyone thought.

4

Note: a more general approach might be a control that you can attach to your spatial that adjusts it’s world transform to the world transform of some other spatial. Then when you want to “attach” your person to a vehicle, elevator, whatever… just attach a temporary child that you link your person to with that control. This would work very well for things that have fixed attachment points. (JME may already have a control for this, in fact… I rarely use controls so I don’t know.)

You could even have it so you can mask off certain parts of the transform that it doesn’t transfer… like rotation+scale, or the x/z parts of translation. So for your elevator example, you could just adjust the y value of your ‘person’ and let the rest of the world transform do what it will.

Deciding to stop ‘attaching’ is just a matter of removing the tracking control. It limits any weird math to only the attachment part.

Modeling this sort of elevator thing without physics is tricky, though. (Tricky enough with physics.) Even with the original approach, it’s pretty limited.

That post was also from 2012. Almost long enough that it could have been the old jme2 engine. I guess it doesn’t come up too often and the engine has advanced a lot since then, too.