findPick() problem

Troubleshooting General Help
1

I have a strange problem I cannot solve. It has to do with the findPick method and i call it like this:


selectionNode.findPick(mouseRay, results);



If I allow this line to be executed, some shared meshes added to this node (selectionNode) will after that line be, what looks like, randomly displaced. Without this findpick everything works fine. I don't do anything with the result of the pick.

So my question is, does this find pick change something for the nodes? Shouldn't it only be an observer?

The picking itself works fine and when checked, returns the correct result.

I nearly forgot to say that this error only arises if the findpick hits an mesh and I try to add that specific mesh afterwards to the selectionNode. (I add it as a shared node)

I tried to follow it's execution in the debugger and it does a lot of manipulating in the shared meshes which I don't fully understand. Maybe someone knows what might go wrong with the findpick method?

/Robert
2

I only used the picking-functions with "normal" nodes and had no problems.

Perhaps you can provide a bit more information what and how you are picking?

3

Thanks for the fast response :slight_smile:



I added some more info to my first post, at the same time as you were responding.



I have a lot of shared nodes attached to the selectionNode. When I do the picking and it hit's one of the shared nodes meshes, that particular mesh will be randomly displaced if I try to add it the the selectionNode (as a new shared node).



The meshes that already is attached to selectionNode when i perform the picking will not be displaced. Only meshes I try to add afterwards.



Meshes that I have not "hit" with findPick works just fine… until I hit them  :?

4

Ok, I added a small change to jME 2 and now it works… did the following:


Index: SharedMesh.java
===================================================================
--- SharedMesh.java   (revision 4105)
+++ SharedMesh.java   (working copy)
@@ -39,6 +39,7 @@
 import java.util.logging.Logger;
 
 import com.jme.bounding.BoundingVolume;
+import com.jme.math.Quaternion;
 import com.jme.math.Ray;
 import com.jme.math.Vector3f;
 import com.jme.renderer.ColorRGBA;
@@ -473,11 +474,21 @@
      */
     @Override
     public void findTrianglePick(Ray toTest, ArrayList<Integer> results) {
-        target.setLocalTranslation(worldTranslation);
+       // save a backup
+       Vector3f backupTranslation = target.getLocalTranslation();
+       Quaternion backupRotation = target.getLocalRotation();
+       Vector3f backupScale = target.getLocalScale();
+       
+       target.setLocalTranslation(worldTranslation);
         target.setLocalRotation(worldRotation);
         target.setLocalScale(worldScale);
         target.updateWorldBound();
         target.findTrianglePick(toTest, results);
+       
+     // reset from backup
+        target.setLocalTranslation(backupTranslation);
+        target.setLocalRotation(backupRotation);
+        target.setLocalScale(backupScale);
     }



Don't know if this is a bug in jME or in my code somewhere else.. But now it works for me at least :)
5

Would it be possible to create a test showing the before and after behavior (if you can and others can confirm the issue; then this should definitely be patched :slight_smile: ).

6

Yes, I might do that after the home exams I currently have.

7

3 object creations per pick…



I don't understand what the original code does in the first place. Why is it overwriting Local vectors with World vectors?


8

For shared nodes (gets the real location, and sets the actual geometry to that location)…

Haven't had an issue myself, but that's not to say there might not be one.

sigh guess I will have to create a test myself…



(good catch on the object creation, that would be a bad place to create a bunch of objects ;))

9

Moving the object creation to instance variables doesn't seem a good idea unless we prove it will work.



The function findTrianglePick may be being called recursively, which would justify the 3 object creations.



I don't know if this is the case, hence I would like to understand what the function does and why it needs to copy world vectors to local vectors.

10

Curiosity got the better of me on this one so I took a look at the test case showing the bug.

Maybe it doesn't show the proper problem, but I don't think the fix described above is necessary.



The problem I see in this test case occurs because in the mouseclick handling code, you create a new SharedMesh. To create this you need to use the "original" TriMesh object as the target mesh data. As this object is modified to hold the coordinates/rotation etc from the last pick, its left holding whatever the last value was - therefore when you create a new one and attach it to a Node, its attached with the offset coords of the last shared object checked.

Resetting this to 0,0,0 before creating a new SharedMesh fixes the problem in the existing example - of course there I am assuming the original translation should be 0,0,0 (and ignoring rotation and scale for now).






      if(mouseDown && !MouseInput.get().isButtonDown(0)) {
         Node test = new Node();

                        // Added this line
                        s.setLocalTranslation(0,0,0);

         SharedMesh sm = new SharedMesh("SIGH THIS", s);
         test.setLocalTranslation(testVec.clone());         
         test.attachChild(sm);
         page.attachChild(test);
         rootNode.updateRenderState();
      }



If this is a solution to the problem, maybe SharedMesh constructor should be extended to either take a set of trans/rot/scale values, or internally set them to defaults?