Frame rates…We don’t need no stinking frame rates…
Well, the renderer is embedded/called from a simple single pass graph traversal of an actually J3D graph, not a set of duplicate classes. Because of this, there is no state sorting or management of any kind. Which is bad for performance, but good for render correctness which is actually “the point”. My next step is to add simple view frustum culling against the hierarchy bounds to generate a render list instead of the “inlined” render traversal, however the example renderer will not change, other than step through the draw list that is split into opaque and transparent list so transparency can be done after opaque.
This is pretty much the slowest way to render (each shape3D sets a complete geometry and render state) but ideally the most render error-free. For J3D render compliance this will be the base-line implementation. This renderer will look exactly like the same J3D graph except for intentional differences. There are many J3D features that our group is never planning to implement, but released in this form perhaps the community will add those they want if they choose, as we will also as time goes by.
Once we have a good base-line, then a new in-game performance renderer will be developed based on conforming to the render correctness of this engine.
.
.
Long ago I wrote the OpenFLT loader for Java3D, which we recently reposted and begun maintaining again. One thing that really bothered me about the SGI Performer/FLT loader was that the colors and materials weren’t EXACTLY the same as modeled in Creator and was incredibly frustating. This was the fault of the loader not Creator I came to find out later. So when I started writing the Java3D FLT loader, I took extra care to make absolutely sure that materials in Creator looked pixel perfect in Java3D. Lots and lots of test models and there was some material munching I had to do to make it happen. But it was very much worth it for the artist because before they would over-spend HOURS making changes in Creator so that Performer run-time would look how they intended. This base-line renderer is meant to provide the same level of correctness going from current J3D scenes to JOGL and can be used to test other JOGL based engines content rendering. For example. on the same machine, for the same view configuration and loaded model and screen rez, a snapshot SHOULD be a perfect pixle copy. A quick image add/sub in PhotoShop can find any differences and help sort it out.
And theres so many neat tricks with alpha testing that I’d count that as a major limitation.