Re: Lots of very high res textures

["Andy Jones" <andy(at)thefront.com>]

D'oh!  I'd left off the -r.  Will update when I have the new .maps generated.  Thanks, guys.

- Andy

On 1/3/08, Colin Doncaster < colin_doncaster(at)yahoo.ca> wrote:

To quickly follow up, looking at the imf_copy docs.

You might want to try tiled maps -
"-r When writing to a memory-mapped .map file, arrange pixels in
rectangles instead of the normal scanline order. This increases cache
efficiency and reduces memory usage when rendering. Files created in
this way can only be rendered with mental ray 3.2 or higher, which is
why it is not enabled by default."

and here is the info on feeding it specific maps for each pyramid level

"-c When writing to a memory-mapped .map file, collate up to 20 input
files to form an image pyramid. This option gives control over the
image pyramid, unlike the -p option which automatically creates each
successive pyramid level at one-half the resolution of the preceding
one, using a box filter. The first input image should have full
resolution, the next one approximately one-half width and height, the
next one approximately one quarter, and so on. Files created with this
option can be read by any mental ray 3.x version."

once you create your R/G/B level mip map it's a good idea to store it
somewhere on disk for future debugging.  Because it's area sampled you
probably want to create a 512k, 1k and 2k version of the map based on
rendering resolution etc.

colin.



On 4/01/2008, at 8:50 AM, Colin Doncaster wrote:

>
> hey andy,
>
> If the pyramidal textures are working correctly this should already
> be happening, it's really the whole point of them really.
>
> If mental ray is handling them the way most pyramidal textures
> should be handled, there is header information telling the renderer
> how many levels and what resolution those levels are.  The sample
> area is calculated and the correct level is sourced from disk, thus
> effectively ignoring the higher res levels - and MR should already
> be doing this adaptively.
>
> If there is a way of explicitly setting the texture for each pyramid
> sample you should be able to give the pyramid a red, green and blue
> map for the different levels.  Apply this map to your geometry and
> pull away from it and you should be able to visually see what level
> of the pyramid MR is choosing based on your sampling settings.
>
> You'd probably end up with more problems if you break the texture
> up, just more disk thrashing etc.
>
> You really should run some tests to see if the maps you created are
> being used correctly by MR, the renderer might be accessing the
> highest res texture all the time even though it should be using the
> different levels.
>
> colin.
>
> On 4/01/2008, at 8:27 AM, Andy Jones wrote:
>
>> I guess part of what I'm getting at is that I'd like to see that
>> workflow (of down-rezing) absorbed into the pyramidal map format.
>> I.e., I'd like to be able to have an 8K texture on disk, but tell
>> mental ray to ignore the bottom layers to make it behave like a 2K
>> texture (or whatever I specify).  Or, better yet, MR would do that
>> adaptively, with as little performance loss as possible.
> <snip>
>>
>> Oooh, wait -- I just got an idea.  Maybe the 8K texture should just
>> be tiled into separate 2K textures (or whatever size is deemed
>> efficient -- probably it would be a user setting).  There's a small
>> amount of redundant data, but it would typically be pretty
>> negligible, I think.  You could implement this sort of thing
>> manually, in the form of breaking your texture apart into separate
>> textures, but really what you want is something that's encapsulated
>> in the .map format.  Otherwise, dealing with seams will always be a
>> nightmare, and even if you get the UV's to line up, you won't be
>> able to properly filter across them.
>
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
> body:
> unsubscribe xsi

---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi