Hi all,
Firstly, sorry if this is a common question - I'm new to this and it's quite possible my search keyword selection isn't quite optimal yet.
I'm building a simulator that includes an object that I need to occasionally teleport. I've been looking at the TestAdvancedVehicle.java example and how setPosition() is implemented. In that case, the nodes down the graph need to implement resetPosition (which resets their location relative to the parent node to some stored offset) and need to make sure they also call resetPosition on their children.
Problem is (apart from needing to maintain resetPosition), I believe that this means that everything gets reset (funnily enough), including joint angles and the like, if the resetPosition() chain involves objects on both sides of the joint (basically everything gets reset to whatever the original offsets were). What if I just want to move a whole object (comprised of a node plus all of its children and with some parts linked with joints) and preserve all the joint angles/translations? I can think of a couple of ways of traversing the node graph to do this but before I reinvent the wheel, is there a standard (or particularly smart/efficient) way of doing this sorta thing?
I've currently got it happening by using solid joints instead of resetPosition (and relying on joint resolution to keep things together) but of course if I teleport across a wall or something it probably isn't going to work. It probably also means my localTranslations get incrementally more and more offset - not sure if this will be a problem.
Tnx 
Hi! Good question.
I am not an expert but I believe that yes, you need to recursively reposition all children nodes, applying transformations if needed.
jjmontes said:
Hi! Good question.
I am not an expert but I believe that yes, you need to recursively reposition all children nodes, applying transformations if needed.
Tnx :D Yup I know ... I guess my question though is if there is a standard way or pattern to do this or if it's a case of anyone who comes across the need makes something up from scratch ... I imagine this sorta thing isn't that rare so if there's a commonly accepted way of doing it (I've looked and not found it but it could be my google-fu isn't dialed in quite right yet) I might as well use that and avoid confusing the poor sod who has to maintain my code after me. ;)
Maybe the standard way IS via individual resetPosition() calls but it seems an awful messy way of doing things as you've now got effectively four object graphs to maintain (kinematic graph, scene graph, composition graph and position reset tree) when you should really only need the first three (and the fourth should be derived when needed).
There no API method for this yet. But I agree it would be very useful. Such a "moveEntity" method should be possible (e.g. find all attached nodes for a given dpn and change all the coordinates and update the joints). Maybe you need to fiddle around the the joints a bit to avoid strange effects after moving the attached bodies. We can add it to jME Physics if you get something running.
Tnx for the quick answer!
OK so at least I know my search skills haven't taken a dive south 
I've currently got a slightly less hacked (or more depending on your perspective) solution which involves setting the translation/rotation of sub-entities by setting the translation/rotation of their parent Node (rather than the base DynamicPhysicsNode) and some other bits and pieces that basically mean the scene graph takes care of some of the transform jiggery pokery for me (I still need to make the DynamicPhysicsNode translation/rotation match the parent Node but because they're now on top of each other it's basically a copy of the transform rather than a calculation). Thoroughly impractical for a general solution but it works for now.
Once I've got the rest of my code working though I will try and revisit this, if I come up with something general I'll be sure to post it!
A more elegant solution would be allowing nested physics nodes, btw. It would involve some more trickery scenegraph update after the physics update, but could work… so if you're ambitious you could look into that as well