Opale's 3D module Presentation

Romain Pacanowski

<pac@tuxfamily.org>

Revision History
Revision 0.4	5 July 2003
Update
Revision 0.3	19 Feb 2003
First release
Revision 0.2	17 Feb 2003
Second draft
Revision 0.1	11 Jan 2003
First draft

Table of Contents

Presentation

Warning

Currently, the 3D module is only available in the CVS source tree. Its conception is not finished and any contribution would be appreciated (see below). The following presentation gives you the development's outline and our main ideas with this new module.

Presentation

The goal of the Opale 3D module, aka OM3D, is to provide a full API to represent, to manipulate and to render 3D objects. It is not built over Opale's 2D module. It is not an extension of it. Why ? For many reasons and more precisely because we wanted to keep 2D and 3D separated in order to let the end user use whichever module he really needs. Even though a point in a three dimensional world may be seen as an extension of a planar point, the re-usability of methods and attributes would not be very interesting and more important, not very efficient.

To be clear, OM3D is not

Another Raytracer (POV-Ray is very good)
Another 3D Motor to develop a Quake-like game

It's a library, a basis for pre-modelling with exports capabilities for softwares like Maya, 3DSMax,POVRay or Blender.

OM3D introduces a new concept that is not present in other modules. It is a polymorphic module separated in two parts : a representation part which will be 100% Java and a rendering part which will be polymorphic.

What does "polymorphic" mean for a rendering engine ? Well let's face the truth. Many Java developers/programmers think that Java's implementation is not fast enough and especially in the 3D domain. So we have decided to let the user choose between the following options (in development order ?) :

Java + Java
Java + OpenGL using GL4Java or JOGL
Java + Java3D
JEVAS

All solutions listed above will implement the same UML model for modeling 3D objects and a will have a common minimalistic UML model for the rendering part.

Java + Java : This solution is the lightest one. The rendering engine is entirely Java-written, no additional libraries are needed, only a Java Runtime Environment. This solution is the most portable (is Java really portable?) but it is also the slowest.
Java + OpenGL : The fastest solution which uses an external specialized library (a binding to be more precise) to implement the rendering engine.The relevant question which is still debating is : "Which one ?".
This is an intermediate solution which will use the Java3D API but we will not attempt to develop it just as yet, interested developers are welcome !!!
JEVAS stands for Java + Evas. Evas is a powerful graphical library created by Rastermann only available for Unices. Jevas is not a very useful project but a fun one which goal is to provide an encapsulation, a convenient way to call Evas' routines, through JNI. JEVAS will not be a new implementation of EVAS.

The OM3D provides two Canvas3D objects that are reusable with SWING and AWT. All solutions listed are for Java developers. Since the apparition of the Gnu Java Compiler, solutions for C++ developers may be conceivable whether

a new canvas (extending one provided by QT, GTK, wxWindows,..) is developed.
classes responsible for rendering will be reimplemented in C/C++ using CNI or JNI.

This could be a huge waste of time if the GCJ project provides speedily an AWT and SWING native implementation.

However, a solution with SWT may be given birth if we are enough to work on it.