Rendering Graph

Scenome's directed acyclic graph is a powerful technology for encoding scenery in a format that is human and machine-readable. However it is not without limitations. One important limitation of the directed acyclic graph is its traversal and rendering methodology. The directed acyclic graph is traversed in order from top to bottom and nodes are rendered in that order as well.

The link node provides an interesting tool with which you use to make different rendering selection and rendering order decisions. With link nodes you can construct rendering graphs that contain custom rendering descriptions used to override the standard scene traversal.

Rendering Graph Examples

Consider the following terrain database.

Figure 1.1. Rendered View. This terrain database is composed of 3×3 quadrants of terrain that are stored on disk as nine separate files. Typically the runtime software traverses the scene graph, determines which granules are on-screen, and renders those granules regardless of their semantic importance. Imagine that you wish to create a rendering list that displays specific content based on camera position. You might invent a rule such as "when the camera is inside a specific quadrant, only render neighboring quadrants." A 3x3 granule terrain database.

Figure 1.1. Scene Graph. This is the scene graph.

Figure 1.2. Rendered View. The camera is inside the quadrant indicated by dark blue. Light blue indicates neighboring quadrants. Granule 1x1.

Figure 1.2. Scene Graph. If you wish to render the quadrants and neighbors, you need the following scene graph instead. Your runtime also needs to test the camera position once per frame to determine the bounding box in which the camera is currently contained.

Figure 1.3. Rendered View. The camera is inside the quadrant indicated by dark blue. Light blue indicates neighboring quadrants. Granule 1x2.

Figure 1.3. Scene Graph. If you wish to render the quadrants and neighbors, you need the following scene graph instead. Your runtime also needs to test the camera position once per frame to determine the bounding box in which the camera is currently contained.

Figure 1.4. Rendered View. The camera is inside the quadrant indicated by dark blue. Light blue indicates neighboring quadrants. Granule 1x3.

Figure 1.4. Scene Graph. If you wish to render the quadrants and neighbors, you need the following scene graph instead. Your runtime also needs to test the camera position once per frame to determine the bounding box in which the camera is currently contained.

Figure 1.5. Rendered View. The camera is inside the quadrant indicated by dark blue. Light blue indicates neighboring quadrants. Granule 2x1.

Figure 1.5. Scene Graph. If you wish to render the quadrants and neighbors, you need the following scene graph instead. Your runtime also needs to test the camera position once per frame to determine the bounding box in which the camera is currently contained.

Figure 1.6. Rendered View. The camera is inside the quadrant indicated by dark blue. Light blue indicates neighboring quadrants. Granule 2x2.

Figure 1.6. Scene Graph. If you wish to render the quadrants and neighbors, you need the following scene graph instead. Your runtime also needs to test the camera position once per frame to determine the bounding box in which the camera is currently contained.

Figure 1.7. Rendered View. The camera is inside the quadrant indicated by dark blue. Light blue indicates neighboring quadrants. Granule 2x3.

Figure 1.7. Scene Graph. If you wish to render the quadrants and neighbors, you need the following scene graph instead. Your runtime also needs to test the camera position once per frame to determine the bounding box in which the camera is currently contained.

Figure 1.8. Rendered View. The camera is inside the quadrant indicated by dark blue. Light blue indicates neighboring quadrants. Granule 3x1.

Figure 1.8. Scene Graph. If you wish to render the quadrants and neighbors, you need the following scene graph instead. Your runtime also needs to test the camera position once per frame to determine the bounding box in which the camera is currently contained.

Figure 1.9. Rendered View. The camera is inside the quadrant indicated by dark blue. Light blue indicates neighboring quadrants. Granule 3x2.

Figure 1.9. Scene Graph. If you wish to render the quadrants and neighbors, you need the following scene graph instead. Your runtime also needs to test the camera position once per frame to determine the bounding box in which the camera is currently contained.

Figure 1.10. Rendered View. The camera is inside the quadrant indicated by dark blue. Light blue indicates neighboring quadrants. Granule 3x3.

Figure 1.10. Scene Graph. If you wish to render the quadrants and neighbors, you need the following scene graph instead. Your runtime also needs to test the camera position once per frame to determine the bounding box in which the camera is currently contained.

Figure 1.11. Rendering Graph. This is the complete rendering graph. A quick examination makes it very easy to determine when the runtime will experience the highest loads. Assume that each quadrant is roughly 50MB. You could use similar metrics to determine triangle or texture load as well. [None of these quadrants would require more memory than is available on an XBOX360 or a PlayStation3. But you might have to consider the time required to stream each quadrant of the CDROM or hard disk. This would also apply to a PC-based runtime used to run a professional flight simulator.]

Conclusion

Rendering graphs are easy to implement with Scenome, assuming your content is properly structured.