First stab at this: https://github.com/OpenImageIO/oiio/pull/1426 <https://github.com/OpenImageIO/oiio/pull/1426>
> On Jun 2, 2016, at 10:01 AM, Larry Gritz <[email protected]> wrote: > > 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] >> <mailto:[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] <mailto:[email protected]> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > -- > Larry Gritz > [email protected] <mailto:[email protected]> > > > _______________________________________________ > 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
