Uniforms required for OCIO fragments must be parsed and stored. Currently this is done by create a new reflection table which holds either { name, ValuPtr } pairs or { name, image } pairs. Note: as the Image class resides in the Render module and is not necessary for shader generation at all times, a numeric vector (FloatVec)+ image information is cached instead of an actual Image instance.
These are in turned cached as additional inputs for the implementation definition instance when a OCIO shader node is created.
Later on when the node is asked for constant or uniform creation, this implementation instance is parsed and a new custom uniform block is created. Note that for buffer packing should work but has not been examined yet.
Reflection Step
A color management system (cms) now has a public accessor to get cached data from 1.
The names of the shader code uniforms and the names in the cache are maintained for 1:1 correspondence.
Render Step
At render time the cached uniforms can be accessed and bound.
This has been done for the the sample GLSL backend.
The ImageHandler class has been expanded to allow for creation of Images from a numeric vector, dimension and channel data data. The name of the uniform is the unique key used to cache the image for later reuse.
The GLSL Texture manager has been updated to bind 1D textures instead of 2D ones if the height is 1.
Notes:
There is no 3D image support as of yet so any 3D luts will not be bound. Any extensions will be looked at outside this PR.
It is TBD if it's desirable to move the Image class to the code generation module as it adds additional bloat.
It is TBD if we want a Value type which is an Image (binary blob). This is not likely at this time as a lot of additional infrastructure would need to be reworked and forces the inclusion of Image support to the Core modules (more bloat).
Uniform constant and texture support changes.
Code Generation Step
Reflection Step
Render Step
Notes: