Generalizing image and texture management #903
Description
As stated in the PR #901, it could be helpful to have better texture management than a simple, openGL oriented and strongly limited one.
Let me recall here what I understand on texture management on Radium
- texture/image management is clearly OpenGL oriented and lack features to update, sample and access texture on CPU side
- texture/image management is very limited wrt to input/ouput file format (only the ones supported by std_image_load) and relies on strong assumptions on color space on loaded images
- texture/image management is not thread safe
- texture/image cache is dependant on the initialization of OpenGL subsystem
- managing dynamic textures requires some specific code that is not so easy to setup or maintain to be usable by all the Radium component.
OpenImageIO (https://github.com/OpenImageIO/oiio) might be considered as a valuable replacement of hand-made image and texture operations in Radium.
While not being a direct replacement of our texture manager (the Texture manager migh become a wrapper over oiio), oiio will offer high quality services to manage image and texture data and the texture manager might be replaced by a proper usage of oiio API.
Oiio might be added to Radium Engine as an external library available from the Core component to allow image and texture operations without relying on the Engine and on the OpenGL subsystem initialization.