Rendering large assemblies

Welcome to this book dedicated to the rendering of large data assemblies using REDsdk. The definition of 'what is a large assembly?' is indeed specific to each visualization application, so let's focus then on a few examples:

Large real-time 2D, 3D and photo-realistic assemblies examples.

The common item in each of these examples, for drafting, AEC or architectural markets is that we have millions of entities to manage. It can be millions of lines and texts in a 2D model, each of them being selectable, editable anytime; it can be millions of pipes in a plant model or it can be hundreds of millions of triangles in a complex architectural model.

This book will provide you guidelines on how to architecture your application and data to get a good level of performances with REDsdk. Then, if not done already, you may be interested in reading the Analyzing performances book, dedicated to optimization with REDsdk.

The scene graph

Defining the scene graph architecture is our first performance lever. A scene graph set properly will enhance the overall application performance. Depending on the kind of data, edition needs and a variety of other factors, we'll be able to find out a good scene graph architecture fitting both the application needs and REDsdk's requirements.


The definition of appropriate shaders and the choice of a lighting model for the scene are also key parameters that can have a lot of influence on performances. See the details here: Choosing a shading model.


At the application code level, we have another optimization lever that we can activate, on the data channels used by the geometry. Learn how we can save memory and performances reading this chapter: Reducing the geometry bandwidth.

Application architecture

Many applications are more or less real-time, but some *must* be real-time and run at 60Hz minimum. At this high framerate, every milliseconds is important, so running a A parallel application architecture may be key to performance.

Using levels of detail

Rendering Levels Of Details (LODs) with REDsdk is possible. The engine provides a way to incorporate and select the right LOD to be displayed for a given geometry, based on application defined criteria. See Levels of detail for further details.

Data streaming

Applications managing extremely large datasets that don't fit in the system or GPU memory need a way to stream in and out data according to their needs. Please review this chapter: Data streaming for guidelines on how to stream data with REDsdk in a parallel architecture.

Setting up floating origins

One common problem that arise with large assemblies is about exceeding the numerical accuracy provided by simple precision floating point values. The problem is that hardware acceleration need simple precision floating point values to operate at full speed. Double precision data rendered by graphics hardware may display up to 10 times slower than simple precision data, so often, this is not a viable alternative.

Some display techniques can be setup to overcome this problem. Learn all about them here: Floating origins