Hi Larry, We wanted to provide you our answers to your original UDim questions listed below. We're all curious to get your thoughts. Thank you!
* What text should indicate that it's a UDIM texture and which will be substituted with the tile number? "<UDIM>"? "%04d" or some other explicit format indicator? Something else? A: “<UDIM>” in the filename, and then replaced with the UDim value, say 1025, is what we use, so we support this format. * Does everybody agree that UDIM tiles are 1-D (i.e. a single tile number, not a separate u and v tile in the filename), start with 1001, are 4 digits, and always have 10 tiles in the u direction? Can this be hard-coded, or does it need to be an option to the ShadingSystem (that could be overridden on a per-site/per-product basis), or does it need to be something that can be specified separately for every texture? We agree with your premise. 4 digits. Always have up to 10 tiles in the u direction. For us, this is hard coded, so again, we are fine with this. * Because the filename you pass is "virtual" -- that is, "foo.<UDIM>.tif" doesn't actually exist, it's only turned into a proper existing filename in the midst of a lookup for a particular u,v -- this means that TextureSystem::get_texture_info which lacks uv coordinate parameters must necessarily fail for most queries, since you don't know which individual texture region file should be used. Does that sound reasonable for those queries to fail? That sounds reasonable to us. * Are there any properties that you feel strongly should or should not be constrained to be identical for all of the individual region files for one UDIM texture? I assume we want to allow the region tiles to have differing resolutions, say. But should/can we assume that they must all share the same number of channels? Are there any cases I need to be aware of where differences are nonsensical? Any cases where differences are inevitable and I need to ensure that such flexibility is allowed? We only assume that all region tiles have the same number of channels. * Let me know if you have opinions. As well, even if you are fine with the proposal but are keen to try out the UDIM support as soon as it's available, let me know so I can ping you for feedback when it's ready to take for a test drive. We would love to try out the UDim support. We developed our own in house UDIM support on top of OIIO, but centralizing out texturing into OIIO is something we strive to do. We would like to make an additional request regarding MultiPart UDims We use both MultiFile (what you outline here) and MultiPart (subimages within one exr file) UDims. To briefly review the MultiPart setup, all subimages - and their related mipped versions - exist in one file. The UDim number value (eg. 1001) is then used to access the correct subimage in that one file. Currently in OIIO, the subimage name is stored as a string, but as you mentioned in your earlier emails, this can easily be tweaked so that we don’t need string compares at lookup time. It would be great if OIIO could support this as well - both the texture system / image cache, as well as add the ability for tools like maketx and oiiotool to work on multi-part .exr files (currently maketx only tiles and mips the first subimage and loses the rest of the data). As a result, our current workflow uses a two step process of running maketx on the original non-multipart exrs and then combine those results with the exrmultipart tool. Is it possible to combine these into a one step maketx command? For us, the benefits of MultiPart and MultiFile UDims depend on which part of the workflow you are in. So to that end, we use both types of UDims again, depending on how the textures are being used. Thank you again from all of us!
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
