During the most recent OpenFlight User Group Webinar (November 2013), we talked briefly about Switch Textures and Switch Materials - both potentially new constructs to be added to the OpenFlight file format.
The background of these topics is included here:
Currently (as of OpenFlight v16.4) OpenFlight models have a texture palette in which each texture (image) file contained in that palette is assigned a unique index. Geometry in the scene (represented by face or mesh nodes) can have texture applied. Base texture is associated to a face or mesh node via this texture palette index. In this way, each face or mesh geometry can be assigned exactly one base texture. Face and Mesh geometry have 7 additional texture layers. The semantics of these additional layers is not strictly enforced or defined by OpenFlight. In other words, OpenFlight consumers can use these additional layers for any purpose they see fit. Often, these texture layers are used to define texture variations on models. While this is useful, it might be better for the OpenFlight format to define/support a formal mechanism for this.
We are considering Switch Textures or Switch Materials (or both?) for the next revision of the OpenFlight file format (which would be 16.5). Attached on this thread is more detailed description for two solutions under consideration.
We invite you to review the attached document and add your comments here.
Would you use either? If so which one? Or both? If only one was added to the OpenFlight format, which one should it be?
All comments are welcome.
Thanks in advance.
The texture sets idea can be accomplished currently by saving out palette files of like textures (OD, Green, Tan, Summer, Winter etc) the format is palnum, patnum, x, y, texture name. So to swap texture representation just load the desired texture palette...
How does this differ? will the texture sets be stored differently?
The difference is that the switch mechanism is not placed in OpenFlight. In that scenario, the runtime is responsible for doing the switch. It has to know that this model can switch, and know where to find the data to switch on. Both of these pieces of information need to be coded by the individual setting up the runtime.
If we encode this information in the flt file, then the files generated are more robust. They will still work when opened years later by a new viewer or runtime. They will also work on a broader range of viewers, not just the single application set up to load them, so the assets created in this way can be shared and repurposed more easily.
I see you are extending the format to store this information. when I initlally read this I thought it was from a UI perspective. makes sense I think this would be value add to the format.
So the question is, what would add more value to you... The ability to switch textures, or the ability to switch materials? (remember extended materials have textures) Do you need the ability to include things like reflectivity and specularity in your switch? It might be handy to represent wet surfaces in rainy seasons. Or do you not use Extended Materials and just want the simplicity of switching textures alone?