Does jME Physics 2 depend on XWindows


I am a phd student working on robotics. We have a 3d physics based simulator written in C++ for our robots but i also want to develop a simulator for myself in Java for several reasons.

I had started on this subject like 1 year ago with Odejava but did not continue… I want to restart again.

I have an important requirement for my project. The simulator i developed should run on the systems without Xwindows installed. This is required for parallelizing the experiments i performed with the simulator. Note that most of the grid environments do not have XWindows support. If the physics engine i use somehow have some connection with opengl, in that case my simulator will crash on grids.

I would like to use JMEPhysics +  jMonkey Engine for my simulator because as far as i see its community and developers are the most active one compared to other alternatives. But i want o know if my requirement is somehow being fullfilled by JMEPhysics? Let me know if this physics engine is clearly separated from its 3D renderer…


You can use jME Physics 2 headless, using DummyDisplaySystem.

Can you give a little bit more detail?

I understand that DummyDisplaySystem is a class in jME. But will there be any extra problems or will the switching between render/norender is as simple as using DummyDisplaySystem or NotDummyDisplaySystem (I dont know jme api yet. i just made up this name to reference a regular display system):

if (render) {
   display = DummyDisplaySystem ();
   display = NotDummyDisplaySystem ();

Ok, thought you only wanted to know if it's possible.

You could do it similar to that, yes (don't know the correct code from the top of my head). But I assume you will want to load different/no trimeshes in server/nodisplay mode. It depends on the kind of simulation and/or visualization you are planning. There should not be "extra problems" besides what you might have as extra requirement…

What else do you need to know?

Thanks for the explanation…

Basically my use case will have a rectangular floor surrounded by walls and a many numbers of robots. The robots will interact with the environment and the other robots basically. The aim is to use physics is to obtain realistic results (to make the results as close as to real robot's interaction results). The robot will have a few parts which are connected with joints and the motor of the robot will be simulated with force vectors. Since i may have hundreds of robots in the environment, it is very computationally expensive. This is where grid come to scene and why i need to have a -norender option.

In this context, i should abstract physical entities from the visualization so that i can disable and enable rendering with just a flag. But if rendering is integrated to the physics engine of the physics engine in deeper levels, then i can not do that. What do you think? Is rendering separated from the pyhsics engine clearly in jME. By the way, i understand that in your application domain, this norender option is not much relevant but i hope somehow you separated it clearly…

We are using a server version without rendering in a project at work, so it's definitely possible. Physics is somewhat separated (you can define different physics than visuals) but it's still integrated with the scenegraph. The important thing is to omit the expensive parts (most importantly visual meshes) - that's possible.

I'm not sure if ODE (or any real time physics engine) is suited for clustering, though. But that's another story.

Thanks for the answers. It looks like you have won a new user and possibly a future developer :wink:

I'm not sure if ODE (or any real time physics engine) is suited for clustering, though. But that's another story.

No, i am not clustering the physics. I would like to describe that part too. Lets say i have some parameters to test in my robot controller. Since these parameters may take several values in the continuous space, i will need to test several of these. This is reason to paralellize because if i assume that one experiment takes 2 computation hours on one PC then for 100 different parameters i will need 200 hours to finish my experiments on one PC. But this is not the only reason. Since i can position robots in a bounded arena in infinite number of way in continuous x and y coordinates i need to use some sampling there too. Because of that i need to run the simulation i described for 200 times to obtain an acceptable average. This makes 200x200 hours for one PC :). But if i send each simulation to a different CPU in a grid of 400 CPUs, i can get this result in ~100 hours. That is the way i need to use grids..

ah, ok. so you don't even need to get that in realtime? then you should be fine with ODE (it cannot handle hundreds of robots moving on the floor in realtime)

good speed for your implementation :slight_smile:

Yes i dont need real time. I just need my experiments as realistic as possible and as fast as possible. About the robot numbers, upto a point the simulator returns me faster results than the real robots since working with real robots is tedious and time consuming to manage. And after some limit, real robots starts to be faster :slight_smile: because of physical interaction of robots in the simulator but if i can manage to buy that much robot :slight_smile: So simulation is necessary for working with large numbers of robots…