JOODE: Geoms and Spaces

arne · December 25, 2005, 9:17am

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 · December 27, 2005, 3:08pm

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 · December 27, 2005, 5:17pm

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.

	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);
					}
				}
			}
		}

	}

arne · December 27, 2005, 9:31pm

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 · December 29, 2005, 1:56pm

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)

eMKa · December 30, 2005, 1:34pm

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

arne · December 30, 2005, 1:58pm

(from Geom)

	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…)

eMKa · December 31, 2005, 9:27am

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


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 :


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 · December 31, 2005, 10:50am

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

[quote]And in the collision code, there’s probably something like that :

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

[/quote]
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 · January 2, 2006, 11:51pm

Hello! Back from hols!

[quote]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)
[/quote]
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.

eMKa · January 3, 2006, 2:43pm

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

Cheers

t_larkworthy · January 4, 2006, 7:35pm

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 · January 4, 2006, 8:03pm

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 · January 4, 2006, 9:58pm

brilliant, cheers

t_larkworthy · January 12, 2006, 12:26am

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 · January 12, 2006, 1:50pm

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 · January 12, 2006, 3:38pm

[quote]it’s not that urgent, is it?
[/quote]
Nah not at all. Feel free to do something else if you get stuck. HashSpace is a really useful Space as well.