New OBB interface

Change title: New OBB interface

Created classes: CollisionResults2

Affected classes: Spatial (and all extending), OBBTree

Summary of changes: Easier way to do collision detection. Pretty self explanatory. Spatial has the empty methods. Spatial extending classes can impliment them if they want to update and find collisions. Calls are recursed to children. Intersections fire an intersection event. Mojo has the code.


public void Spatial::updateCollisionTree(){}

public void Node::updateCollisionTree(){
for (int i=children.size()-1;i>=0;i--){

public void Spatial::findCollisions(Spatial scene, CollisionResults2 results){}

public void Node::findCollisions(Spatial scene, CollisionResults2 results) {
if(getWorldBound().intersects(scene.getWorldBound())) {
//further checking needed.
for(int i = children.size()-1; i >=0 ; i--) {
((Spatial)children.get(i)).findCollisions(scene, results);

public interface CollisionResults2 {
    public void onIntersect(TriMesh a,int indexA,TriMesh b,int indexB);

            maggie=jbr.loadBinaryFormat(new ByteArrayInputStream(BO.toByteArray()));

        maggie.findCollisions(bullets,new CollisionResults2(){
            public void onIntersect(TriMesh a, int indexA, TriMesh b, int indexB) {
            private void makeBlue(TriMesh mesh,int triIndex){
                ColorRGBA toPaint;
                if (mesh.getName().equals("bullet"))
                int[] indicies=mesh.getIndices();

Other than the OBBTree update, I’m not real excited about this implementation. I don’t like overriding a TriMesh method to process collisions. If you would look at the new addition to CVS of all this you’ll see that CollisionResults has an array list of Collision Data. The Collision Data contains who was collided with and the Triangles they collided with. This allows it to handle more than a single collision with different nodes in a single pass.

I don’t mind the concept of a overriding a class for specific collision handling, I was planning on having CollisionResults abstract with an onCollision that the user may override if they wish, if they don’t it will work as it does currently.

I’ve been revamping the collisions and I’ve said that I want to take it on a couple times before, and that’s what I’ve been doing this last week. Also putting up a discussion for review when you’ve already written the code is skipping a few steps in the dev process which you signed off on. Not to mention you’ve changed code I worked on just last week without discussing at all.

I approve the update of the OBBTree being in spatial and inherited, but I’ll be starting a thread to talk about how Collisions should be handled to make it a community effort.

When you are writing the code for collisions keep inside that meny games do not need to know all the points of cotillions. Meny only need one point. There should be a option that returns just the point of cotillion and dose not waste time fining the rest.

Just because I wrote it doesn’t mean it has to go in… I wrote it to show what my idea would look like in practice.

This method allows you to handel more than a single collision with different nodes in a single pass as well. All a user would do is impliment a class that stores data instead of processes it. It’s less code overall and more extendable, being just as fast. Users can even have collision trees for wacky stuff like text and process those with this implimentation. You mentioned you don’t like overriding a TriMesh method to process collisions. The only other way, would be to use some 3rd party class like we did before with BoundingVolume intersections (unless I’m missing something). This code seems intuitive, but it may not be.

I don’t claim it’s the only way. Maybe post some pseudo-code for what you’re thinking about in a Dev thread would be good.

"Cep21" wrote:
Just because I wrote it doesn't mean it has to go in.... I wrote it to show what my idea would look like in practice.

I agree with Cep21 motiveativation. I think what he did should be alowed.