REDsdk 4.3
Welcome to REDsdk 4.3!
API Changes
For those that directly want to jump into the details, see all API changes here: REDsdk 4.3 API Changes.
Overview of Changes
This new version of REDsdk is focused on both extending the REDsdk feature set and also keeping REDsdk efficient and performant. Among all changes, we can note:
Improvements on the rendering quality & performance as seen below in: Enhanced Multiple Important Sampling, Enhanced Probabilistic Light Sampling, and Adaptive Ray-Tracing.
Extensions of the post-processing capabilities of REDsdk as seen below in New Post Processing Features.
Real-time rendering enhancements as seen below in Real-Time Improvements.
Engine enhancements as seen in Debug Output for a Better Error Tracking.
New features such as Clouds.
Some hardware changes as seen below in Hardware Issues.
The draft of a new REDExplorer application. It’s called REDApplication.exe and can be found in the binary folders.
New RNET client / server tutorials.
Browse the page below to discover other changes made for this release!
Clouds
Background clouds in the sky.
We have put a significative effort in REDsdk 4.3 in the development of a cloud rendering solution. REDsdk 4.3 contains two new rendering solutions for clouds, both of which serve different purposes:
True volumetric clouds, detailed in the tutorial Rendering Volumetric Clouds, that are ‘in-scene’ clouds that can interact with other user geometries. These clouds are rendered using the volumetric rendering solution of REDsdk. Therefore, rendering an image using volumetric clouds take time. These clouds are based on procedural algorithms, and may be difficult to control as of today.
Background clouds: these are detailed here: Background Clouds. These clouds only exist in the background sky image of REDsdk. These clouds are based on artistic texture plates that are provided by REDWAY3D and are much simpler to use than volumetric clouds and have more intuitive controls. Background clouds will receive new artwork plates in the coming months (hopefully before REDsdk 4.3 final release date, or as patches after the release date).
Enhanced Multiple Importance Sampling
Enhanced multiple importance sampling.
We have changed the mathematical method used for multiple-importance sampling calculations in REDsdk 4.3. This results in much better results at no cost. The image above compares results got from REDsdk 4.2 with new results got from REDsdk 4.3. All rendering options are identical and rendering times are identical too.
Enhanced Probabilistic Light Sampling
The scene used for light sampling comparisons.
Rendering scenes with many lights could take a fair amount of time. A new development in REDsdk 4.3 reduces the burden of rendering scenes with many lights by improving the probabilistic distribution of lighting samples. On average, scenes render faster AND get a better quality with less noise. Below is a comparison between REDsdk 4.2 and REDsdk 4.3 with identical rendering parameters on an average scene (6 millions triangles, 25 lights, 200 materials): AA = Anti Aliasing level, L = Lights sampling rate, G = glossiness sampling rate.
REDsdk |
AA |
L |
G |
time |
speedup |
|---|---|---|---|---|---|
4.2 |
4 |
8 |
8 |
6’00” |
|
4.3 |
4 |
8 |
8 |
5’24” |
10% |
4.2 |
4 |
16 |
16 |
19’11” |
|
4.3 4 |
16 |
16 |
17’11” |
10,4% |
|
REDsdk 4.2 vs. 4.3 sampling comparisons.
Of course, results may differ depending on the used range of settings, and may also differ depending on the number of lights; but the higher the number of lights the greater the speedup factor using REDsdk 4.3 instead of REDsdk 4.2. Note that this only applies to physical lights. Non physical lights are ignored by these improvements.
Adaptive Ray-Tracing
REDsdk features a new rendering mode based on adaptive sampling for ray-tracing. Adaptive sampling is a technique that reduces the amount of calculation to perform for a pixel based on a quality threshold. Performance savings can reach up to 75% of the rendering time, at the expense of a little loss in quality. The performance gain highly depends on the kind of scene and quality variation, so it’s quite difficult to provide numbers, as this depends both on how the quality loss is perceived and on the scene itself. In most cases, the quality loss is barely visible while the image calculation time savings are up to 50%.
Please refer to the following page: Adaptive Sampling for all details on how to use adaptive sampling in REDsdk.
New Post Processing Features
New post processing effects available in REDsdk 4.3
The set of post-processing effects available in REDsdk has been increased to include a new set of post-effects:
Sharpen
Glow
Blur
Depth Of Field
Then, new color manipulation tools have been added too:
Brightness / contrast controls
Hue Saturation Lightness controls
Input / output levels controls
All these effects are available in all REDsdk modes: hardware, hybrid or software. Please look at Post Processing for details.
Real-Time Improvements
IES profiles are now visible using the GPU.
A few enhancements were made in REDsdk 4.3 to enhance the lighting capabilities of the GPU:
Portals are now visible and rendered by the GPU. Portals are considered as physical lights and are converted to the GPU as any other physical light.
IES profiles are now visible and rendered, with no associated performance cost.
Other miscellaneous enhancements:
Improvements have been made to optimize the management of huge dynamic scene graphs in REDsdk.
Support for the HTC Vive VR helmet has been added.
Extension of the
RED::RenderShaderParameter::REF_INSTANCE_COUNTERto handle images:RED::RenderShaderParameter::REF_INSTANCE_COUNTER_IMAGE.
RED::IWindow::FrameDrawinginterruptions have been enhanced to ensure that on user request, the method will return quickly.
High Definition Matrix Migration
A very important change has occurred in REDsdk 4.3 related to GPU rendering: Due to the recent trends in OpenGL evolution, we have chosen to migrate all REDsdk built-in shaders toward using high definition matrices supplied by REDsdk. This means that all REDsdk 4.3 built-in shaders will be using the high definition modelview and modelview-projection matrices that are defined by REDsdk. This solves ref bk_ra_floating_origins issues and this prepares future changes in OpenGL pipeline where there’ll be no more fixed function pipeline (FFP) matrices definitions available to shaders.
Practically, this implies that:
All REDsdk shaders are now based on REDsdk matrices.
GPU ray-tracing, ray-traced transparency workflows and shadow mapping workflows are all based on REDsdk matrices.
Legacy (4.2 or older) .red files that are containing shaders are automatically migrated toward these REDsdk matrices.
Then, custom shaders may require a migration:
Custom shaders that are involved in shadow mapping and GPU ray-tracing will require changes in names of the transform matrices they use. See the
RED::RenderCode::SetModelViewMatrixandRED::RenderCode::SetModelViewProjectionMatrixcalls for details.Other custom shaders can remain using FFP matrices or can be migrated as wished.
A shader that is not modified and used in one of the REDsdk rendering workflows described above may reveal z-fighting artifacts. This may arise if an internal REDsdk shader uses high definition matrices and the custom shader uses default OpenGL matrices: both matrices are slightly different and rendering different passes with one or the other matrix will cause artifacts to appear. In this case, the shader must be migrated and the matrix names it uses must be changed.
Note
Changing matrix names is done at no performance cost. From a user standpoint, this is just a string name change.
Also, some shaders still require legacy FFP matrices to be used, such as those used for the rendering of OpenGL fonts (see RED::FNT_TRIANGLE, RED::FNT_LINE and RED::FNT_BITMAP types). These texts can be rendered using materials created by RED::IResourceManager::CreateColorFontMaterial. If these texts are rendered using REDsdk built-in shaders, they won’t be displayed anymore until migrated to a shader using legacy transformation matrices.
Debug Output for a Better Error Tracking
A new Error Tracking feature has been added to REDsdk to provide a better feedback on errors. Practically, the hosting application must declare a callback to gather errors at the time they happen. Depending on the kind of error that occur in REDsdk, extra informations may be available then to facilitate debugging. At the same time, a REDsdk error log file is dumped in the binary folder of the application.
We have tried to add extra informations to describe internal errors the best we could, but as this is an endless process, please don’t hesitate to send us those files back with details on the kind of extra informations you’d have appreciated to find, so that we can try to complete our error logs.
Stereoscopic Panoramas
A new tutorial (Creating Stereoscopic Panorama) has been added to show how REDsdk can be used to create stereoscopic panoramas images that can be then loaded to the Oculus or HTC Vive.
Hardware Issues
Several changes have been made to the REDsdk configuration to bypass hardware issues:
The NVIDIA threaded optimization has been disabled for all NVIDIA drivers on starting a REDsdk application. This threaded optimization could cause application crashes. The occurence was low but significative enough to let us disable this option. As soon as this issue gets fixed we’ll enable the threaded optimization again.
On recent INTEL HD graphics, we had several customer application issues reporting a loss in rendered frames (the application window is not refreshed sometimes, even if rendered properly). This has been countered by setting the value of the
RED::OPTIONS_DATA_RELEASE_TIMERto INT_MAX as the new default in REDsdk 4.3. Practically, this means that REDsdk does not release intermediate rendering buffers it uses and keeps a pool of buffers ready to be reused in case of need. As nowadays GPUs have a large amount of video memory available, we don’t think this’ll cause any problem.We have modified the primary GPU detection method, as a result of incorrect values that could be returned by Windows EnumDisplayDevice call (mainly dual GPU Optimus systems with NVIDIA / INTEL GPUs). The new method is OpenGL based, so its result should always match the real GPU used by REDsdk.
