Is jMonkey the right engine for simulating basic physics?

Hi!

I am a control engineer and most of the time I work with simulations. In this case I show plots with line and almost of the time, the customer does not understand what that plot is showing.

My work is to simulate mechanical arms such as robotic arms, springs, inertia, gears etc. So one day I found jMoney and I have some knowledge about Java. So I tried jMoney and it was quite simple to display rotating 3D objects.

Now I asking you. Is jMoney the right model for me to simulate basic 3D approximation of robots with jMonkey? I think I will use Blender to build up the scene like a sloping wall and then a simple 3D motor cycle is driving on that wall.

I’m going to combine jMoney with Apache Common’s math library. Should I stop now, or is jMonkey + Blender the right tools for me to simulate and control physical and mechanical systems?

The engine or core is essentially a 3D scenegraph with support for many modern techniques. The additional modules offer support in aid of the scenegraph, but that is what it is in essence.

There is built in support for bullet physics, and does possess the effects you describe. There are other wrappers for different physics engines such as box2d, and some libgdx love too. I like bullet.

It is certainly possible yes. Is it right? I guess in the end anything only goes so far before you have to write it yourself. I have a feeling this would be one of those in any circumstance.

Well.

My goal is to create a scene and dynamic model in blender, combine them inside jMonkey and do the simulation. The dynamic model can be a car with servo controlled shocks or a self driving car.

Do make the dynamic model works, they need a controller. I not focusing to make games, only simulate mechanical “things”.

As I have planned. First I need to create a scene in Blender. Then I also need to create a model in Blender like a arm with joints. Then combine them into jMonkey and make sure that the camera can filming on the model.

Is that right? Or do I need to know more?

Well you can definitely do all of those words. I have toyed with cars. The principal components exist. You must abstract them yourself to define a finer detail. E.g. inertia Vs defining an engine and gears. Horsepower, weight, etc. Suspension, tyre slip and friction etc to define tyres.

It’s bullet physics :stuck_out_tongue:

And I define that inside Blender or jMonkey?

I’ve been using bullet heavily on my project, it’s a game, not a simulation though. I’ve been fixing all the bugs i’ve found, but expect to find others and to have to fix the jni bindings. I would rate the current implementation as a beta-ish.

Also consider that bullet is not running fully asynchronous (as it could be) in jme, this might or might not be an issue, probably not.

And I define that inside Blender or jMonkey?

JME, unless you use xbuf exporter that allows to export physics settings from blender.

Okej!

So Blender is only for 3D design and creating limits so the model don’t fall through the floor. Does I not need to specify connections to in joints?

JME is only for the logic and import of the 3D?

Have you fixed them in a private fork or on the repository? I use the native Bullet Physics library and so it would be nice to know those bugs (:

1 Like

So Blender is only for 3D design and creating limits so the model don’t fall through the floor. Does I not need to specify connections to in joints?

I’ve just noticed that you are new, when i talk about xbuf, im talking about an unofficial model format for jme, that can export rigidbodies ( i think they are what you refer to as limits) and joints of type Generic, that can make things a bit quicker, you can search the forum for more infos.

Said that, xbuf is not a requirement to use bullet in jme, you can build rigidbodies and joints in the code, and that’s what you normally do, read the tutorial, i think it’s called Hello Physics. You would then use blender only to design the scene graphically and move the objects to the right initial position.

Have you fixed them in a private fork or on the repository? I use the native Bullet Physics library and so it would be nice to know those bugs (:

If you use the master, you should have everything, except pr #868 that has not been merged yet, but you would encounter that only if you enqueue tasks to bullet.

2 Likes

Thank you. I need to learn Blender first to create scene and model. Then jumping back to JME again.

I believe bullet does run either alongside in a single threaded manner with the scenegraph or in parallel in its own timestate; not in conjunction with tpf.

Most bugs are user error I find. Setting values is a mathematical art. Stray too far off the required settings and it will malfunction. But find the right ranges and it works as intended.

Yes, the updates run in parallel but they wait each other, there was a fully detached mode, but it was probably disabled due to concurrency issues, since some bullet code is in the update loop.

I managed to enable it, and it would run a lot better, you can have the physic thread at 100% cpu and still get perfect framerate, but i still need to figure out why it goes deadlock sometimes.

See https://github.com/jMonkeyEngine/jmonkeyengine/blob/c0cdf75603460b8f069eeb35cb0400a68148e3ce/jme3-bullet/src/common/java/com/jme3/bullet/BulletAppState.java#L137-L146 , you’ll see there is some dead code in this class that refers to the detached mode.

The SiO2 bullet integration is setup to run 100% on the simulation thread… which can be whatever frequency you like and is separate from the render thread.

You do have to use an entity system, though.

It’s not documented but there is a demo. You can see some posts about it in this thread:

The demo code is here:

I’m using it for the Spacebugs demo game which will eventually be open sourced as well.

1 Like