I'm very much in favor of upgrading the DDS support. I'm not much of a DDS guru. However it's stored is fine with me, as long as it appears on the app side of the OIIO APIs as addressable in terms of subimage (slice) and mip level.
OpenEXR is an example where both subimages (what they call "parts") and MIP levels are supported. TIFF only supports subimages, but the OIIO TIFF reader/writer make them look like MIP levels, when the right attributes are set. Field3D is the main volumetric texture format we use at the moment (we use it all the time in production), and the format itself recently added MIPmapping, but we haven't made OIIO's reader catch up yet to support that. TIFF also supports 3D, but I admit that I haven't used it and so I don't know if our support for it is bullet-proof. > On Jun 6, 2016, at 5:25 PM, Jonathan Tilden (2K) <[email protected]> > wrote: > > Hey all! > > We're in the process of updating the DDS importer and implementing an > exporter to support some of the more modern block compression encodings we > use in games today. I'm looking for some advice for how to store the data for > texture arrays, 3d textures, and cubemaps. I'm thinking of something like > this: > - For texture arrays and cubemaps, each slice would be a subimage > - If the texture has mips, store them in subimages with something like this > [00, 01, 02, 03, 10, 11, 12, 13]. The number of mips would be stored as an > imagespec attribute. That would make it relatively easy to find mip0 of every > slice/cubeface > > Does that sound crazy? Or is there some sort of different precedent already > in the code that we can look at? > > Also, I was curious to 3d textures. Is there any precendent for how these are > stored, accessed, and written? > > Eager to get your feedback. Thanks in advance! > -J > > ==================================== > Jonathan Tilden > Principal Technical Artist > 2K Games > Email: [email protected] > Phone: +1.415.507.7623 > ==================================== > -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
