next »

[Marvin Fröhlich]

There's a bug in the newTrimesh() method(s) of XPAL's CollisionEngine. It takes an array of Vector3f, which should be an array of Point3f. Vertex coordinates are always handled by Point3f, since otherwise, they would net be transformed correctly. It is ok (and advisable) to make the method take an array of Tuple3f, but internally a vertex coord should always be handled by Point3f. The GeometryUtils.getVertices() method returns a Point3f array. So the newTrimesh() method is not usable without conversation.

Additionally I would suggest to overload this method to alternatively take VertexContainer/IndexContainer to avoid filling a Geometry's vertices into a new array with new Point3f instances. And a method taking a Geometry would also be cool. It would then check the hasIndex() method and call the method, that takes a VertexContainer/IndexContainer. This way you could create a new TriMesh with only one line of code and with no GC overhead.

I would fix/add this on my own, but currently there is a compilation bug in JOODE, so I would not be able to create a new jar. And XPAL is your baby anyway, Amos.

Marvin

['n ddrylliog]

Everything you mention here is possible, except avoiding GC overhead, since data duplication is needed between Xith3D and JOODE, and that, until both libs use the same math library (how is it coming, btw ?).

I have added these methods that you were talking about. For now it has a GC overhead indeed, but that'll be fixed when JOODE no longer has this compile error.

And XPAL is your baby anyway, Amos.

Come on, I was not saying that nobody should touch it.
I was just saying "if it sucks, it's my fault. if it's good, it's because someone else melted in".

[Marvin Fröhlich]

Everything you mention here is possible, except avoiding GC overhead, since data duplication is needed between Xith3D and JOODE, and that, until both libs use the same math library (how is it coming, btw ?).

I have added these methods that you were talking about. For now it has a GC overhead indeed, but that'll be fixed when JOODE no longer has this compile error.

Thanks a lot. The new math lib is evolving pretty well. In fact I have already finished everything needed for xith. Arne is currently working on the extras needed by JOODE. It won't be done that quickly, since it is a little more difficult for him to adept the method signatures. But tests are to be done anyway after it is ready.

And XPAL is your baby anyway, Amos.

Come on, I was not saying that nobody should touch it.
I was just saying "if it sucks, it's my fault. if it's good, it's because someone else melted in".

Oh, you misunderstood me. I only say: "As long as somebody is an active developer and is in a mood to further develop/support his work, he should have the privilege to add new features (and fix bugs). But of course everybody can tough other's babies after consultation with the code owner or in urgent cases when the code owner is absent."

I hope, this is a little less misunderstandably.

Marvin

['n ddrylliog]

Oh, you misunderstood me. I only say: "As long as somebody is an active developer and is in a mood to further develop/support his work, he should have the privilege to add new features (and fix bugs). But of course everybody can tough other's babies after consultation with the code owner or in urgent cases when the code owner is absent."

I hope, this is a little less misunderstandably.

For such evident improvements as that, you don't even need to ask me. (If you don't want to do it, ask me to do it. But if you just want it and want to do it, go on, that's no problem. I'm not too touchy about my code)

[Skuggan]

Is the above mention bugged fixed yet or have I found a new one?
The following code generates an exception:
Code:

Code:

        TriMeshCollideable brick0 = collEng.newTriMesh( new Box(1f, 1f, 1f, "crate.png"));
        Body brick0Body = simWorld.newBody();
        brick0Body.setMass( 20f );
        brick0Body.setPositionY( 5f );
        brick0Body.setPositionZ( -1f );
        brick0Body.addCollideable( brick0 );
        simWorld.addBody( brick0Body );
        scene.addChild( gfxManager.add( brick0 ) );
        //bricks.addCollideable( brick0 );
        environment.addCollideable( brick0 );
        addMovingObject( brick0Body );

Exception:

Code:

Exception in thread "main" java.lang.NullPointerException
        at org.xith3d.physics.collision.collideable.TriMeshCollideable.getBaseGFX(TriMeshCollideable.java:110)
        at org.xith3d.physics.collision.collideable.TriMeshCollideable.getBaseGFX(TriMeshCollideable.java:53)
        at org.xith3d.physics.PhysicsGFXManager.directAdd(PhysicsGFXManager.java:108)
        at org.xith3d.physics.PhysicsGFXManager.add(PhysicsGFXManager.java:263)
        at com.xbrix.simx.main.SimX.setupPhysicsAndScene(SimX.java:183)
        at com.xbrix.simx.main.SimX.<init>(SimX.java:256)
        at com.xbrix.simx.main.SimX.main(SimX.java:271)

The following works:

Code:

        BoxCollideable brick0 = collEng.newBox( 1f, 1f, 1f);
        Body brick0Body = simWorld.newBody();
        brick0Body.setMass( 20f );
        brick0Body.setPositionY( 5f );
        brick0Body.setPositionZ( -1f );
        brick0Body.addCollideable( brick0 );
        simWorld.addBody( brick0Body );
        scene.addChild( gfxManager.add( brick0 ) );
        //bricks.addCollideable( brick0 );
        environment.addCollideable( brick0 );
        addMovingObject( brick0Body );

Just started to play around with the latest cooker in order to get it to work with my game.
I need the newTriMesh() function to work because I will use loaded models to be collideable.

Have I done something wrong?

//Skuggan

[Marvin Fröhlich]

I will check it tomorrow.

Marvin

[Marvin Fröhlich]

The NPE is fixed. But here we have an example again, where JOODE's collision-checkers do not work correctly for some cases.

Marvin

[Skuggan]

Thanks Marvin!

I solved it with primitives as colliders instead of the simplified 3d model.

I thought it should be a piece of cake to convert to the new physics but there are
many differences from OdeJava I used before.

Eventually I will get everything to work and will give you some testcases with vehicles
etc you can include in the package.

So far I have managed to get my wheel loader on the screen and get it to react with the
surrondings. Now I'm working in the joints.

//Skuggan

[Marvin Fröhlich]

Eventually I will get everything to work and will give you some testcases with vehicles
etc you can include in the package.

That would be awesome .

Marvin