Will triangle resolution collision detection be forced in this new system, or can we still stop at the boundings if that is good enough for our app?
Currently if TriMesh does not have a collisionTree set, it will stop at the boundings.
However, we could put a switch in if you don’t need triangle accuracy.
Source? I wana try it out when I get home, but that won’t be till tonight.
Well, there isn’t much source yet, until the final review, this is just the discussion phase… design decisions etc.
So what your saying is that if a collision HAS occured at BoundingVolume method, we go down to triangle method?
If thats the case, that would be awsome 
It would also be nice if the triangle collision tree is set automatically so I dont have to find all the trimeshes and call that myself. I can just load a model, and check collision automatically. Thats ofcourse from a user’s point of view.
It would also be nice if the triangle collision detection is ON by default and a switch would turn it of back down to bounding volume level.
These are my views anyway.
DP
So what your saying is that if a collision HAS occured at BoundingVolume method, we go down to triangle method?
basically yes, think of the old collision detection, instead of stopping at the trimesh level bounding, it continues on to the OBBTree if it exists.
It would also be nice if the triangle collision tree is set automatically so I dont have to find all the trimeshes and call that myself. I can just load a model, and check collision automatically. Thats ofcourse from a user's point of view.
You only have to call the updateCollisionTree method in TriMesh and the OBBTree is built for you.
ray.instersects(scene, customCollision);
About that, I think it would be better if it was scene.intersects(ray) instead. It would be closer to how we do OBBTree intersections.
It will also contain an abstract method that can be overridden by the user to handle these collisions. This of course is application specific.
Will that be similar to what I submitted to you? If so, that's cool. Also, there needs to be methods that return boolean if a ray intersects and boolean if two meshes intersect. Those are faster, and sometimes users don't need to know every intersection, they just need to know if one exist.
this is just the discussion phase... design decisions etc
What confused me is that I inferred from the email this was for code, and the developer forum was for post like this. Does this mean development ideas go here too?
About that, I think it would be better if it was scene.intersects(ray) instead. It would be closer to how we do OBBTree intersections.
The reason I am making it ray.intersects is because it is the ray that is colliding with the scene (ray shooting out). That is, you are checking to see if this ray collides with the scene anywhere. I felt this makes more sense from a user perspective.
Will that be similar to what I submitted to you? If so, that's cool. Also, there needs to be methods that return boolean if a ray intersects and boolean if two meshes intersect. Those are faster, and sometimes users don't need to know every intersection, they just need to know if one exist.
Yes, it's pretty similar to how you handling it.
I have some ideas about the boolean (I agree that a simple true would be nice), I've put it on the list.
The boolean would work exactly as it does now, but just return true when you hit your first intersection. Return false if none hit, and return the recursive calls if you have to recurse.
yep.
You only have to call the updateCollisionTree method in TriMesh and the OBBTree is built for you.
Right, but what if I want to load a model?
Id have to do this:
Node model = loadPlayer();
for (int i = 0; i < model.getQuantity(); i++) {
Spatial spat = mode.getChild(i);
if (spat instanceof TriMesh) {
((TriMesh)spat).updateCollisionTree();
}
}
And that method doesn't take into account nodes in the model as well! So it has to be recursive.
Wouldn't it be easier to do that automatically (from a users perspective again).
DP
A change from Cep is in where updateCollisionTree is in Node as well.
Will be in, I should say.
thats kewl then 
DP
Ok, so the additions will be:
CollisionResults class that is extensible to allow for collision handling defined by the user.
Single call to determine the collision results.
– switch to all for triangle or bounding accuracy
– allow for simple boolean returns (true/false if it collided or not).
– picking will be handled in the same fashion.
The reason I am making it ray.intersects is because it is the ray that is colliding with the scene (ray shooting out). That is, you are checking to see if this ray collides with the scene anywhere. I felt this makes more sense from a user perspective.
How would you code this without using instanceof, casting, or simply calling a spatial node to do the work, all with allowing users to define their own Spatial/ray intersection code without having to modify the base jME classes? It can't be done because ray doesn't know what kind of spatial it's getting. In the code I sent you, when you pass the ray to the spatial, then the spatial defined function covers how to do intersection testing without any of that mess. It's extendable for the user to define their own Spatial/ray test, and it keeps the ray class basic. Passing the spatial to the math class is equivalent to passing a TriMesh to a Matrix3f. It's just a strange way to do it. And in a math POV, the ray intersects the Spatial just as much as the Spatial intersects the ray.
the interface is ray.intersects(Spatial)…
at the core when it calls your code, it does the Spatial.intersects(this)
switching to your method.
EDIT: It is calling it like you mention, it’s only the interface that is different.
Ok, just to let you guys know I am still working on this stuff (just not nearly as much as I’d like), I’m posting a little update. I was able to work on it today and got a lot done.
First, CollisionResults.
CollisionResults is now an abstract class with two methods as abstract:
addCollision(Geometry, Geometry)
processCollisions()
It still contains the other methods for getting/adding CollisionData.
There are two implementations of CollisionResults: BoundingCollisionResults and TriangleCollisionsResults they both implement addCollision. BoundingCollisionResults simply add a collision data object with the two geometrys that collided. TriangleCollisionResults call Cep’s OBBTree, and add a CollisionData with the Geometry’s that collided and the triangles that touched. The processCollisions methods are empty and the user can override them to handle collisions as needed.
CollisionData now stores the source mesh as well as the target mesh. This became important when testing models. We need to know what part of the model hit the scene if the model has multiple trimeshes. Basic addition, fairly obvious.
Node has updateCollisionTree as per Ceps suggestion.
TriMesh’s hasCollision method has altered slightly. After it is determined that two Geometrys have hit, instead of directly creating the CollisionData and determining the OBBTree hit, etc. It simply calls:
results.addCollision(this, (Geometry)scene);
Allowing the collision results implementation to determine the best way to store the results.
Those are the major changes. So the process of collision detection might be something like:
//create collision results (in this case we don't need to know the triangle)
//we want to print out if something hit or not, so we'll override the process
//collisions method.
results = new BoundingCollisionResults() {
public void processCollisions() {
if (getNumber() > 0) {
text.print("Collision: YES");
} else {
text.print("Collision: NO");
}
}
};
//...
results.clear();
t.hasCollision(scene, results);
results.processCollisions();
That's how it sits currently. I'm going to create a way to do a single method call, that will do the hasCollisions and processCollisions in one call. As well as add the simple boolean return (if you don't care about results, just if they hit or not). Then picking (which will be the same design).
Ok, got the boolean method in, also renamed some methods to make sense, findCollisions and hasCollision are the two methods to use. Doing a bit more testing, then I’ll get to picking. Hopefully, I’ll get this complete and ready to submit before much longer. Sorry about the delay.