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
# 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
<[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
<[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
>>
>
> _______________________________________________
> 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]
<mailto:[email protected]>
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
_______________________________________________
Oiio-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
