TrianglePickResult

Ok,…here the situation:



When using the new HottBJ-Exporter without converting the meshes to triangles (ctrl-t) it exports the Mesh as QuadMesh. (I forget about that quite often). Everything is perfect but when trying to make an accuarte

pick on the mesh you have the problem that there is no adequate QuadPickResult.



Most of the times you actually don't know that your geometry is a QuadMesh so you use TrianglePickResult.

TrianglePickResult uses something like a fallback. If the ray intersects a Bounding of a geometry != TriMesh it adds this as Pick but only with BoundingAccurancy. This behaviour is also mentioned in the comments. For me that doesn't make sense, does it? If I want an accuate pick I don't want a BoundingPick!



Minimum at this point would a warning about it. (For sure this didn't was a problem until now as noone really used QuadMeshs or if he knew about the pros and cons.)



I have two suggestions:



1)

Only add picks that really are TriMeshs and ignore the rest or give a warning/error about incompatible geometry intersected by the ray. (If you want BoundingAccurany you use BoundingPickResult(…))



That may lead to problems with applications that use that side-effect.



2)

Add every pick but give a warning.

Index: src/com/jme/intersection/TrianglePickResults.java
===================================================================
--- src/com/jme/intersection/TrianglePickResults.java   (revision 4648)
+++ src/com/jme/intersection/TrianglePickResults.java   (working copy)
@@ -33,6 +33,7 @@
 package com.jme.intersection;
 
 import java.util.ArrayList;
+import java.util.logging.Logger;
 
 import com.jme.math.Ray;
 import com.jme.scene.Geometry;
@@ -54,6 +55,8 @@
  */
 public class TrianglePickResults extends PickResults {
 
+   private static final Logger logger = Logger.getLogger(TrianglePickResults.class
+            .getName());
    /**
      * <code>addPick</code> adds a Geometry object to the pick list. If the
      * Geometry object is not a TriMesh, the process stops here. However, if the
@@ -73,6 +76,7 @@
       if (!(g instanceof TriMesh)) {
          PickData data = new PickData(ray, g, willCheckDistance());
          addPickData(data);
+         logger.warning(g.getName()+" is not a TriMesh so only BoundingAccuracy is used!!!!!!!!");
       } else {
             ArrayList<Integer> a = new ArrayList<Integer>();
             ((TriMesh) g).findTrianglePick(ray, a);




Nevertheless the best to avoid the problem is not to forget to use Triangles in blender for the exported meshes. :D

Sure I convert it to triangles. The point is I just want people prevent from getting stuck because they accidental got a QuadMesh and want to use trianglepicking which will not work(or not with the expected result)…so with a warning they would have a clue.



Mabye we should just kick QuadMesh…who needs this?

Why don't you want to convert the mesh to triangles? Triangles is the most efficient and supported format of geometry in jME and any real-time 3D rendering engine.

Additional to say:



For me it seems that TrianglePickResult adds PickData even if there are actually no TrianglePicks.

It's enough if the ray intersects the bounding and you have to check the number of TargetTris to be really sure about a triangle accurate intersection.



I would expect only PickData with TargetTri>0. Maybe I missed something!?


+1…

quad mesh, while conceptually useful, is having to be maintained along with Curve, Line, Point, Text, TriMesh despite the fact it brings nothing to the table so to speak…

I’m all for losing quad mesh, but do you think it will screw up a lot of projects for people using it?  I’m not sure how many are… most people seem to be in tune with the advantages of tri’s anyway.



That all said, this is probably a feature for 2.1, as the stable of 2.0 is coming in the near future