Changes in Aviatrix3D 2.0 Notes
The change from version 1.0 to 2.0 brought some significant changes to Aviatrix3D. These changes make the two versions incompatible, though for the most part upgrading to the new APIs should be relatively trivial.
The three most significant changes that an end user will see is the change to
the new JSR 231 APIs for access to OpenGL (
Layers and Viewports
Although AV3D 1.0 made mention towards layers and viewports, we didn't end up providing an implementation of them. The layered methods were empty and the classes did nothing. With the move to 2.0, we have made layers an integral part of the scene graph. In fact, it is now impossible to build a scene graph without at least one layer.
A layer represents a separate drawable scene that can be composited on top of other layers. A typical use of this is in a HUD such as in a game. Along with layers we also introduced the concept of viewports. A viewport allows you to draw to only a portion of the full window, and yet treat it as a fully self-contained window with proper aspect ratio management etc. A typical use of viewports is in a 4-view CAD-style application.
Layers contain one or more viewports. A viewport may also contain its own layers, which can be useful if you have independent views and each need their own local user interface. Viewports on different primary layers do not need to match between layers. Each primary layer is independent of the other layers, so you can mix and match these as required by your application needs. Of course, we also allow you to share a scene graph between different viewports/layers as well, thus saving on memory usage.
As a result of adding layers, projecting the mouse back into virtual world
coordinates has become a lot more difficult. A 2D position on the screen doesn't
always correspond to a single virtual environment. To accomodate these changes,
the methods on
Supporting multipass rendering has resulted in needing to change the way the
scene itself is represented at the top of the scene graph. The single
JSR 231 APIs
With the release of the formal JSR 231 APIs, we swapped over to using those. For the most part, you won't notice these as a programmer. Only in a few place, such as the package for the GLCapabilities object that needs to be passed to the surface constructor will you notice. If you are building scene graph objects based on the custom renderable interfaces, you'll also notice that we only pass in the GL object and no longer the GLU object. With the new APIs, the GLU object can be directly constructed by the end user, rather than fetching it from a drawable object provided by the system.
Internally we have some large changes to how we interact with OpenGL. The new JSR APIs allowed direct access to the context rather than only allowing the indirect callback structure. Now we access the context, make it current, do the drawing and then release it, in the same way as a traditional C-based OpenGL application.
We done some more optimisations for single versus multithreaded rendering. In the single-threaded case we grab the context and make it current at the beginning of the application and don't bother to release it until the canvas goes away. This saves a fair bit in the locking/unlocking overheads.
One of the areas that became increasingly more cluttered as we developed the
first version was the location of almost all the classes in the one package
As part of this restructure, the existing
During the restructure we also commonised as much as possible. A lot of the interfaces between the audio and visual pipelines were the same, so a collection of sub interfaces were made and then extra packages were defined for the audio and visual device implementations. We also noticed a lot of common code in the bottoms of the various cull and sorting stages, so common base classes were built there as well. Almost all of this you should not notice, other than needing to change the packages, but it makes our life much easier from a development and debugging perspective.
The picking system has been completely abstracted now. In the old code, if you
wanted to create a custom node type and have it pickable, you needed to extend
one of the core classes, like
In this version we add the support for the SWT toolkit that is the heart of the Eclipse project. We're including this as a first class capability rather than an optionally compiled extra. Eclipse is has a huge following and with the addition of OpenGL capabilities that are being developed by us (a port of the JSR-231 APIs to run under SWT).
SWT support is designed at the level of allowing you to use Aviatrix3D as a plugin direct to Eclipse. In this way you can add first-class 3D graphics capabilities without the need to code in OpenGL. Also, with just the change of the surface class your application can run in either SWT or AWT environments.
A subset of the scene graph nodes have been defined that allow for scenes to be described in purely 2D nodes. In a 2D system, lighting and other effects are ignored. Also, transparency handling is limited to only separating out transparent and opaque objects. There's no depth blending.
In addition to a 2D scene graph, 2D geometry in the form of bitmaps and rasters are supported. These are projected into 2D space on the screen, that is modified by the 3D transformations above them. These project 2D pixels for rendering on screen, but they are also subject to the OpenGL limitations. Once the raster position goes offscreen (typically the lower-left corner), the entire raster object is clipped, even if it would normally still be partially visible.
Along with the layers, there is also the ability to define a layer as being rendered using multipass techniques. This allows almost all the traditional C-style functional programming tricks for multipass rendering. Shadow Volumes, motionblur and all those usual effects can be drawn using these capabilities.
Access to all 4 main buffer types are provided. The scene graph is still structured in the natural way you would expect: Describe each layer and viewport as needed in the proper order, including the multipass layers. Internally, the implementation takes care of all the messing around and rendering re-ordering that needs to be taken care of. Several examples showing the use of different buffers and volume shadows are provided.
[ Home ]
[ License ]
[ javadoc ]
[ Online Examples ]
[ Download ]
[ j3d.org ] [ Aviatrix3D ] [ Code Repository ] [ Java3D ] [ OpenGL ] [ Books ] [ Contact Us ]
Last Updated: $Date: 2010-05-01 04:20:35 -0700 (Sat, 01 May 2010) $