To understand the role of RC we begin with a very high level and simplified diagram;
/--> [ RenderChimp ]
/ |
[ Application ] |
\ v
\--> [ RC::Renderer ] --> [ Low-level graphics ]
(OpenGL)
(OpenGL ES)
(Software ray tracer)
(...)
The first thing to notice is that the Application has no direct contact with the underlying, low-level graphics API. All the rendering calls and state changes goes through a Renderer which is responsible for handling and relaying rendering tasks. Different Renderers can use wildly different rendering techniques. Probably the most commonly used are the different OpenGL renderers, but to this date there is also a Cuda ray tracer and a software rasterizer. New renderers can be added, and the only requirement is that they comply with the set of functions specified in Renderer.h. It cannot be expected that all platforms will be able to run all different types of renderers. Invalid combinations should result in compile time errors.
It is important that the Application never directly calls the low-level graphics API since this can cause undefined behavior and crashes.
(Important note: As of yet, the Renderer is not static. You must call renderer-> to access its members and functions. This will be fixed in the future.)
Next we take closer looks at the different sub systems of RenderChimp.
1.7.2