UVTILE is synonymous with Mudbox. On May 31, 2016 11:57 AM, "Larry Gritz" <[email protected]> wrote:
> 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]> 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]> >> 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] >> >> >> >> >> >> _______________________________________________ >> >> Oiio-dev mailing list >> >> [email protected] >> >> 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 >> > > _______________________________________________ > 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 > >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
