Hi all!
I'm working to develop a physics engine written in java, it's available in proto-type form on sourceforge (https://sourceforge.net/projects/jinngine). There is some source code available for creating simple demonstrations.
I'm looking for people who would like to help develop this engine, possibly with focus on making it pluggable into jME. If someone is interested in that, please feel free to contact me. Also, I wold like to discuss if such a project is really relevant. I developed the engine in my spare time, and in the beginning as an graduate project. But i think what came out of it was maybe worth building something on, as it was made with relatively high focus on performance.
Do you people think we need a "pure java" physics engine?
As things are now, the engine i quite functional, but a lot of necessary features are missing. That e.g. being some kind of event generation to an external listener. It uses the common techniques that bullet, ode uses, it is a constraint-based simulator using a simple PSG solver. It has a SAP / GJK-EPA collision detection system.
Morten Silcowitz
Hey silcowitz nice job! I’m going to pull it down this evening and give it a test drive. Do you have any plans for materials and trimesh and such? I assume the answer is yes, and the solution is more a manpower thing. I think a pure java physics engine would be great. As far as being easily jME usable, a jME Physics 2 binding would be the way to go for that.
I also think we need a pure Java Physics Engine!
I have played a bit with the JMEPhysicsPort of JBullet.
Jeah, the joints are really broken, I'm trying to fix it.
But for example, I had an error in the Source of Jbullet, 10seconds, and the error was fixed.
In ODE I have some problems since long time, and no idea how to fix it…
I've also been following JOODE pretty closely and it is moving along pretty well. Mostly driven and used by Xith as far as I can tell.
nymon said:
Hey silcowitz nice job! I'm going to pull it down this evening and give it a test drive. Do you have any plans for materials and trimesh and such? I assume the answer is yes, and the solution is more a manpower thing. I think a pure java physics engine would be great. As far as being easily jME usable, a jME Physics 2 binding would be the way to go for that.
Yes, and extension to the collision detection part that supports more complex shapes than convex compositions would be a very good thing. I'm not sure, but some kind of bounding volume algorithm should be able to handle this. Of course, having complex meshes greatly increases the computational expense of contact determination i for physics, but i guess it is still desirable in terms of game physics?
I have taken a look at the jME physics 2 interface, and it looks very interesting, and it should be possible to create a binding between this and Jinngine. I think I will put my attention to this, and let new task turn up in this way.
Thanks for the feedback!
We are starting to work on the jME Physics 2 bindings for Jinngine. Is there any guidelines for doing this available?
Right now, we are doing is creating a package named com.jmex.physics.impl.jinngine, in simply started to fill in interfaces. If any developers have some tips on how to handle this, they are most welcome to share them 
That sounds about right. How long do you think it will take you? Also, how much of the jME Physics API will be fulfilled with Jinngine (what won't work yet)?
Right now i don't fell like a have a complete overview of the jME api, so its hard for me to tell, but like you said in your previous post, tri-meshes and materials need some attention, right now the engine only handles compositions of convex quadrics. I'm still in the initial phase of figuring out how the API is intended to be implemented, mostly by looking at the code from the other implementations.
Also there is an issue on how friction is modeled in the api and how it is done in jinngine. Right now a very simplified friction model is used in jinngine, im not sure that its adequate to satisfy the needs of the API.
I think it is realistic to have a working prototype (with limitations) in 3-4 weeks, sooner if lucky.
Im currently working on the jME API implementation for jinngine. Im having trouble figuring out how it is intended that the internal transforms of geometries (e.g position, orient) are supposed to connect to the API /jme representation.?
Should the the API implementation update the jme representation? or should the jme representation poll the transforms through some interface?
I think Jme should poll the transforms. Because the presentation of the objects should be refreshed in the RenderThread. The other way would slow down the physic and the graphics can flicker.
In jME Physics the physics implementation should take care of this (no polling from jME's side). So after a call to PhysicsSpace.update() the new local transforms should have been updated in the scenegraph by the engine wrapper.
The best approach would be putting the transform update code into the event handler for physical movement - if you have such a thing. Otherwise you need to update all node positions.
The test file TestStressPhysics.java is first invoking the game threat, then simultaneously calls physic setup methods in a parallel thread (its own thread).
Is this multi-threated approach intended?
Hi again
When the API framework asks the PhysicsSpace to e.g create a box, it calls createBox, and sends a PhysicsNode as argument. But the to get the dimentions of the box, one needs to know the local transform. How is this information available when entering PhysicsSpace.createBox(name, node) ?
I've tried node.getLocalScale(), but it doesn't containt the right scaling… only identity. In the various test code files, one creates a new box by passing dimentions. So they should be available?
Is it right to ask such questions here, or should they be asked somewhere else?
silcowitz
Mostly you create the Box, and change its sizes after the constructor, in the ODE implementation the worldScale is called in the updateWorldData() method.
I dont think this is the best solution, but it should work
…and this is the right place to ask your questions.
Yes, the information is not available on creation time. It must be adjusted each time the local tranforms are changed anyways. Just have a look into the ODEJava binding.
HI!
there is a preliminary version of the jinngine jME plugin available on the svn at sourceforge
In the usual way, to check out both modules ( Jinngine, the simulator, jmejinngine, the jME plugin)
svn co https://jinngine.svn.sourceforge.net/svnroot/jinngine jinngine
You should be able to put this inside your jmephysics project at run the tests with the jinngine plugin. I wrote how I did it at https://sourceforge.net/forum/forum.php?thread_id=2510221&forum_id=811868, but you guys probably know this much better that me
Right now, only TestDomino and TestStressPhysics are supported… I think results are acceptable, although a lot of improvements could be done.
Just wanted to let you know.
-silcowitz
Cool. Nice to hear it works. I hope I have the time to get a look at it.
:-o
Sure I'd be interested in incorporating my idea. If I have any free time between p-sets then I'd be happy to do some work on that.