[udig-devel] Java3D Rendering

["Wellmann, Harald" <harald.wellmann@xxxxxxxxxx>]

In our uDig-based application, we need to support 3D terrain models and building models. So far, we have a couple of stand-alone Java3D viewers for rendering these models, and now we would like to somehow integrate them into uDig.

This is my rough idea of a roadmap:

1) An Eclipse EditorPart that handles a 3D file format and renders it using Java3D.

2) A replacement for uDig's BasicFeatureRenderer that simply renders 2D content into a Canvas3D and ignores the third dimension.

3) Mixing 2D and 3D content in one map with full support for 3D affine and projective transformations and multiple levels of detail.


Step 1) is finished and was almost trivial. I just had to osgify Java3D, wrap a Canvas3D in an SWT_AWT embedded frame and create an org.eclipse.ui.editors extension for a given 3D file format. This solution bypasses uDig completely, working directly with Eclipse RCP, but at least it allows us to open and view our 3D files. 

Step 2) is a kind of "easy exercise" and prerequisite for the final step 3), and it would have the pleasant side-effect of a drastic rendering speed-up for existing 2D feature layers. 

(By the way, I'm aware of that JOGL-based Geotools rendering pipeline, but I don't want to lose the scene graph and other high-level abstractions that Java3D offers on top of JOGL.)

I've been browsing the uDig source code, trying to understand the interaction of Renderer, MapEditor and FeatureStore, and it would be great to get some feedback on the following ideas:

- Create a ViewportPaneJava3D which implements ViewportPane on top of Java3D.
- Create a new preference and arrange for MapEditor and MapViewer to use the ViewportPaneJava3D instead of ViewportPane[Tiled]SWT. (It would be nicer to have extension point for this purpose.)
- Create a Java3DRenderer extending RendererImpl that somehow (?) gets access to the ViewportPaneJava3D by downcasting the IRenderContext (?) and updates the scene graph or moves the view platform when required, leaving all the painting to Java3D.

The biggest problem seems to be that the rendering models of Java3D and uDig are fundamentally different.

uDig gives you a BufferedImage to draw to, you have to handle all the world to screen transformations on your own and paint each feature to the image, whenever the viewport changes.

In Java3D, you create a scene graph with shapes (= features) and appearances (= styles), you set up a view platform which can move around in your virtual universe, and all the rendering is handled by Java3D automatically. Supposing your map layer is small enough to fit into memory, you would just construct the scene graph once, and each render() request would simply move the view platform, depending on IRenderContext.getImageBounds(). No need to iterate over the feature collection for every frame, no need to do any low-level painting of individual geometries.

And of course there are many more problems regarding layers, coordinate transformations and so on, but I would just like to get started somewhere...

Best regards,

Harald 
 
*******************************************
innovative systems GmbH Navigation-Multimedia
Geschaeftsfuehrung: Edwin Summers - Kevin Brown
Sitz der Gesellschaft: Hamburg - Registergericht: Hamburg HRB 59980 
 
*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************