Thanks for the feedback. Yes, my initial stab is leaning toward <UDIM> with
offset 1001 and 10-wide, and <u> <v> with 0-offset and <U> <V> with 1-offset.
If any other cases come up in practice, we can extend the syntax to handle
other offsets or widths, but for now I think it's best to keep it simple and
not over-engineer a solution to a problem that does not exist in practice.
I'm making progress on this, and should have an initial review for comment soon.
-- lg
> On Jun 2, 2016, at 12:19 AM, Michel Lerenard <[email protected]> wrote:
>
> Same here.
> We have UDIM hardcoded to 10 and U/V offset chosen depending on
> low/uppercase, ie 0 or 1 and never got any complaint/request to support more.
>
> On 06/02/2016 12:27 AM, Deke Kincaid wrote:
>> Mari used to do this when it was an in house tool but as commercial software
>> it has always been limited to 10 UDIM's across.
>>
>> On Wed, Jun 1, 2016 at 2:12 PM, Larry Gritz <[email protected]
>> <mailto:[email protected]>> wrote:
>> In practice, does anybody use UDIM with width other than 10? Or u & v tiles
>> with offset other than 0 or 1?
>>
>>
>>> On Jun 1, 2016, at 12:13 PM, Ramon Montoya Vozmediano <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> We are interested in testing it!
>>>
>>> The Arnold and MtoA usage is the following:
>>> <UDIM:width> or <udim:width> : default width is 10
>>> output: "%04d"
>>>
>>> <tile:offset> : mudbox (default offset 1)
>>> output: "_%d_%d"
>>>
>>> <utile:offset>, <vtile:offset> : default offset is 1
>>> output: "%d"
>>>
>>> <u:offset>, <v:offset> : default offset is 0
>>> output: "%d"
>>>
>>> <U:offset>, <V:offset> : default offset is 1
>>> output: "%d"
>>> Those have accrued with time and might be in need of some cleanup. But I
>>> have seen variable widths for UDIMs.
>>>
>>>
>>>
>>> A related issue is token replacement in general: in many systems it's
>>> possible to specify a texture name based on some user data attached to the
>>> geometry being shaded:
>>>
>>> "crowd_body_<user_attribute:variantID>_<udim>.tx"
>>>
>>> where for each render object you have a user defined string (or numeric)
>>> attribute indicating its texture variant.
>>>
>>> Because dealing with token replacement like that one shares some of the
>>> work required for tiles it's interesting to at least consider what would be
>>> needed from OIIO to handle the general case.
>>>
>>> It would involve letting user code resolve certain tokens with user defined
>>> callbacks and pointers to data (a token replacement closure).
>>>
>>> So a sketch for a more generic approach: before starting to use textures
>>> client code would register token resolvers:
>>>
>>> std::string CustomTokenResolver(std::string &token_data, void *caller_data)
>>> { /* use caller_data to resolve our token */ };
>>>
>>> ...
>>> OIIO::RegisterCustomTokenResolver("user_attribute", CustomTokenResolver);
>>> ...
>>>
>>>
>>> And when evaluating textures it would pass along some data to be used by
>>> the resolver if needed:
>>>
>>> void *caller_data_for_resolver = (void *)data;
>>> ...
>>> my_texture_lookup = OIIO::texture(handle, u, v, ....,
>>> caller_data_for_resolver);
>>>
>>>
>>> Best,
>>>
>>>
>>> r
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jun 1, 2016 at 12:29 AM, Michel Lerenard <[email protected]
>>> <mailto:[email protected]>> wrote:
>>> Yes.
>>>
>>> Mudbox and Zbrush support individual tags like you said, meaning they could
>>> be far from each other (like foo_<u>_bar_<v>.tx), but they tags are almost
>>> always right next to each other(foobar_<u>_<v>.tx), in which case having a
>>> single <uvtile> tag is easier (foobar_<uvtile>.tx).
>>>
>>> To be able to cover all cases, I support all three tags: <u>, <v>,
>>> <uvtile>, low and high case.
>>>
>>>
>>> On 05/31/2016 09:09 PM, Larry Gritz wrote:
>>>> OK, so the generalized rule is:
>>>>
>>>> <u> --> "%d", int(u)
>>>> <v> --> "%d", int(v)
>>>> <U> --> "%d", int(u)+1
>>>> <V> --> "%d", int(v)+1
>>>> <UDIM> --> "%04d", int(u%10) + 10*int(v)/10 + 1
>>>>
>>>> That should cover all the bases of known apps we're concerned about?
>>>>
>>>>
>>>>> On May 31, 2016, at 11:58 AM, Deke Kincaid <
>>>>> <mailto:[email protected]>[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>> Maya added native optional UDIM/UVTILE and Zbrush methods in the read
>>>>> node about 3 years ago.
>>>>>
>>>>>
>>>>> <https://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2015/ENU/Maya/files/GUID-132520C0-F1DF-4C74-B8C1-D89154ADFBDB-htm.html>https://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2015/ENU/Maya/files/GUID-132520C0-F1DF-4C74-B8C1-D89154ADFBDB-htm.html
>>>>>
>>>>> <https://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2015/ENU/Maya/files/GUID-132520C0-F1DF-4C74-B8C1-D89154ADFBDB-htm.html>
>>>>>
>>>>> 0-based (Zbrush) - u<u>_v<v>
>>>>> 1-based (Mudbox) - u<U>_v<V>
>>>>> UDIM (Mari) - <UDIM>
>>>>>
>>>>> On Tue, May 31, 2016 at 11:44 AM, Stephen Parker <
>>>>> <mailto:[email protected]>[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>> tl;dr - support both udim and uvtile
>>>>>
>>>>> V-Ray supports both <UDIM> and <UVTILE> and those are the exact tags used
>>>>> in the filename for string replacement. At Digital Domain, they
>>>>> exclusively use <UVTILE> as it plays nicer with animated texture
>>>>> sequences. At some point, Maya only allowed you to overload one padded
>>>>> sequence token between two dot's (.). So the file names for <UVTILE>
>>>>> would look like this:
>>>>>
>>>>> "brick_red_u1_v1.exr"
>>>>>
>>>>> and if it were an animated texture:
>>>>>
>>>>> "sign_neon_u1_v1.0001.exr".
>>>>>
>>>>> To be clear, the format string is "_u%d_v%d" and tiles start at 1.
>>>>>
>>>>> Mari's convention for animated textures was to prepend the file name with
>>>>> padded numbers: "####sign_neon.1001.exr" (which didn't play nice with
>>>>> Maya's texture file node and it's convention for animated sequences) and
>>>>> was also not easy to look at on disk in a directory structure for obvious
>>>>> sorting issues.
>>>>>
>>>>> I wouldn't impose any constraints from tile to tile unless it's a really
>>>>> big burden to support. For example, anything that isn't specified on the
>>>>> file read node representing the virtual texture, should be permitted to
>>>>> vary to whatever extent you can reasonably support. Ideally, you wouldn't
>>>>> have to ... but, vfx. :)
>>>>>
>>>>> -steve
>>>>>
>>>>>
>>>>>
>>>>> On Tue, May 31, 2016 at 8:35 AM, Larry Gritz <
>>>>> <mailto:[email protected]>[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>> Thanks, that's really helpful!
>>>>>
>>>>> Yes, and I should have mentioned in my original email -- if there is an
>>>>> application that has already added UDIM support that is widely used or
>>>>> that you like its conventions, please point it out and I'll try to use
>>>>> the same notation (if there is any consensus among such apps).
>>>>>
>>>>> Michel, I'm happy to support the Mudbox tiling as well, can you outline
>>>>> how it is different?
>>>>>
>>>>>
>>>>>
>>>>> > On May 31, 2016, at 2:51 AM, Michel Lerenard <
>>>>> > <mailto:[email protected]>[email protected]
>>>>> > <mailto:[email protected]>> wrote:
>>>>> >
>>>>> > Hi,
>>>>> >
>>>>> > I add support for UDIM in Clarisse over the TextureSystem a few years
>>>>> > ago, I should have a few answers:
>>>>> >
>>>>> > - I used the <UDIM> tag. "%04d" is too generic and may confuse users in
>>>>> > my opinion, since it could also be a way to specify a frame. Having an
>>>>> > explicit tag that stands out is useful. (so we have two tags: <UDIM>
>>>>> > for Mari and <UVTILE> for Mudbox. )
>>>>> >
>>>>> > - Agree that UDIM is single tile. Tile indice in UDIM is hardcoded in
>>>>> > Clarisse to 1000 + 10 * V + U + 1. Mari seems to be harcoded as well,
>>>>> > so unless you have a in house software package that support other
>>>>> > sizes, I don't think you'll need another line width. We've never had
>>>>> > any complaint so far.
>>>>> > Per texture option : useless.
>>>>> > At texture system level: why not, it shouldn't make the code much more
>>>>> > complex.
>>>>> >
>>>>> > - In my implementation, I do not make any assumption on the data: it
>>>>> > may or may not exist for a UV range, resolution may change, so
>>>>> > does AOV/channels.
>>>>> > It's not the most efficient way to go, but I'm sure that it will work
>>>>> > every if you mix mipmapped TX files with loads of AOV with simple Jpegs.
>>>>> >
>>>>> > Here are a few thoughts that I'd like to share with you about this
>>>>> > feature:
>>>>> > - The main issue I have today is being able to use filtering over
>>>>> > several tiles. I compute the name of the file to evaluate, and offset
>>>>> > UVs before calling the texture() function, which means that OIIO does
>>>>> > not know that I'm evaluating UDIM tiles => I can't get any filtering on
>>>>> > the sides of the tiles, or integrate data over several tiles. Making
>>>>> > this work would be awesome.
>>>>> >
>>>>> > - Listing the available tiles for fast access can be easily done. What
>>>>> > I do is parse the folder, get all files matching the filename and
>>>>> > create an array to later be able to evaluate a tile without accessing
>>>>> > its filename. Very efficient especially if you have holes.
>>>>> >
>>>>> > - Do you plan to support Mudbox tiling system as well ? It's not that
>>>>> > different and is able to handle negative ranges, which is very pratical
>>>>> > for symmetry.
>>>>> >
>>>>> > - I'm interested in testing it, i'm curious to see if it's faster than
>>>>> > my implementation, in which case i'd switch.
>>>>> >
>>>>> >
>>>>> > On 05/30/2016 11:41 PM, Larry Gritz wrote:
>>>>> >> I've gotten a few requests lately for direct UDIM support in OIIO
>>>>> >> (and, transitively, in OSL).
>>>>> >>
>>>>> >> The way I figure this will work is that you pass in the UDIM u and v
>>>>> >> texture coordinates (which may extend outside [0,1], with each [i,i+1)
>>>>> >> block indicating a different texture region tile), and for the
>>>>> >> filename you will give a generic name such as "myfile.<UDIM>.tx". For
>>>>> >> the particular texture lookup, the u and v will be assessed and the
>>>>> >> "<UDIM>" will be replaced with the right tile number (let's say "1013"
>>>>> >> for u=0.25, v=0.12).
>>>>> >>
>>>>> >> Don't worry, I know a way to do this so that there is no actual string
>>>>> >> searching or construction happening per call. So the expense of this
>>>>> >> will be very very low.
>>>>> >>
>>>>> >> But I want to make sure everybody is happy with the way of signalling
>>>>> >> this, so I have a few questions.
>>>>> >>
>>>>> >> * 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?
>>>>> >>
>>>>> >> * 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?
>>>>> >>
>>>>> >> * 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?
>>>>> >>
>>>>> >> * 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?
>>>>> >>
>>>>> >> 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.
>>>>> >>
>>>>> >> -- lg
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Larry Gritz
>>>>> >> <mailto:[email protected]>[email protected]
>>>>> >> <mailto:[email protected]>
>>>>> >>
>>>>> >>
>>>>> >> _______________________________________________
>>>>> >> Oiio-dev mailing list
>>>>> >> <mailto:[email protected]>[email protected]
>>>>> >> <mailto:[email protected]>
>>>>> >>
>>>>> >> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>> >> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>> >>
>>>>> >
>>>>> > _______________________________________________
>>>>> > Oiio-dev mailing list
>>>>> > <mailto:[email protected]>[email protected]
>>>>> > <mailto:[email protected]>
>>>>> >
>>>>> > <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>> > <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>>
>>>>> --
>>>>> Larry Gritz
>>>>> <mailto:[email protected]>[email protected]
>>>>> <mailto:[email protected]>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> <mailto:[email protected]>[email protected]
>>>>> <mailto:[email protected]>
>>>>>
>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> <mailto:[email protected]>[email protected]
>>>>> <mailto:[email protected]>
>>>>>
>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> <mailto:[email protected]>[email protected]
>>>>> <mailto:[email protected]>
>>>>>
>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>
>>>> --
>>>> Larry Gritz
>>>> [email protected] <mailto:[email protected]>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>
>> --
>> Larry Gritz
>> [email protected] <mailto:[email protected]>
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>
> _______________________________________________
> 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
