Big no-no(s)¶

Below are some things I discovered not to do along the way with regards to OSG programming.

Composite scene graph node classes¶

At first glance this seems pretty handy. You can create a new class derived from osg::Node so it can go on the scene graph and make it encapsulate additional scene-graph elements as an alternative to inheritance or multiple inheritance. For instance, the SpatialSystem class inherited from osg::Group and encapsulated a list of osg::PagedLOD nodes with SpatialSystem nodes as children to represent nested spatial systems. For downward traversal on the scene graph everything is hunky dory. Simply override traverse in SpatialSystem to call accept on the PagedLOD list and we’re fine. However, this all completely breaks when upward traversal is considered because the PagedLODs don’t actually have a parent list to traverse over. This breaks bounding volume computation and any other visitor that performs parent traversal. Even some downward traversing visitors may be broken since they don’t know about the encapsulated objects. Bottom line, do not do this. It tears the scene graph apart.

Alternatively, in most if not all situations where you may be compelled to implement the anti-pattern above, you can simply add the nodes you would have encapsulated as children on the scene-graph instead (as nature intended). The only drawback is less ease of access, but scene-graph centric strategies can be used to deal with this. For instance, SpatialSystem had to be changed to add the PagedLODs as actual children. However, it uses a group node child to organize nested system children away from non-system children. Essentially serving the same purpose as having them as a list data member. Additionally, the old design required serializer code for the list of PagedLODs, but the revised design does not.

Changing the render target on an existing camera¶

Lets say you have a camera bound to an off-screen frame buffer object. After this camera has been initialized (an update pass has been performed on it), you cannot change the render target. This is particularly confusing since there is a method 'detach’ on the camera, but it doesn’t work as of OSG 3.0.1. For a different target, you just need to instantiate a fresh camera.

OSG as a processing pipeline¶

OSG is not so great for 'pipeline’ operations that require a huge amount of detailed control of state. This is because OSG was designed to remove the burden of cumbersome OpenGL state management as part of scene traversal. However, this can actually get in the way when doing things like procedural texture generation or even HDR effects. The structures create unnecessary overhead and you find yourself having to override everything OSG is doing that would be helpful under more usual circumstances. For these types of tasks, one may want to consider plain OpenGL (depending on complexity) or osgPPU (OSG Post Processing Units) plugin.