It would be very useful to construct a RhinoCommon Texture object from a memory stream rather than a file path. (FileName and FileReference are the only options at present.) I’m raising the issue because our plugin uses texture mapping to paint falsecolor data onto render meshes. This often involves thousands of maps, which need to be updated progressively every second or so. Having to create thousands of disk files makes this process prohibitively slow. So my questions are as follows:
- How feasible is adding a stream constructor to RhinoCommon?
- Are there any workarounds?
- Ultimately I need to render the textures in a display conduit. As I understand it, this requires a DisplayMaterial. Is there any way to create my own texture evaluator in this case, to bypass the limitations of the Texture class? (Similar question here.)
- If one has to use disk files, is there a trick to ensuring that DisplayMaterials and Textures refresh properly when a file is overwritten? At present, the display pipleline occasionally gets “stuck” on a cached bitmap, even though I’ve created a new Texture and DisplayMaterial from scratch (and confirmed that the bitmap file was correctly overwritten prior to calling these constructors). Changing the file path seems the only guarantee of success, but this incurs big System.IO penalties.