Local Info

Topics

j3d.org

Design Philosophy

Well designed systems must have some over-arching philosophy that guides the development. As developers that have been involved in 3D graphics design and implementation for more than a decade, we do have some fairly well developed set of guides about what we liked and disliked about other scene graphs that we've used. In addition, as active members of a number of these other communities, we also have a very good understanding of what others like and dislike and would like to see, and this has been our guide as we've done the initial work on this project.

 

Target Audience

Aviatrix3D is targeted at the visualisation and simulation markets. It is not designed for game engines. Where a design trade off needs to be made, it is done in favour of multi-threaded and or multipipe rendering infrastructures. Considerations of multi-threaded access are primary in the design, which means lots of protection against users interacting at the "wrong time".

Extensibility

Since the target audience has such a diverse range of hardware that they could and will be running Aviatrix3D on, we built the API so that any given piece can be removed and replaced with something else that may be more suitable for the task at hand. Extensibility extends to all levels - from the basic scene graph structural components through to the various stages of the rendering pipeline.

The only area where we have not permitted extensibility is in the definition of the low-level rendering API. We are about OpenGL, and OpenGL only. There is no facility to extend to different rendering technologies, nor will we make limitations to the design to support the different capabilities provided by other rendering 3D APIs (frequently you can just use the OpenGL type value directly, interchangably with our own constants). We do intend to provide output for non-graphics devices over time too (eg spatialised audio and haptics).

Minimalism

To keep performance high and not burden the rest of the rendering infrastructure with extra implementation cost, the API design is very minimalistic. There is only one way to set and get a value and minimal reliance on external APIs. In addition, the scene graph code contains no implicit functionality. For example, billboards and LODs, both of which imply a functional runtime implemetation requirement inside the scene graph are not provided. Utilities are provided that implement these on top of the core API, but they are not provided as part of the base function.

The code is designed to be as open as possible. We give you enough rope to hang yourself with, a stool and point you at the tree and then tell you to go for it. For example, you can provide a pre and post effect processor that gives you complete access to the GL context allowing you to completely change the visual output from what we wanted to render. If you want to really screw things up, we're not going to prevent you from doing it.

Open Access

Access to all parts of the rendering model are provided. Almost every item of functionality is provided to the end user and there is nothing "hidden" behind the scenes, such as use of package-level API calls etc. In addition, all the classes are provided with protected methods and variables to all the important data structures allowing you to extend with your own functionality as desired.

Also, since this is an open source codebase, you are free to peek, poke and prod at the internals too. If you find a bug, please tell us about it and optionally provide a fix.

 
[ 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) $