Nah, I want mu friction. If you put the surface parameter "mu" to infinite, the objects get stuck in each other. Its a well documented behaviour ODE suffers from (but they have the solution, I want it too!).

Cheers for the support guys.

PS I don't want moderator rights, I have enough work to do as it is!

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

Triangle Mesh (list entry) should be annotated with the postfix "(TriMesh)", since this Word will be found in most documentations (and should be used in this doc).

I would not write, that ODEJava should be faster than JOODE, because it uses native libs. Java can be faster than C(++) even for number cruncher code (Java isn't that bad ). So ODEJava might be slower just because it has to handle the JNI overhead. But, yes, benchmarks are to do .

In the very first example you should move line #32 between lines #38 and #38 (and #43 after it), since the canvas is needed first there and if errors occurr while scene setup, OpenGL would not yet have been initialized and would not be hard-destroyed. This is not the best thing for finished games, but the best for testing.

Well, maybe we should provide the frameTime in nano seconds in xith.[/li]

I guess, your addGeom() method should take a NodeGroup instead of a BranchGroup. A BranchGroup is solely for the root of the scene (a RenderPass). And I guess, you want to add the Geom to any place in the scenegraph.

You should use a Monospace Font for the code examples. I think, it would be good to use a background color for the code blocks like in XIN.

EDIT: The RenderLoop method prepareNextFrame() is meant to be used aith the super call as the first one. The renderNextFrame() method should have the super call as the last one. Thsi should be used like this in the documentation. It is not always used in the JOODE test in SVN. Maybe this should also be changed, if it wasn't made by intent, was it?

After all it is a good beginning of a great documentation. I finally begin to understand, how JOODE works . Keep it up .

Triangle Mesh (list entry) should be annotated with the postfix "(TriMesh)", since this Word will be found in most documentations (and should be used in this doc).

you've got a point - done

Quote

I would not write, that ODEJava should be faster than JOODE, because it uses native libs. Java can be faster than C(++) even for number cruncher code (Java isn't that bad ). So ODEJava might be slower just because it has to handle the JNI overhead. But, yes, benchmarks are to do .

changed the should to might

Quote

In the very first example you should move line #32 between lines #38 and #38 (and #43 after it), since the canvas is needed first there and if errors occurr while scene setup, OpenGL would not yet have been initialized and would not be hard-destroyed. This is not the best thing for finished games, but the best for testing.

I don't understand you here. How can I move something between one line. And what am I supposed to do with line 43

I didn't made those frameTime dependent step sizes, because for now I prefer a stable simulation - jumps can have strange effects in physics simulation

Quote

I guess, your addGeom() method should take a NodeGroup instead of a BranchGroup. A BranchGroup is solely for the root of the scene (a RenderPass). And I guess, you want to add the Geom to any place in the scenegraph.

mmh - yeah, but I won't change that now, because than I would also have to change that XithBinding stuff.

Quote

You should use a Monospace Font for the code examples. I think, it would be good to use a background color for the code blocks like in XIN.

no - When latex gives me Java syntax highlighting, why not use it?

Quote

EDIT: The RenderLoop method prepareNextFrame() is meant to be used aith the super call as the first one. The renderNextFrame() method should have the super call as the last one. Thsi should be used like this in the documentation. It is not always used in the JOODE test in SVN. Maybe this should also be changed, if it wasn't made by intent, was it?

You will see, that the Canvas3D is created after the scene has been set-up. So when there's an unhandled exception in the scene set-up code and the app will crash, it doesn't leave an uncleaned OpenGL context.

Of course when the app (game) is finished, there should not be any exception of this kind and you might want an OpenGL rendered loading screen or what ever. So you will need the Canvas from the beginnig on. But you might see my point.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org