Java the right language for a physics engine?

[mezcal]

Hey guys,

I've set out to program some simple physics simulations representing basic 2d collisions, rotation, etc..

I'm a CS numerical analysis major, and I've taken some intro physics classes which covered the basics of dynamics and kinematics.  -- I think I have a decent grasp of the subject, so it should be "feasible" for me to have some decent realistic simulations.

I'm choosing java because I'm most familiar with it, and using an applet to display graphics in java is fairly simple.

My question(s )  :  Should I be programming "math simulations" in java?  Will this slow the program down too much?  

Is it the math calculations, or the animation / display methods which causes java programs to be slower?  I guess I don't understand how my java classes are displaying things at a lower level than "when I type g.drawLine(x1,x2,y1,y2); a line appears in my applet".

I've read people talking about using Physics engines, which were programmed in C++, in java.

Why is this a better approach?  Which "pieces" of your games are written in C++, and which pieces are written in java?  How can you include C++ libraries into a java program?

If I'm not really interested in building a game, but more interested in working towards a physics engine, should I bother writing any of it in java?

Thanks a lot!!

[swpalmer]

The general consensus here is that math in Java is pretty much the same speed as C/C++ with the exception of trig.
Unless you use SIMD assembler instructions you should be fine with pure Java.  The trig thing has to do with getting the precision that the Java spec says you must get for repeatability purposes on different machines.

I suspect for your project it will work out fine.

You can include C/C++ in a Java program through the Java Native Interface (JNI)  just read about it on java.sun.com.

The ODE Java bindings use this approach. Not for speed, but just so ODE doesn't have to be re-written in Java.

Working in Java may help you because development tends to go faster (specially if you know Java well).
You also have a built-in cross platform GUI kit for making simulation UIs and graphing results etc.  That might be good for you if you are developing at home on a PC and showing your work to people at school on a unix box for example.

Java programs aren't in general much slower.  But yes you did hit a particular area where performance can vary a lot - Graphics.  Some times you need to be careful or your Java graphics operations will use software loops instead of going more directly to the graphics drivers on the system and using hardware for line drawing and blitting.

[mezcal]

Ok, sounds good!

No, I don't think I'll be using SIMD instructions.

Sometimes you need to be careful or your Java graphics operations will use software loops instead of going more directly to the graphics drivers...

How can I control this?  I didn't think that you could have control over such things when interacting with a VM.

I have heard people complain about the java 2d API being slow.. how / why are the alternatives faster?

Games published by our own members! Check 'em out!

[Jani Laakso]

I'm choosing java because I'm most familiar with it, and using an applet to display graphics in java is fairly simple.

I'd say Java gives you enourmous boost for creating complex product, like physics engine. Grasping hard tasks with Java is a lot easier than with C++. This is something that really matters for large projects, less bug hunting, less cryptic code, less pointers..pointers..pointers and so on

My question(s )  :  Should I be programming "math simulations" in java?  Will this slow the program down too much?  

As someone already answered here, Java trigonometry is very slow (also i/o) compared to other languages, but this is somewhat isolated issue and perhaps it can be tangled a bit by using JDK 1.5 or even 3rd party trig. packages. I'd say in all the other areas Java does not need to be ashamed even if we compare it to C++.

Is it the math calculations, or the animation / display methods which causes java programs to be slower?  

E.g. jogl (Sun's reference implementation for OpenGL Java apllications) is very fast (again, compared to native code).

I guess I don't understand how my java classes are displaying things at a lower level than "when I type g.drawLine(x1,x2,y1,y2); a line appears in my applet".

I'd suggest that you check Java3D and Xith3D projects for example. They give you even higher level API to work out with 3D objects (and world itself), Xith3D works very fast.

Check Xith3D, it's relates to Java3D with it's API, it has some documentation and good people to back it up.

I've read people talking about using Physics engines, which were programmed in C++, in java.

Why is this a better approach?

I'm the author of Odejava project which wraps ODE (C project) for Java API. The only reason why I wanted to start such an project is this: There does not exist full fledged Java physics engine. But there exists need for proper physics engine to be used in Java applications. And on the other hand, I do not own enough knowledge or time on how to code proper collision libraries or physic libraries in any language. You can get some grasp of the physics engine's complexity by looking at the source code of ODE and OPCODE (= big task).

But, I see no reason why e.g. ODE wouldn't be very fast if it would have been implemented purely with Java.

Hope this answers your question.

How can you include C++ libraries into a java program?

Basically you get amazingly easy Java bindings to most native projects by using a project called Swig. It really is very simple I can tell. But for e.g. Odejava, we had to do some optimizations for the API, e.g. use Java's NIO with DirectBuffers.

If I'm not really interested in building a game, but more interested in working towards a physics engine, should I bother writing any of it in java?

I'd definately say, go for it (with Java!) Writing is one task, desinging other. I'd say if for some reason you wan't to change language from Java to e.g. C++, you can do it later also, but I'd be amazed if you need to. It's the architechture and algorithms behind it, not the language that makes things go fast (or slow).

Last comment, if you are really up to benchmark and numbers, you might check this out:
http://www.osnews.com/story.php?news_id=5602
It compares nine programming languages on different areas.  JDK 1.5 performs somewhat better on most areas, especially on the trigonometry.

Cheers, Jani!

[swpalmer]

Do a search here for VolatileImage and Managed Images.  There are optimizations within Java2D that put images in VRAM so they can be blitted with hardware.  Some operations (reading the image or doing operations like drawing an antialiased line that require a read of the image data) can defeat that optimization.  Some primitive operations (drawing lines) are optimized by getting the hardware to do it, etc..  Per-pixel access to bitmap data is slow partly due to bounds checks on the backing arrays and perhaps interaction with the VRAM caching etc.

[Jacko]

Go for it. My final year project at uni is a rigid body simulator that my tutor insisted had to be in C++   I've found it very useful to work through some of the algorithms and techniques first in java, because I feel more comfortable writing java than c++. Once you know how to do it, you can write it in any language.

And if you want to be sure that  the drawing isnt slowing your drawing down, then learn opengl using (LWJGL/JOGL/insert Java opengl rendering API of choice here). It's really not that hard to work out how to draw primitive shapes, like boxes, spheres, etc, which is what you will probably be starting out with.