A weird promlem(might have something to do with clod node)

I tried the Hello LOD tutorial, and made a small mistake. I forgot to write the line “rootNode.attachChild(meshParent);”. The result of this mistake should have been not showing meshParent. However, when I run the game, what happened is that clodNode appeared jumping.



I made some checkings, and found out that the problem is that during its path, the camera sometimes looks at the wrong direction. In the simple update, there is some code that points the camera to rootNode.getWorldBound().getCenter(), so I tried to change that center by changing the distance between the centers of meshParent and clodNode, via the x value of the local translation of meshParent (meshParent is shifted to the negative direction of the x axis). It appears, that if that distance is greater then or equal to 1.1, then the problem is gone. If that distance is less then or equal to 1.0, then the probelm remains. I didn’t check values between 1.0 and 1.1. I don’t think I need to explain why.



I am a jME noob, so this is as far as I could get with my debugging. I suggest to check it out and fix this problem before releasing version 1.0.

change simpleUpdate to this:


      
   protected void simpleUpdate() {
      // Get the center of root's bound.
      Vector3f objectCenter=rootNode.getWorldBound().getCenter(tempVa);

      // My direction is the place I want to look minus the location of the camera.
      Vector3f lookAtObject=tempVb.set(objectCenter).subtractLocal(cam.getLocation()).normalizeLocal();

      // Left vector
      Vector3f leftLocal = up.cross(lookAtObject, tempVc).normalizeLocal();
      tempMa.setColumn(0, leftLocal);
      // Up vector
      tempMa.setColumn(1, lookAtObject.cross(leftLocal, tempVd));
      // Direction vector
      tempMa.setColumn(2,lookAtObject);

      cn.setLocalRotation(tempMa);
   }

O.K., that worked. But I don't get it. If I add normalizeLocal while setting colums 1, the problem returns. I know that normalizeLocal makes the vector a unit vector of itself. Does the axes rotation cares about the length of the vectors? I thought it only checks their direction.

Actually, I believe this is a roundoff problem. the normalization doesnt allways make the vectors "true" unit vectors wich brakes the quaternion.fromRotationMatrix method.



by changing the quaternion method to count for the rounding, like this:



line 216:

from:

        if (t > 0f) {

to:

        if (t > 0.00001f) {



it should work even with your old code(the unchanged hellolod.simpleUpdate)



this is also mentioned in this matrix&quaternion faq here:

http://skal.planet-d.net/demo/matrixfaq.htm#Q55

under the topic:

How do I convert a rotation matrix to a quaternion?



is this something jme should add to cvs?

How tiny can the value be, perhaps we can use the float epsilon value in FastMath

not really sure how general the solution can be. since the t(trace) variable used in the comparison is built from three rounding-prone values I would at least have assumed that a value of 3epsilon would be required…but everything work at 1.5epsilon…since I haven't looked deeper in to it I don't dare give any answer at this time :wink: anyone else knows?

…by the way, when finding a more mathematical solution, this should be changed in the fromAxes method too…

I'll go with t > FastMath.FLT_EPSILON * 3 for now.