Modifying engine data

Changing data will have a cost. This cost can sometime be neglectable, and sometime not. All this depends on the kind of application considered of course. The purpose of this page is to provide a few details on REDsdk's internal mechanisms to handle data.

GPU updates

Any pure hardware mode or hybrid mode REDsdk application will have to deal with GPU updates on making changes to data. First of all, as detailed here: Transaction management, changes in REDsdk occur between a call to RED::IResourceManager::BeginState and a call to RED::IResourceManager::EndState. The call to RED::IResourceManager::EndState commits all changes and updates the GPU accordingly to reflect these changes.

Among the different possible changes that can occur, we'll mainly discuss:

• Material GPU updates,
• Image GPU updates,
• Geometry GPU updates.
• Text GPU updates.

And finally some Free GPU operations, that have zero cost!

Material GPU updates

On calling RED::IResourceManager::EndState, REDsdk will prepare all materials for the rendering. This implies a parsing of the modified material contents. This operation consumes some time by itself: around ~1/10th of a millisecond for complete materials with several rendering configurations. This time may of course vary with the number of RED::LayerSet configurations, the number of shaders involved and the number of RED::HARDWARE_PLATFORM to handle.

Image GPU updates

REDsdk does not have any image copy allocated on the CPU side. Therefore, at the time a pixel array is loaded for an image (using RED::IImage2D::SetPixels for example), it directly goes up to the video memory, without any pit-stop on the CPU side. Note that image operations are synchronous and should not be executed from auxiliary threads, as detailed here: Modifying images during a draw.

Geometry GPU updates

REDsdk clusters geometries together into large batches to reduce the number of rendering calls, per material, unless specified otherwise through RED::IMaterial::SetBatchMode. Therefore changing the contents of a single geometry may have an effect on a larger memory chunk than the one used by the geometry itself, alone.

Under certain conditions, REDsdk can do what is called a 'smart GPU update' where only the portion of the changed geometry is being modified. Whenever all conditions below are fulfilled, REDsdk can do a smart update on a geometry modification:

• If the mesh (or line, or point) update occurs AND if there's no change in the number of vertices of the mesh AND there's no change in the number of data channels, size and format, then the update of the memory for the GPU will be smart and only the modified subset of data will be uploaded on the GPU with new contents.
• If a mesh is unlinked from the scene graph without being destroyed, then nothing happens on the GPU. The mesh is still there, ready to be re-used. If the access hierarchy to a mesh is modified, then nothing happens on the GPU. This can be used for example to insert intermediate transformation matrices that have to be applied to some meshes.

Other changes may cause a 'full GPU update' for the memory batch storing the geometry:

• If a mesh (or line, or point) update occurs with a change in its number of vertices, or channel format or if new channels are added or existing channels are destroyed, then the batch will suffer a full update on the GPU.
• If the material of a mesh is modified, then both the old material batch and the new mesh's material batch will have to be fully updated.
• If a mesh or line or point is created and assigned to a material, then the material's batch will have to be updated.
• If a mesh or line or point is destroyed, the former mesh's material batch will have to be updated.
• Note that the two previous rules apply to meshes, lines and points only. Adding or removing existing geometry instances through intermediate transform shapes has no effect on the GPU.

Text GPU updates

These rules apply to RED::ITextShape rendered with RED::IFont using the RED::FNT_TEXTURE display method:

• A textured text is internally turned into a geometric mesh that is batched like any other mesh is.
• Then, the change in position, rotation, alignment of a string in the text cause a GPU smart update workflow.
• If the sum of all characters in all strings of a shape changes, then a full update occurs as if the number of vertices in a mesh had changed.
• Note that parameters of a textured font can't be modified. The font has to be destroyed and replaced by another one.

Free GPU operations

To complete the list of operations detailed above, several scene graph operations have no effect at all on the GPU memory.

• Modifying the transformation matrix of a shape.
• Moving a shape between two different cameras.
• Modifying the RED::LayerSet used to render a shape.

CPU updates

Of course, CPU updates are completely different from GPU updates. The point with CPU updates is all about the update of the acceleration structure used for the ray-tracing of the considered scene.

Unlike GPU updates, CPU updates are NOT performed during the RED::IResourceManager::EndState call. CPU updates occur during RED::IWindow::FrameTracing (or any FrameTracing derived calls). The acceleration structure gets updated first.

The general rule is that the amount of time needed to update the ray-tracer acceleration structure is directly proportional to the number of triangles that are modified in the structure. Any world space position change of a triangle (or line) is considered as a modification. Matrix transformations of instances are considered as changes applied to all the geometry being manipulated for the purpose of updating the acceleration structure.

CPU acceleration structure reset

On certain conditions, the acceleration structure of the engine may be reset:

• If two consecutive transactions that modify data in the scene are not drawn, then the acceleration structure will be reset. REDsdk has the capability to store actual data and to recall the last change that occurred on these data. Therefore, whenever two changes were made without updating the structure in-between, then the acceleration structure might have been unaware of some changes. Consequently, REDsdk will reset it. As a general rule to avoid this, make sure that every transaction defined in your REDsdk application gets drawn. Its useless to define a transaction and not to render it.
• If the RED::OPTIONS_RAY_USE_EMBREE is modified, the acceleration structure is reset.

CPU acceleration structure update

Updates occur (so this increases the total number of triangles or lines or points to update) on the following conditions:

• An object geometry has changed.
• An object global WCS matrix transform has changed.
• An object's visibility has changed due to a RED::LayerSet interaction with the camera layerset.
• An object's visibility has changed after a context switch callback result change and the RED::OPTIONS_RAY_CONTEXT_CALLBACK_PERSISTENCE is turned off.

Memory usage

Anti-aliasing