arne
Senior Devvie   
money is the worst drug- we should not let it rule
|
 |
«
Posted
2005-12-25 09:17:14 » |
|
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
|
 |
«
Reply #1 - Posted
2005-12-27 15:08:52 » |
|
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.
|
Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
|
|
|
arne
Senior Devvie   
money is the worst drug- we should not let it rule
|
 |
«
Reply #2 - Posted
2005-12-27 17:17:52 » |
|
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();
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
Senior Devvie   
money is the worst drug- we should not let it rule
|
 |
«
Reply #3 - Posted
2005-12-27 21:31:31 » |
|
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
Senior Devvie   
money is the worst drug- we should not let it rule
|
 |
«
Reply #4 - Posted
2005-12-29 13:56:42 » |
|
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
|
 |
«
Reply #5 - Posted
2005-12-30 13:34:50 » |
|
What do you mean when you say we should do something about collision-types ?
|
"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
|
|
|
arne
Senior Devvie   
money is the worst drug- we should not let it rule
|
 |
«
Reply #6 - Posted
2005-12-30 13:58:54 » |
|
(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
|
 |
«
Reply #7 - Posted
2005-12-31 09:27:08 » |
|
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 ?
|
"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
|
|
|
arne
Senior Devvie   
money is the worst drug- we should not let it rule
|
 |
«
Reply #8 - Posted
2005-12-31 10:50:26 » |
|
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
|
 |
«
Reply #9 - Posted
2006-01-02 23:51:19 » |
|
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.
|
Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
|
|
|
Games published by our own members! Check 'em out!
|
|
Amos Wenger
|
 |
«
Reply #10 - Posted
2006-01-03 14:43:02 » |
|
Yes please. But I gotta register to sf.net before
Cheers
|
"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
|
|
|
t_larkworthy
|
 |
«
Reply #11 - Posted
2006-01-04 19:35:49 » |
|
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?
|
Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
|
|
|
arne
Senior Devvie   
money is the worst drug- we should not let it rule
|
 |
«
Reply #12 - Posted
2006-01-04 20:03:27 » |
|
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
|
 |
«
Reply #13 - Posted
2006-01-04 21:58:16 » |
|
brilliant, cheers
|
Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
|
|
|
t_larkworthy
|
 |
«
Reply #14 - Posted
2006-01-12 00:26:56 » |
|
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?
|
Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
|
|
|
arne
Senior Devvie   
money is the worst drug- we should not let it rule
|
 |
«
Reply #15 - Posted
2006-01-12 13:50:38 » |
|
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
|
 |
«
Reply #16 - Posted
2006-01-12 15:38:54 » |
|
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.
|
Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.
|
|
|
|