To OSG or not to OSG?
Abstract: Discusses the usage of a scene graph library, namely OpenSceneGraph.
© Copyright Daniel Krajzewicz, 06.03.2019 21:58, cc by
Introduction
While working on ALSOG, I once had to take the decision whether to use a scene graph library — or any other kind of openGL extension — or not. Why should someone want to use a scene graph library? Well, because:
- You may obtain some importers / exporters “for free”;
- it may have some more gimmicks than you know;
- it may ease things;
- it may be fancy to use it.
Well, is it? I will discuss it using two applications I used OpenSceneGraph (OSG) for, namely ALSOG and SUMO.
ALSOG
ALSOG interprets a Lindenmayer System as different geometrical objects, namely cones, cylinders, balls, and tori. Initially, I coded the geometries by hand and rendered them using plain openGL. But, as said, I thought it would make sense to use a scene graph instead due to the reasons named above.
It took quite a while for me to move everything from a self-coded representation of objects to OSG. This was definitely a drawback.
Visual Appearance
When looking at the differences between the initial, openGL-based implementation and using OSG, both have the same appearance, see Figure 1 and Figure 2.
Figure 1: A complete example.
Figure 2: Close-up to the example.
The only difference appears when zooming deep into an object. My implementation only shifted the view to the front. Thereby, the nearest object covers the whole screen. OSG moves the camera, so that the objects behind the one in front get visible.
Figure 3: Moving beyond the near objects.
Goodies
Yes, I gained some additional features when moving to OSG. One of them is a nice performance monitor that displays the frame rate and the information about which of the rendering steps takes how long.
In addition, you get several additional output formats the generated scene can be saved as:
- Alias Wavefront (.obj)
- Openflight (.flt)
- Native OSG ASCII (.osg)
- Native OSG binary (.ive)
SUMO
After my experiences with embedding OSG into ALSOG, I tried to extend SUMO by a 3D-view, see also the blog post on using OSM 3D for SUMO. The original 2D openGL visualisation already was already hierarchical — lanes within the visible viewport are drawn, then the vehicles that are using them. Extending SUMO by OSG was very straightforward. An implementation of a viewport for the FOX-Toolkit is available within the OSG release. Building OSG-structures that represent the lanes and vehicles was very easy.
In fact, I did not investigate the result into deep. Still, it was surprisingly nice — a performant 3D-view with small coding effort.
Figure 4: 2D view on a SUMO simulation, and two 3D views from different angles.
Summary
It worked. In the end, it did. The effort to move ALSOG's existing 3D-representation from a native implementation into OSG needed some time. But it increased the overall features set. Extending SUMO by a 3D view was very thankful in terms of the result given the needed programming effort.
So, is it worth to move to a scene graph library? Well, yes, I think it is. One drawback may be the very complex build process of the OSG library due to the big amount of dependencies. I didn't build it for myself.
| Your message | |
|---|---|
| Name: | |
| E-Mail: | |
| Subject: | |
| Message: | |
Supporting an e-mail address allows us to answer.
Your message has been sent. Thank you.