ODEJava bug

Game Mechanics
#1

I found a bug in OdejavaToXith3D.


if (!(odejavaGeom instanceof GeomTransform) && !(odejavaGeom instanceof PlaceableGeom)) {
	t3d.setIdentity();
	
	// Rotate
	t3d.set(((PlaceableGeom) odejavaGeom).getQuaternion());  <-------------------
	// Translate
	t3d.setTranslation(((PlaceableGeom) odejavaGeom).getPosition());
	// Scale objects visually
	if (scale != 1) {
		t3d.setScale(scale);
		t3d.scaleTranslation(scale);
	}

	// Apply transform to transform group
	tg.setTransform(t3d);
}

The marked line obviously raises a ClassCastException. What to do here?

Marvin

#2

No idea what that code should do. The only non-placeable geom is a ray, I think - maybe that can help you?

#3 
if (!(odejavaGeom instanceof GeomTransform) && 
    !(odejavaGeom instanceof PlaceableGeom)) {
...
	t3d.set(((PlaceableGeom) odejavaGeom).getQuaternion());

In the if case, it verify that odejavaGeom is NOT an instant of PlaceableGeom to cast into it after… a bit strange… ???

#4

A GeomPlane seems to be non-placeable, too. I have commented out the lines with the cast and it seems to work. But I have no idea, if this is a real fix.

That’s exactly, what I mean ;).

Marvin

#5

Here is another one. The engine crashes very often with the attached JVM dump. Is this a known problem? Or am I doing something wrong? Just run any of the Xith-examples to see it.


# Problematic frame:
# C  [libodejava.so+0x228b7]  dJointAttach+0x2f
#

---------------  T H R E A D  ---------------

Current thread (0xcc2f4c70):  JavaThread "Thread-2" [_thread_in_native, id=11483]

siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00003018

Registers:
EAX=0x00000000, EBX=0xcc4f733c, ECX=0x00000000, EDX=0x00003004
ESP=0xca7f7c98, EBP=0x085a87d0, ESI=0x089cf700, EDI=0x00003004
EIP=0xcc4498b7, CR2=0x00003018, EFLAGS=0x00010202

Top of Stack: (sp=0xca7f7c98)
0xca7f7c98:   083ef8e8 00000000 0000000c cc4e8cae
0xca7f7ca8:   089cf700 00003004 085a87d0 cdc55d98
0xca7f7cb8:   ca7f7cd0 ca7f7cf0 cc4faa40 085a8760
0xca7f7cc8:   083ee8b8 bead518d 4206d707 4217da7c
0xca7f7cd8:   c16593aa 447a0000 00003004 00003004
0xca7f7ce8:   447a0000 00000000 3e0f5c29 3dcccccd
0xca7f7cf8:   00000000 00000000 00000000 00000000
0xca7f7d08:   00000000 00000000 c16593aa 4217da7c 

Instructions: (pc=0xcc4498b7)
0xcc4498a7:   74 42 83 66 18 fd 89 7e 20 89 6e 2c 85 ff 74 46
0xcc4498b7:   8b 47 14 89 46 30 8d 46 28 89 47 14 85 ed 74 19 

Stack: [0xca778000,0xca7f9000),  sp=0xca7f7c98,  free space=511k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libodejava.so+0x228b7]  dJointAttach+0x2f

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.odejava.ode.OdeJNI.createContactJoints(JJ)V+0
j  org.odejava.ode.Ode.createContactJoints(Lorg/odejava/ode/SWIGTYPE_p_dJointGroupID;Lorg/odejava/ode/SWIGTYPE_p_dWorldID;)V+8
j  org.odejava.Odejava.createContactJoints(Lorg/odejava/ode/SWIGTYPE_p_dWorldID;Lorg/odejava/ode/SWIGTYPE_p_dJointGroupID;)V+2
j  org.odejava.collision.JavaCollision.applyContacts()V+39
j  org.odejava.test.car.Car.step()V+32
j  org.odejava.xith3d.test.CarExample$1.update(JJLorg/xith3d/loop/UpdatingThread$TimingMode;)V+7
j  org.xith3d.loop.UpdaterImpl.update(JJLorg/xith3d/loop/UpdatingThread$TimingMode;)V+32
j  org.xith3d.loop.RenderLoop.prepareNextFrame(JJLorg/xith3d/loop/UpdatingThread$TimingMode;)V+98
j  org.xith3d.loop.RenderLoop.loopIteration(JJLorg/xith3d/loop/UpdatingThread$TimingMode;)V+5
j  org.xith3d.loop.RenderLoop.update(JJLorg/xith3d/loop/UpdatingThread$TimingMode;)V+5
j  org.xith3d.loop.UpdatingThread.nextIteration(Z)J+68
j  org.xith3d.loop.RenderLoop.loop()V+61
j  org.xith3d.loop.UpdatingThread.run()V+57
j  org.xith3d.loop.RenderLoop.run()V+10
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub

Marvin

#6

Those crashes are usual reactions of ODE on misconfiguration or high number of applied contacts >:( - tracking them down can be really annoying. Crashes due to high contact count can be avoided by increasing the stack size and running the app in a new thread. The best measure to analyze what’s going on is attaching a c++ debugger, but I never succeeded with that on linux (failed to connect to jvm, no matter what I tried)… it sounds strange but… visual studio works smoothly :wink:

#7

I don’t think, this is due to a high contact count, since there are not too many geoms in the scene. And I didn’t change the configuration in these tests. Since I have very limited knowledge about Odejava, I don’t have a chance to track these issues. Could you maybe try to do this when you have time?

Marvin

#8

I’m sorry, I won’t have the time for it.

With ‘configuration’ I meant positions, rotations, mass values, sizes etc. etc.

#9

There seems to be a bug in JavaCollision.collide2()'s native function. When I use it with a Geom and a Space. It always sets the Geom1 to the geom from the Space (passed as the second ID) and sets Geom2 to null. I could live with the swapping of the Geoms and could correct it on a higher level. But the null Geom is hard. Is this a bug in ODE or can we fix that somewhere?

Marvin

#10

I found the C implementation of nearCallback2 i the odejava.cpp file. And it looks ok. So, this seems to be a bug in ODE itself, doesn’t it? Could please someone check that? If this is a bug in ODE, we need to report that to the ODE team. Or is there a newer ODE version we could use?

Marvin

#11

No, 0.9 is the latest release and afaik the trunk does not contain any changes to collide2 or directly related stuff (besides a new space type, that is).

#12

Where can I report that bug? Do I have to join the mailing list? Or is there a more suitable way like a forum or a bug tracker?

Marvi

#13

There is bugtracker on sf. But I’d recommend to discuss it on the mailing list.