<=  Variable mass and crudely proportional (but not cube rooted) radii. With elastic collisions, some of the objects may collide at low speeds, and it's possible for a pair to get sort of hung up on one another due to the asymmetry in their positions pre-detection versus their positions the iteration after the collision. They may end up on the next iteration, 'colliding' again even though they are moving away from one another because their positions + radii still overlap, and another set of collision calculations will move them back toward one another as though they were colliding juxtaposed (because the collision equations simply reverse the component vector velocities).

Basically two objects colliding with one another cannot collide again without one of them colliding with another object first  (1) Assuming the collisions are in a Euclidean space  2) Assuming no other forces like gravity are acting on them.  This smoothes out the simulation. If ballX's last computation cycle included a collision with ballY, and it detects they're colliding again without either ball having collided with something else in the mean time, then do not register another collision. This will allow the balls that have collided and are moving away from one another but are still overlapping not to collide again until there's a legitimate reason to do so. Quick and dirty.

<=Jogl collider

Sun has created a graphics API called Java3d which is based on OpenGL and DirectX (you can choose, apparently, which to use based on the OS).  I spent a week or so going through J3D, reading the documentation and trying to work out how to write for it because I was having trouble getting JOGL off the ground (until I found Kiet Le's redbook site). But, while it's easy to get something on the screen, it's too restrictive for the average OpenGL hack who wants (and knows how to) get into the nuts and bolts of transformations.

Java3d is different (although logical) from OpenGL or DirectX. It's a middleware API a level higher than OpenGL/DirectX (where higher means, it takes care of more details behind the scenes than a language less high), and the entire scene is class-based. You create a universe, a branch, and group objects, then you generate leaves, or primitive objects; you can add mouse rotation classes to move objects in the scene around, but it handles all of the functionality itself, and there's no easy way to get in and manipulate things the way I'm used to.

So, for me it was back to JOGL, and I was finally able to get it working. Once you have it up and running, it's just a matter of putting your C++ OpenGL code in the render function.

Here's a great tutorial for JOGL that covers most of the lighting you'd ever want in a basic physics program. If you know OpenGL, then there isn't that much you need to do in going from C++ OpenGL to Java JOGL; there's a little difference in the way you get a GL context and loop through the render function, but this is very nicely taken care of with the JOGL animator class. 

 The NeHe ports are also good, but I prefer Le's tutorials because he compresses at least the basic lessons into very basic 1 file classes you can easily modify, test, and deploy. The NeHe  tutorials have help overlays, keyboard overlays, a "common" directory and other extraneous stuff that make it too difficult for me to track down issues; and also, I don't want a bunch of overlays floating around that I didn't specifically create for a reason, and I don't create things unless I use them. I will add what I need later.

Use the arrow keys to rotate the system, and use the -,= keys to zoom in and out.

Sources as text files. I used a standard Kiet Le redbook example as a template for the main class.

• src\Ball3D.txt
• src\Balls3D.txt
• src\gravity_plane.txt
• src\point.txt