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
