Exact Collision detection in

jmetest.intersection.TestOBBTree;





It’s somewhat sloppy right now. I plan on cleaning up the use but it’s there.

Results are great Cep, however, I’m not thrilled with some of the implementation. Especially, the addition of findIntersection in TriMesh.



If you look at CollisionDetection you’ll see there was a place for the tree collision check:


if (Intersection
                .intersection(test.getWorldBound(), scene.getWorldBound())) {
            if ((scene instanceof Node)) {
                Node parent = (Node) scene;
                for (int i = 0; i < parent.getQuantity(); i++) {
                    hasCollision(test, parent.getChild(i), results);
                }
            } else {
                //find the triangle that is being hit.
                //add this node and the triangle to the CollisionResults list.
                results.addGeometry((Geometry) scene);
            }
        }



This is where that code should be placed.

Other than that, it looks great.

I’ll see what I can pull off when I get home.

There’s an implimentation problem though. An intersection is 4 pieces of information, per intersection: Mesh a, Mesh a’s triangle index, Mesh b, Mesh b’s triangle index. Lets say this gets stored in a list. How does someone go about changing colors like I did in my program? You look through the list… but for every iteration you need to get mesh A, then mesh A’s color information, mesh A’s index information, Mesh B, mesh B’s color information, mesh B’s index information: Change both. Remember that you changed A and B somehow, then finally update the colors of every mesh that changed.



I’ld like to change CollisionDetection to an interface that users pass to the testIntersection class. This way, users don’t need to go through the memory overhead of storing things into large list and accessing the list and the list’s information multiple times. They can simply define the trueIntersection() function to color the triangles (or whatever they want to do) when it’s called.

Also, is there a reason for wanting to use the Intersection class? It doesn’t feel very OOP, but that’s just me.



Also, I’ll need to somehow store the information of the TriMesh’s worldRotation as a Matrix3f during intersection testing because I’m doing a lot of point rotations and it’s much faster to rotate with Matrix3f than Quaternion. How do you suggest that happen? Give me some kind of design and I’ll see if I can fit it into the design without sacrificing speed.

"Cep21" wrote:
Also, is there a reason for wanting to use the Intersection class? It doesn't feel very OOP, but that's just me.

I suggested using a controller for collisions awhile back but it was rejected because it would take up two much memory.

Moving the intersection code to the bounding volumes is on my todo list.



I am more than willing to talk about how to improve the design of the collision detection stuff, but what I would like (for the time being) is collisions to be standard. So when you get your CollisionResult object it will contain the arrays of the triangle indices for the two spatials colliding.



If you get it working with the current collision detection for now, we then have collisions in a single place. We’ll have a basis to which to discuss ways to improve it in the near future.



Basically, I’m trying to get everything tighted up before major changes are made. So, if you can move that into collision detection it would make things easier for me to organize.