next »

[Marvin Fröhlich]

This thread shall solve as a discussion about a general JOODE abstration for scenegraphs (like Xith).

[Marvin Fröhlich]

In CollideableType there is Shape3D used. This shouldn't be done, since the abstraction layer should be included into the JOODE project without knowledge about the using scenegraph.

I don't know, what actually is needed at this point. Maybe it's just the name. Then simply write an interface NamedNode with a getName() method or what ever. Or simply make it Object. But there cannot be a xith type used in it.

Do you agree?

Marvin

['n ddrylliog]

In CollideableType there is Shape3D used. This shouldn't be done, since the abstraction layer should be included into the JOODE project without knowledge about the using scenegraph.

I don't know, what actually is needed at this point. Maybe it's just the name. Then simply write an interface NamedNode with a getName() method or what ever. Or simply make it Object. But there cannot be a xith type used in it.

Do you agree?

Well, actually I don't agree with you.

What I'm actually doing is a "Xith3D abstraction layer for collision engines", not a "JOODE abstraction layer for scenegraphs". So this layer is contained in Xith, totally independent from JOODE, and the JOODE implementation of it is locally on my machine (for now, when it's ready it will be shipped as a separate jar).

And anyone can implement his own collision engine for Xith3D, just implementing interfaces from the layer.

[Marvin Fröhlich]

In CollideableType there is Shape3D used. This shouldn't be done, since the abstraction layer should be included into the JOODE project without knowledge about the using scenegraph.

I don't know, what actually is needed at this point. Maybe it's just the name. Then simply write an interface NamedNode with a getName() method or what ever. Or simply make it Object. But there cannot be a xith type used in it.

Do you agree?

Well, actually I don't agree with you.

What I'm actually doing is a "Xith3D abstraction layer for collision engines", not a "JOODE abstraction layer for scenegraphs". So this layer is contained in Xith, totally independent from JOODE, and the JOODE implementation of it is locally on my machine (for now, when it's ready it will be shipped as a separate jar).

And anyone can implement his own collision engine for Xith3D, just implementing interfaces from the layer.

Cool. That's... great

[hawkwind]

Whatever you end up doing please have the capability to walk into and slide along walls in a "first person shooter" kinda way.

[Marvin Fröhlich]

Whatever you end up doing please have the capability to walk into and slide along walls in a "first person shooter" kinda way.

+1... But I think JOODE is already able to. So it will be possible,

Marvin

['n ddrylliog]

Whatever you end up doing please have the capability to walk into and slide along walls in a "first person shooter" kinda way.

Nothing's easier, dear.

The collision information gives you the contact position, normal, length and collideables involved. So what you want to do is just moving collideable 1 along the normal vector scaled by the "collision length".

Or if you want a slightly better way, just compute a vector perpendicular to the normal and project the "scaled normal vector" on it, then apply this move to your collideable 1.

Bah, I'm not clear enough, I guess. Examples will do Sometimes a small demo is worth a thousand pages of tech doc.

[Patheros]

Hey Amos, hows the abstraction layer going? My project actually uses its own Physics system so I'm more than interested in what your doing. I'm wondering if you could point me at some code or documents so I can see how you intend to implement the layer. One of the biggest questions I have is on whether the physics layer is built on top of the graphics or visa versa. The reason I ask is its my intent to be able to run a dedicated server and make it work without a graphics card and preferably even without Xith. Any thoughts and pointers towards things to read would be greatly appreciated.

['n ddrylliog]

Hey Patheros,

kind from you to take news. The abstraction layer's going well, thank you. In fact the main issue now to use it in games is is doesn't abstract the physic simulation part, just the collision one. But I'll include physic simulation (I mean, with forces, constraints et al.) in the future.

About implementation you can look at org.xith3d.physics.collision package.
I have implemented the abstract layer for joode (see attached jar), it works pretty well, with "Sphere", "Box", and "Capsule" primitives.

It doesn't depend on Xith3D (Shape3D is mentioned in CollisionType but it is normally not needed if you don't use it).

[horati]

How's this coming since the last update?  I'm trying to connect a collision engine to the BSPLoaderTest but am having problems using the Xith collision engine.  Specifically, I'm having problems doing some basic things like attaching the AvatarNode to the same location as the EgoInputAdapter, mapping the inputs between the classes, etc.  It seems that the 2 APIs were written in isolation and do not map very well.  Am I missing something?  Is there a tutorial on this somewhere?  Are you nearly finished connecting Joode so I should just wait?

[Marvin Fröhlich]

How's this coming since the last update?  I'm trying to connect a collision engine to the BSPLoaderTest but am having problems using the Xith collision engine.  Specifically, I'm having problems doing some basic things like attaching the AvatarNode to the same location as the EgoInputAdapter, mapping the inputs between the classes, etc.  It seems that the 2 APIs were written in isolation and do not map very well.  Am I missing something?  Is there a tutorial on this somewhere?  Are you nearly finished connecting Joode so I should just wait?

The collision abstraction for JOODE is almost complete. Directly ask Amos for more info. The Xith collision system will be removed then.

Have a look at org.xith3d.test.game.bsp.BSPGameTest. It contains some commented code blocks, which use the Xith collision system. So what you are trying to achive is already done. But it performs very bad. I don't know, if it even currently works.

Marvin

['n ddrylliog]

How's this coming since the last update?

I have been a bit slowed down by school but now I have more time. Now that the collision stuff is working pretty well (I had to debug lots of things since latest JOODE updates), I'm beginning to consider the whole physic simulation stuff.

I'm trying to connect a collision engine to the BSPLoaderTest but am having problems using the Xith collision engine.  Specifically, I'm having problems doing some basic things like attaching the AvatarNode to the same location as the EgoInputAdapter, mapping the inputs between the classes, etc.  It seems that the 2 APIs were written in isolation and do not map very well.

Absolutely true. And it's gonna be fixed soon.

Am I missing something?

Probably. The MemberLink class, in org.xith3d.utility.general (If I remeber correctly).

Is there a tutorial on this somewhere?

Not yet. That'll come. The API isn't stable at all right now.

Are you nearly finished connecting Joode so I should just wait?

Technically JOODE is perfectly connected to XPAL. The only thing is XPAL doesn't support everything JOODE does. So plane and Trimesh aren't there for now. (It's coming, don't worry).

I hope i?ll have enough time to connect all that.

Keeping you informed. (And note : the .jar attached on this forum is by far outdated. When the JOODE projects upgrades to the latest Xith3D + OpenMali I'll put the XPAL-JOODE impl in the JOODE SVN).

[hawkwind]

I had a similar Xith collison/egoinput complication I never figured out.  Basically my Avatar stopped tracking the view.  I eventually stole functionality from the ego code for myself.  A possible driver for testing/demo would be

http://opensource.dazoot.ro/maze3d/ a Xith based maze collision demo

[Marvin Fröhlich]

Another topic, that belongs to this thread:

You know, I have managed to get the HUD picking GC-cheap now, which will be done for PickingLibrary, too, as well as for GLSelect picking.

As far as I understood it, a new Collision instance is created for each collision, that has been detected by the CollisionManager. These instances have to be managed/stored by a CollisionHeap (or a more common ObjectHeap) like I did for HUDPickResults. Otherwise collision detection will be very GC expensive.

Another solution could be to pass a buffer List instance to to checkCollisions() methods and a single Collision instance to the checkCollision() method. This way, it won't produce any GC by itself. This would avoid the need to call a deallocate() method on the heap agter the Collision instance has been handled.

Marvin

['n ddrylliog]

Hey, thanks to pay attention to that.

Another solution could be to pass a buffer List instance to to checkCollisions() methods and a single Collision instance to the checkCollision() method. This way, it won't produce any GC by itself. This would avoid the need to call a deallocate() method on the heap agter the Collision instance has been handled.

I quite don't like this one solution : it's just pushing back the problem to the user.

As far as I understood it, a new Collision instance is created for each collision, that has been detected by the CollisionManager. These instances have to be managed/stored by a CollisionHeap (or a more common ObjectHeap) like I did for HUDPickResults. Otherwise collision detection will be very GC expensive.

This one is better, I think..

OR maybe why not use ONLY collision listeners which use anyway only one Collision instance ?