I've seen it been done in the past (due to precision issues), but that was an extreme case and arguably the asset should have been UV'd better...
Keep in mind in terms of tokenisation it's unfortunately possible to have tokens multiple times in a path (say at directory level as well) which makes fast token replacing without any allocation a bit more interesting... Peter On Thursday, 2 June 2016, Larry Gritz <[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] > <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[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 <[email protected] >> <javascript:_e(%7B%7D,'cvml','[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 >> >> - 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 < >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> [email protected] >> <javascript:_e(%7B%7D,'cvml','[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 <[email protected] >>> <javascript:_e(%7B%7D,'cvml','[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 < >>>> <javascript:_e(%7B%7D,'cvml','[email protected]');> >>>> [email protected] >>>> <javascript:_e(%7B%7D,'cvml','[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 >>>> >> [email protected] >>>> <javascript:_e(%7B%7D,'cvml','[email protected]');> >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> Oiio-dev mailing list >>>> >> [email protected] >>>> <javascript:_e(%7B%7D,'cvml','[email protected]');> >>>> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>> >> >>>> > >>>> > _______________________________________________ >>>> > Oiio-dev mailing list >>>> > [email protected] >>>> <javascript:_e(%7B%7D,'cvml','[email protected]');> >>>> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>> >>>> -- >>>> Larry Gritz >>>> [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');> >>>> >>>> >>>> _______________________________________________ >>>> Oiio-dev mailing list >>>> [email protected] >>>> <javascript:_e(%7B%7D,'cvml','[email protected]');> >>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>> >>> >>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> >>> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> >> >> -- >> Larry Gritz >> [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');> >> >> >> >> >> _______________________________________________ >> Oiio-dev mailing [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> >> > _______________________________________________ > Oiio-dev mailing list > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > > -- > Larry Gritz > [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');> > > >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
