Hi, thanks for the feedback, Bruce.
There was pretty wide consensus, so I already have a proposed implementation
that works as you desired (except for the multi-part UDIMs):
https://github.com/OpenImageIO/oiio/pull/1426
<https://github.com/OpenImageIO/oiio/pull/1426>
Also a companion PR for people who need a way to flip the vertical orientation:
https://github.com/OpenImageIO/oiio/pull/1428
<https://github.com/OpenImageIO/oiio/pull/1428>
Please give it a spin! It's not merged into master yet, but you can apply the
patch (or in your tree, cherry pick it) just to try it out.
I'd never heard or thought of the multipart UDIMs. That's a neat idea, I'm sure
we can make that work somehow. It seems in that case that you want to give it
the one and only true filename (no translation necessary), but then have the
UDIM tile select a subimage ("part", in EXR terminology). I think that if we
build this into maketx somehow, it can also add an attribute into the header
that identifies it as a UDIM file.
IIRC, OpenEXR multi-part files are not allowed to have differing resolutions
for the parts. Is this not a fatal flaw here? Or in practice is that not a
problem for you? I would have thought that allowing the different "tiles" to
have differing resolutions (higher res for tiles corresponding to large pieces
of the model, etc) would be typical for UDIM practice. No?
> On Jun 9, 2016, at 2:17 PM, Bruce Tartaglia <[email protected]>
> wrote:
>
> 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
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
