Thanks, this input is really appreciated! <UDIM> and <UVTILE>, check!
Is Mudbox yet a third option, or is it covered by these? > On May 31, 2016, at 11:44 AM, Stephen Parker <[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 <[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] > 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
