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]> > 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 <[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> >>> >>> 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 <[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 >>> >> [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> >>> >>> -- >>> 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
