// Pictures of my old 3D Engine in Java
Here are some screenshots of my 3D Engine (codename Metaverse) I made a few years ago (click to enlarge). It is written in Java and uses JOGL (JSR 231) as OpenGL binding and JInput to access the controllers.
These shots show the real time lighting and water rendering capabilities. They also show that you are the whole time on a real 3D planet (codename potato ;) ).
The next shows a 'test vehicle' to test model loading, animation, physics and collision detection of the Engine. You can use this vehicle to explore the planet - it makes even a lot of fun to drive through rough terrain and try to survive jumps from steep hills ;). The other screenshot shows the planet as wireframe.
The last two show the continuous triangulation of the terrain mesh and the space subdivision into a quad-tree (used for fast frustum culling and physics). The viewer is configured to be located inside the river bed.
You think that Java for 3D Graphics is like a penguin in hell? If you follow some rules to prevent stop the world garbage collections (full GCs) and prevent calls through the JNI where possible you can reach with the server (hotspot compiler) JVM performance comparable to C++ code.
The rendering performance is quite good. Even fast fly overs are rendered with 60+ fps. If the camera stays still the renderer reaches 200+ fps on my notebook (ATI X1600).
I have currently no time to continue with this project but if I think back how fun it was to work on that engine I would love to start hacking again immediately ;).
Wow! :-)
Our problem is always the f**ing budget! :-(
Posted by Fabrizio Giudici on December 31, 2007 at 01:56 PM CET #
>Our problem is always the f**ing budget! :-(
Yes, especially in a free time project :-)
Posted by Michael Bien on December 31, 2007 at 03:12 PM CET #
Fabrizio,
this 3D engine is the coolest visual thing I ever saw. However my brother became lazy, and now he is building grids...
Posted by Adam Bien on January 12, 2008 at 10:50 PM CET #
>However my brother became lazy, and now he is building grids...<
better building grids than a artificial intelligence for your heating :P
(not so dangerous :-))
Posted by Michael Bien on January 18, 2008 at 09:01 PM CET #
"If you follow some rules to prevent stop the world garbage collections (full GCs) and prevent calls through the JNI where possible you can reach with the server (hotspot compiler) JVM performance comparable to C++ code."
Could you share any details or pointers about these rules and how to prevent calls through JNI? According to Tony's comment in the sun.com blog entry about garbage collectors, referenced in one of your later entries in this blog, pauseless collectors come with considerable overhead.
Posted by ejoakim on February 19, 2008 at 11:20 PM CET #
Hi ejoakim,
>prevent calls through JNI
This is actually pretty easy (in theory): Just avoid OpenGL state changes. The OpenGL driver is of course not written in Java, that means that every time you talk to the OpenGL API you make a JNI call. To avoid state changes use techniques like state sorting (every engine does this) wrap state changes (if possible) in display lists, use shaders and prefer vertex buffer objects (VBOs) over immediate mode rendering.
This is actually nothing special, if you are doing this you will even safe a lot of driver side overhead (more details in your favourite OpenGL book).
>...pauseless collectors come with considerable overhead.
maybe - that is probably the reason why we have no pauseless GC in java ;-)
My engine generates almost 0 garbage at runtime. That means that stop the world garbage collections are not happening (independently of your chosen GC). Around every 10s a fast parallel young generation garbage collection accrues which pauses the app for <100ms (=>almost not noticeable).
I will probably write a separate blog entry about object pooling in the next weeks.
thanks for your comment!
Posted by Michael Bien on February 20, 2008 at 07:44 PM CET #