OpenGL
REDsdk is an OpenGL based engine. All hardware accelerated graphics are rendered using the OpenGL API. This chapter will provide some details about the usage of OpenGL made by REDsdk.
A first important point to keep in mind is that even if there's no OpenGL driver installed on the host computer, REDsdk can still run in software. As REDsdk is a hybrid hardware / software rendering engine, it can use whatever is best to leverage the host system capabilities. So if there's no valid OpenGL installation on the system, REDsdk can still run in software (see Software startup for details).
OpenGL Version
REDsdk can run using graphic hardware acceleration on any OpenGL 2.0 or later version. REDsdk is a shader based engine, and needs at least an access to the ARB_vertex_shader and ARB_fragment_shader to operate.
All REDsdk features are available starting with any OpenGL 2.0 installation. REDsdk can take advantage of more recent OpenGL versions, but this is not mandatory to operate REDsdk. Therefore any system which was setup in year 2004 or later should be able to run most REDsdk's features but those that are very power demanding (such as GPU ray-tracing).
OpenGL initialization in REDsdk
The creation of the first window using RED::Factory::CreateREDWindow initializes OpenGL in REDsdk. Before this step, the OpenGL library or DLL is loaded by the system, but it's not initialized. Any identified OpenGL driver initialization problem will be returned as a RED_RC value by RED::Factory::CreateREDWindow. Specifically, RED_RC return codes starting with 'RED_DRV_*' may be returned, indicating an error trapped in the OpenGL driver layer.
Integration of REDsdk in an existing OpenGL application
REDsdk can be added to an existing OpenGL application without breaking that application's rendering pipeline. For this a REDsdk window can be initialized from an existing application OpenGL context. This procedure uses the RED::WindowRenderInfo class to supply external host application context informations to the RED::Factory::CreateWindow method. See all the details in Integration into an existing OpenGL application.
OpenGL queries
A REDsdk based application can get informations on the underlying OpenGL implementation. For each base query, there's a corresponding REDsdk method:
- GL_VENDOR: RED::IWindow::GetHardwareVendor,
- GL_EXTENSIONS: RED::IWindow::GetOpenGLExtensions,
- GL_RENDERER: RED::IWindow::GetRenderer,
- GL_VERSION: RED::IWindow::GetOpenGLVersion.
GPU vendor identification
In addition, the GPU vendor can be identified further using one of the known vendor identification methods:
- NVIDIA hardware: RED::IWindow::IsNVidia,
- ATI hardware: RED::IWindow::IsATI,
- INTEL hardware: RED::IWindow::IsINTEL.
Finally, the RED::HARDWARE_PLATFORM corresponding to the operated system GPU can be accessed using RED::IWindow::GetGPUChipset. This will provide a finer information on the used hardware platform.
GPU class limitations
Some GPU classes identified by their RED::HARDWARE_PLATFORM tags can't operate some of the REDsdk features. These limits are due to an insufficient power of the GPU to do the requested calculations. These features are disabled to avoid seeing the application freezing for a long time. The corresponding query methods can be used to identify any weakness here:
- RED::IWindow::IsNoRayTrace: Identify all GPUs that have no GPU accelerated ray-tracing capability.
- RED::IWindow::IsLimitedRayTrace: Identify all GPUs that only have a simple ray-tracing capability (shadows, simple reflect / refract, no dispersive calculations such as area shadowing, or reflection glossiness).
- RED::IWindow::IsLimitedAreaLighting: Identify all GPUs that don't have the capability to display area lights in real-time. This is due to an insufficient shading power of the GPU. For these GPUs, area lights are replaced by centric point lights that are faster to display.
- RED::IWindow::IsNativeHDR: Identify all GPUs that can't use blending equations with floating point render targets. Very old GPUs didn't have the necessary hardware components to do these blending operations and were falling back to software OpenGL (!) in this case.
Immediate mode rendering option
REDsdk uses VBOs for the processing of the data to be displayed. However, in some very specific circumstances, it may be wishful to revert back to the legacy immediate more rendering style. This will sloooow down the rendering a lot, but if:
- There are corrupted geometries appearing on screen due to driver issues, or
- The polygon memory can't fit in the GPU memory,
The RED::OPTIONS_IMMEDIATE_MODE can be used to offload the GPU or to bypass some issues with it to still display the graphic data using the GPU
![]() | Metal![]() |