Collision System

Engines, Libraries and Tools Xith3D Forums
#1
#2

[quote]Let’s see how many supporters…
Maybe I will start a new project with an independent collision system or release our source code…
[/quote]
Um… how are collisions done in Xith? Isn’t the current collision stuff broken? I know that the demo is, so would your system be added to the xith core?

#3

The xith3d collision system is broken. It misteriously just broke one release and noone knew why. Nobody was really using it at the time so it went unnoticed for a while.

I don’t think it should be hard to fix - just a case of grabbing an old release where it did work and finding what changed.

Personally I use (and develop) Odejava which handles collision and physics very well and I won’t be switching any time soon.

Will.

#4

[quote]The xith3d collision system is broken. It misteriously just broke one release and noone knew why. Nobody was really using it at the time so it went unnoticed for a while.

I don’t think it should be hard to fix - just a case of grabbing an old release where it did work and finding what changed.

Personally I use (and develop) Odejava which handles collision and physics very well and I won’t be switching any time soon.

Will.
[/quote]
How does Odejava interface with Xith3D? Does it use Xith’s bounds? Because I’m having some really serious and annoying problems with just applying bounds, as I intended to use them with collision in Xith.

#5

No, it is the other way round. Odejava is display-API independant, you create your objects in the Odejava world. Then, if you like, you can create counterpart Xith3D (or Java3D, or jME, etc) objects and link them to the Odejava ones so their positions are synched. There are methods to automatically generate Xith3D objects from their counterparts. Bounds could potentially be used to automatically generate Odejava objects from Xith3D ones but this has not been implemented.

Will.

#6

[quote]No, it is the other way round. Odejava is display-API independant, you create your objects in the Odejava world. Then, if you like, you can create counterpart Xith3D (or Java3D, or jME, etc) objects and link them to the Odejava ones so their positions are synched. There are methods to automatically generate Xith3D objects from their counterparts. Bounds could potentially be used to automatically generate Odejava objects from Xith3D ones but this has not been implemented.

Will.
[/quote]
You’ll have to admit it’d be much more convenient if Xith had a working built-in collision system (wouldn’t have to double code, and it’d be one less library to send out with games). Hopefully DonCrudelis’s will be part of Xith. And if someone could just tell me why the bounds are behaving like nuts I’d be more than happy to spare some time to researching Xith’s broken collision system and fixing it up and maintaining it. As it stands now, my time is very limited as I’m trying to get animation working in this 3DS loader i’m porting to Xith, school, and working on my game.

#7

Btw we are working on a port of ode to java (not a wrapper) but it won’t be done in a long time.

Alonzo

#8

I was using odejava before, but I didn’t want to add bounding boxes (e.g to my terrain) so I started to make an own system.

If somebody knows how to use odejava with Shape3D’s and TransformGroups (I want it to check triangles even if a triangle has moved) please reply.

Thanks

Alonzo

#9

The separation of ODE and Xith is eminently sensible.

Cas :slight_smile:

#10

IMHO, the basic question is: Whom are you targeting with Xith3D?

1.) Experienced developers with a good knowledge of how 3D works? In that case, you can rely on ODEJava or let the dev write a collision system that suits him/her. (But maybe such a person wouldn’t use a 3D API like Xith anyway but write his own stuff…)

2.) Users with little or no knowledge of 3D? In that case, at least a basic collision system should be include IMO. If he isn’t happy with it anymore one day, he’s maybe not longer in this category but in the first. He can then move on to a complete physics engine or write his own stuff anyway. But for starters, a basic collision system that works “out-of-the-box” is a great thing.

#11

If somebody wants the source for our rudimentary collision detection,
take a look here:
https://xith-tk.dev.java.net/servlets/ProjectDocumentList?folderID=2404

#12

nm

#13

For those who don’t have Java 1.5 for various reasons (like me, waiting for OS 10.4… hurry up Apple), I’ve “ported” the CollisionSystem.java file to work with version 1.4 here (please tell me if I made any mistakes because I haven’t used Java 1.5).

#14

When I run the BallTest demo I sometimes get this error after pressing space too fast, seemingly before it has time to destory (?) the shooting object:

java.util.ConcurrentModificationException
        at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:448)
        at java.util.AbstractList$Itr.next(AbstractList.java:419)
        at org.css.CollisionSystem.update(Unknown Source)
        at org.css.BallTest.update(Unknown Source)
        at org.css.BallTest$1.run(Unknown Source)

Is this a problem caused by my “port” or is it just a problem with the code in general?

Edit: I think it might be that I commented this out:

private List < NodeCollisionHandler > moList = new java.util.concurrent.CopyOnWriteArrayList < NodeCollisionHandler > ();

Because Java 1.4.2 doesn’t have this class. Any ways to make up for this?

Also, Alonzo, would it be alright if you could write Java 1.4 compatable code? I know it’s a pain but it would cause a lot of people (not just me) to miss out on this and make it a pain to convert the code each time you release it. ???

#15

Oops, I didn’t think about that :D.

I promise to write in 1.4 code in the future.

p.s Thank you for porting my code :slight_smile:

#16

Also the ConcurrentModificationException occours when the list is used while adding a new object to it.
I am going to make my own CopyOnWriteArrayList to fix this problem.

I will post it when it’s done.

Alonzo

#17

[quote]Also the ConcurrentModificationException occours when the list is used while adding a new object to it.
I am going to make my own CopyOnWriteArrayList to fix this problem.

I will post it when it’s done.

Alonzo
[/quote]
Awesome, and if I find out that Odejava is too much of a pain (which seems like it’ll be the case), then I’ll gladly work on this collision system with you :slight_smile: