JOODE: Geoms and Spaces

[arne]

I checked out now how this works with Spaces in JOODE and I realized, that Geoms are saved in linked lists and that the next-Geom functions are directly implemented in Geom.

Is this wise? This way the data structure in which the Geoms are saved is predefined and if a better data-structure should be used, the old will still take memory.

Why aren't Geoms stored directly in the Spaces? That would make much more sense to me. Maybe it's because of the non-OO design of ODE.
If there are no objections about this, I will try to change it.

[t_larkworthy]

Yeah its not ideal. Its just the way I think the C/C++ buffs are used to. All stuff in JOODE is like that at the moment

All the bodies in a world are stored as a link list from the world object.
A bodies geoms are a link list in the body object.

it goes on.....

Yeah go on and change it. There is no need.

[arne]

Now only a simple problem with iterators
I'm wondering what kind of data-structure I should use for simple space, the structure has to be fast with add,remove and the collide code below. add and remove always get called, when a contained Geom gets set to be dirty (I could ofcourse also change that) and collide gets called for Space-interior collisions.
There are three possibilities of data structures to be used:
- a list : a list has the advantage of listiterator (see the code below), but add and remove might be slow
- a set : a set has the advantage of fast add and remove (e.g. HashSet), but no listiterator
- a new datastructure like a set with something like a listiterator or even better : from the performace view the best solution, but it would take loads of work for this bit of performance boost - and this is only for simple space.

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17

public void collide(Object data, NearCallback callback) {       cleanGeoms();       // intersect all bounding boxes      for (ListIterator<Geom> li1 = list.listIterator(); li1.hasNext();) {          Geom g1 = li1.next();          if (g1.isEnabled()) {             for (ListIterator<Geom> li2 = list.listIterator(li1.nextIndex());li2.hasNext();) {                Geom g2 = li2.next();                if (g2.isEnabled()) {                   collideAABBs(g1, g2, data, callback);                }             }          }       }    }

Games published by our own members! Check 'em out!

[arne]

ok went with the set way of doing this - but I've got now some strange errors with dirty geoms and updating of the AABBs - It somehow resets clean Geoms to dirty without calling the dirty method grrr... I believe there's somewhere a crude hack I missed in my changes...

[arne]

ok solved - forgot to set parent_space

It's in cvs now - I'll try to implement something like OctTreeSpace now - It should be fairly simple, so I'll do this as an exercise.
We also should do something about the handling of collision-types (I already added a new dOctTreeSpaceClass in Geom, but I think its dirty and unclean)

[Amos Wenger]

What do you mean when you say we should do something about collision-types ?

[arne]

(from Geom)

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20

public static final int dSphereClass = 0,      dBoxClass =1,      dCCylinderClass =2,      dCylinderClass=3,      dPlaneClass=4,      dRayClass=5,      dGeomTransformClass=6,      dTriMeshClass=7,      dFirstSpaceClass=8,      dSimpleSpaceClass = dFirstSpaceClass,      dHashSpaceClass=9,      dOctTreeSpaceClass=10,      dQuadTreeSpaceClass=11,      dLastSpaceClass = dQuadTreeSpaceClass,            dFirstUserClass = 12,      dLastUserClass = dFirstUserClass + dMaxUserClasses - 1,            dGeomNumClasses = dLastUserClass + 1;

those classes are only needed for the decision of the collision-type. (e.g. BoxBox-Collision...)

[Amos Wenger]

Ah, I see.
And in the collision code, there's probably something like that :

1   2   3   4   5

if((collisionType1 == dBoxClass) && (collisionType2 == dSphereClass)) {   detectCollisionBoxSphere(geom1, geom2); } else if((collisionType2 == dBoxClass) && (collisionType1 == dSphereClass)) {   detectCollisionBoxSphere(geom2, geom1); }

If it's as this, then we could simply replace it by :

1   2   3   4   5

if((dBoxClass.class.isInstance(geom1)) && (dSphereClass.class.isInstance(geom2)) {   detectCollisionBoxSphere(geom1, geom2); } else if((dSphereClass.class.isInstance(geom1)) && (dBoxClass.class.isInstance(geom2)) {   detectCollisionBoxSphere(geom2, geom1); }

Maybe it's not like that, and in that case I would better take a look at the source before posting irrelevant material.
Oh, where's JOODE CVS ? On sourceforge.net or on dev.java.net ?

[arne]

I'm still using the sourceforge cvs (my developer status is still pending at java.net)

And in the collision code, there's probably something like that :

1   2   3   4   5

if((collisionType1 == dBoxClass) && (collisionType2 == dSphereClass)) {   detectCollisionBoxSphere(geom1, geom2); } else if((collisionType2 == dBoxClass) && (collisionType1 == dSphereClass)) {   detectCollisionBoxSphere(geom2, geom1); }

nope - the colliders are saved in a 2-d array with dBoxClass, dSphereClass as indices. So it takes O(1) to get the correct collider pair.

mmh maybe a Hashtable would deal with this problem nicely...

[t_larkworthy]

Hello! Back from hols!

We also should do something about the handling of collision-types (I already added a new dOctTreeSpaceClass in Geom, but I think its dirty and unclean)

Yeah the collision type number system is 'way' rubbish. A hash table of class types would be best. But it seems you have done all that sensibly allready 

We are still using sourceforge at the moment. No switch to java.net yet. Do you want developer access Bluesky? PM me if you do.

Games published by our own members! Check 'em out!

[Amos Wenger]

Yes please.
But I gotta register to sf.net before

Cheers

[t_larkworthy]

Arne, I am getting lots of these messeges when I run the tests now:-

"dirty not empty when getting num of geoms!!"

It doesn't sound good... can you fix it please?

[arne]

damn I hoped this kind of error doesn't occur - at least it didn't occur when I tested it

EDIT: fixed... wasn't that serious as it might have sounded at least I hope there no other errors in that respect. Actually it was one of the least serious messages you could get from my code.
If you still get such messages, tell me.

[t_larkworthy]

brilliant, cheers

[t_larkworthy]

I just though I would give myself a break from implementing joints by porting the BoxBox collider to see if that fixes the problems with it. I must say the C code for that functionality is particuarly awful. Those horrible TST definitions!.  Anyway it looked a much longer job than I expected so I have left it. But yeah, I must admit arne you had your work cut out there.

Are you getting anywhere with your OctTree thingy?

[arne]

I've some issues there, because I wanted to implement it, that it automatically creates sub-spaces automatically.
I would have probably solved them, if I had more time...
so work's in progress

But anyways - it's not that urgent, is it?

[t_larkworthy]

it's not that urgent, is it?

Nah not at all. Feel free to do something else if you get stuck. HashSpace is a really useful Space as well.