Parent node rotation displaces children

I’m not sure if this topic is better suited for the virtual-reality category, but I put it here just in case. Anyways I’m trying to rotate the observer around the headset’s location, but if I just rotate the observer it’ll rotate from the origin; since it isn’t translated with the headset. I’ve made an observerNode (parented to observer) which is translated to the negative of the headset’s position and I’ve made a playerNode (parented to observerNode) which is translated to the headset’s position. This seemed to work how I expected it to, the offset translates the playerNode to the location of the headset without moving everything forward infinitely. However, when I try to rotate the playerNode, it will stutter slightly then shoot both the headset and the node in a direction instantly.

playerNode = new Node();
observerNode = new Node();

oldPos = vrAppState.getFinalObserverPosition();

if (vrAppState.getVRinput().getAxis(1, VRInputType.OculusThumbstickAxis).x != 0)
playerNode.rotate(0, vrAppState.getVRinput().getAxis(1,VRInputType.OculusThumbstickAxis).x * -tpf, 0);

Here’s an example of how the headset and node gets shot somewhere.

headset (-4.5064522E36, 0.88001215, -1.6770646E38)
observer (-4.5064522E36, 0.86536145, -1.6770646E38)
headset (-1.7193532E38, 0.86536145, -1.7835308E38)
observer (-1.7193532E38, 0.8543761, -1.7835308E38)
headset (-Infinity, 0.8543761, -2.321478E37)
observer (-Infinity, 0.841684, -2.321478E37)
headset (NaN, NaN, NaN)
observer (NaN, NaN, NaN)

The problem is in code we can’t see. You need to track down where the -Infinity comes from… it’s probably what leads to the NaN.

It might also help to explain what you are actually trying to do. Like, why is observer and player different, etc… What are you actually trying to simulate?

The simple thing i can suggest (because i dont see error looking at this part of code)

is to run DEBUG mode in Eclipse(i remember you were using Eclipse? also i suggest other IDE’s here btw).

And in DEBUG mode step by step check variable values here.

debug variables(rather part codes) like:


on each line step and see when it starts show NaN or Infinite values.

Then you will know exactly what line cause issue trully.

since first 2 “ticks” work for you it seems(except X value that seems problematic), probably some later values that come from somewhere? (VR?) start giving infinity values, so you need debug when and where this infinity come from.

Its much possible it will come from VR and you will just need add some condition to skip specific values. But anyway then it would be more like VR issue.

When I check the positions of everything at the same time, it seems that the FinalObserverPosition has different values than the other two, even though I just set them a few lines before. I assume this is because the headset gets called faster for it’s own purposes. This difference causes the observer to fly out which causes the observerNode and playerNode to follow. I also see that the FinalObserverPosition is always one position ahead, so the two nodes do use older position data, but I don’t know why that is.

(-0.016084606, 1.1650249, -4.1433796E-4 Final) (-0.007589584, -1.1650249, 0.042456 observerNode) (0.007589584, 1.1650249, -0.042456 playerNode)

(0.00589073, 1.1650563, 0.0551406 Final) (0.0160587, -1.1650563, 4.7534332E-4 observerNode) (-0.0160587, 1.1650563, -4.7534332E-4 playerNode)

(0.07704901, 1.1650945, 0.0779815 Final) (-0.005918999, -1.1650946, -0.055080645 observerNode) (0.005918999, 1.1650946, 0.055080645 playerNode)

I’m trying to rotate the player’s viewpoint at their location. The location of the observer isn’t actually the location of the VR headset, so rotating that will rotate you from the observer’s origin which usually isn’t your location. If you just move the observer to your location it will constantly move you.

this is more VR related question.

Other people do not complain about it, so maybe you use wrong method, or you forgot to “synchronize” or something.

Cant help because i were not doing VR things.

Best would be if you would look some ready example/test of VR in JME.

If multiple threads are modifying the same values then you are going to have a bad time.

I’m not changing the value, I’m copying it to another node. However, by the time I do so, the value has changed.

I would have to see the code in question to say anything but if nothing is changing the value and it is somehow still changing… that’s an indication that some other thread is also modifying that value.

I don’t know how the VR stuff works.

How would I go about rotating a node around its child’s location? The headset’s location and rotation can’t be changed so it’s parented to the observer. When you move in the real world, the location of the headset changes but not the observer. If you set the observers location to that of the headset, both locations are changed and the objects self-propel themselves forever. Is there anyways to rotate both objects, but keep the location for the headset the same? Offsetting the nodes resulted in this problem, but I could have done it wrong.

The node has a transform. The transform includes both rotation and translation. To rotate around a point other than the node’s center, you’ll need to combine both rotation and translation.

The real question I have: if you don’t want these things to transform together then why have you built the hierarchy this way? Maybe you have parents/children where you don’t really want parents/children.

I’ve found out the problem, the method’s location I copied included another transform I didn’t want. I found a different method that doesn’t displace everything, but now I need to factor in rotation. Thanks for the comments.

Just remember, really the only reason to have a parent-child relationship is so that the child works within the parent’s transformation reference frame.

In a case where you go to great lengths so subvert that transform relationship then it’s a good indication that it is not a parent-child relationship. So just be sure you haven’t misunderstood why nodes have children in the first place. Hint: it’s not an organizational structure for your code… it’s 100% about transformations. That’s it.