RE: Lots of very high res textures

["Schoenberger" <XSI(at)digidragon.de>]

>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). 

 

That's reminds me of a different trick.

For one characters head we have used one texture for the front face and one for the "hair thing stuff" (there have been a lot of geometry for that stuff on the back head, not allowed to show you a picture :-(  )

Then two UV projections (front, back) and a simple 256x256 black-white texture to mix them.

-two 4k textures would have given me nearly the same detail ammount as one 8k texture, but they use half of the memory.

-Much more control over the detail (as I can down-scale textures for front and back indepententely).

-MRay does only load the textures needed, and there are only a few areas in the image where it needs both textures.

 

Holger Schönberger
technical director
The day has 24 hours, if that does not suffice, I will take the night

 

---

From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On Behalf Of Andy Jones
Sent: Thursday, January 03, 2008 8:28 PM
To: XSI(at)Softimage.COM
Subject: Re: Lots of very high res textures

Those are definitely good workflow tips.  In practice, I've never had a need for more than one or two really high res textures in my scenes.

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.

Although I agree with what you're saying about the typical use of painted 8K textures today, I think it's pretty easy to imagine scenarios where the 8K texture contains detail you'd actually want to recover in close-up shots.  Right now, if I had a shot that zoomed from far away to really close on a surface painted with an 8K texture, I'd probably want to render with a 1K or 2K texture and blend to the 8K to make it as fast as possible.  And it's dumb to have to do that, since the 1K and 2K textures are already a subset of the 8K.

Regarding fractals, I definitely use them all the time.  A problem I have, though, is that it's a lot harder to pass assets around a pipeline with fractals in the shader trees and have them not buzz or do other weird things.  Yes, there are ways to deal with this properly, but I've found that using textures (even rendermapped textures generated from fractals) is a lot less error-prone in many situations.  When it's just me rendering something, I tend to use fractals like crazy.  Especially since I'm not so great at Photoshop...  Being able to exclusively use self-anti-aliasing fractals is a whole other topic.

The 64-bit thing Francois mentioned is also a pretty big problem at the moment.  To me, it's just further evidence that the .map format is a bit of a hack.  Like, they basically took their existing uncompressed image structure, and wrote it to disk.  I think the problem here is that what worked well in memory does not necessarily work well on disk.  Even though they're able to directly address specific locations on the file, that doesn't make it like true "random access" without a performance hit.  It's also unclear what order the data from the .map structure is being read by the filtered texture lookup.  Depending on the layout of the file format, you might want it to stick to one resolution at a time.  Like, read all the 512 chunks it needs, then read all the 1024 chunks, then all the 2048 chunks.  It's unclear whether it's doing that now.

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.

I suspect there's probably still an even better way to structure the .map files.  The above is one idea that seems like it would definitely already work a lot better.

- Andy

On 1/3/08, Schoenberger <XSI(at)digidragon.de> wrote:

>Now, I'll just shut up and down-rez all my textures to 1/4th resolution.

 

That's the best you can do

For texture painting, the painter should use high resolutions to get rid of a "low-res-look" in the texture.

Then you can often scale it down for rendering, the texure will be antialiased by scaling it down.

 

Then I do some tests, which is the render resolution you really need.

I have some folders with the textures at different resolutions.

I render a region of a closer shot, replace the texture by a lower version and so on until I really see a difference.

Often you need different resolutions for different textures. e.g for my last character I had textures which ranged from 750 to 2048 pixels (all for the head, but different usages, e.g. masks for mixing had the lowest resolution).

 

And for the really closeups a 4k texture was not enough (I don't think 8k would have made a difference), so I just mixed a fractal into the color and bump and got the detail.

 

 

Holger Schönberger
technical director
The day has 24 hours, if that does not suffice, I will take the night

 

---

From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On Behalf Of Andy Jones
Sent: Thursday, January 03, 2008 4:58 AM
To: xsi(at)Softimage.COM
Subject: Lots of very high res textures

Okay, let me preface this by saying I know it's kind of ridiculous to try to render with a bunch of 8K 32-bit floating point textures.  I have an asset that I got from another vendor that came with multiple 8K maps for different parts of the shading (diffuse1, diffuse2, spec1, spec2, etc. -- like 8 maps per surface total).  And there are about 5 different shaders on the asset.  So, all told, I'm looking at about 25GB of texture data (when uncompressed).  And, after converting the files to pyramidal .map files, I'm up to 53 GB.  Obviously, that's WAY overkill for the single frame of the asset at a sort of far distance that I have to render.  But it's not that common that I end up with an asset this heavy on textures, so I figured I'd have a go at getting it to actually render.

I'm still experimenting, but so far, I've noticed some pretty interesting things.

1) I'm taking it for granted that I must use pyramidal .map files.  I didn't even bother trying this without doing that, but I'm pretty sure it's true.
2) In conjunction with pyramidal .map files, elliptical filtering works at a reasonable speed for lookups on a single texture, and didn't seem terribly slower than disabling elliptical filtering (though I found that a little surprising).  So, most of my tests were done with elliptical filtering (20, 4, .3).
3) For those of us like me who often lazily don't set a Mental Ray memory limit, you'll need to do that.  Otherwise, MR has an increased tendency to choke on memory allocation.
4) If I draw a region, the render speed increases dramatically when I refresh.  For example, an experimental "first round" render time was about 1m31s, whereas refreshing the region took only 16s.  My hypothesis for this is that the hard disk's cache is simply doing its job.
5) If I enable more than one texture per sample (for example, if I'm using both a spec map and a separate diffuse map), I experience dramatically increased render times.  For example, 3m12s vs 14m17s. My hypothesis for this is that the hard disk is having to seek back and forth between the two textures which live very far apart from each other on the disk (since they are 8K).

Together, 4 and 5 suggest a possible optimization whereby one would benefit from simply rendering each texture individually to an empty buffer, then re-rendering the multi-textured surface samples (presumably pulling textures straight out of the cache the second time around).  Or, you could render in multiple passes, restricting each pass to a single texture (though this gets really really complicated, if not impossible, when you get to things like reflections, where you're casting multiple rays per sample).

6) For these renders, my CPU utilization is generally down to about 6%, for the obvious reason that all the time is being spent doing lookups on textures.  What I would really like is a way to manually "kill off" perceived texture resolution in my .map files, so that MR effectively ignores a specified number of the highest resolution layers of the pyramid, so that I could force myself back to renders with more reasonable CPU utilization.  While there's an obvious way to do this (down-res the texture and regenerate the .map), it's a lot of extra work that doesn't seem like it should really be necessary, since the resulting textures are already a subset of the existing ones.  I think there are ways to sort of do this, and I'm particularly interested in any information people have about that.  For example, I know that in the elliptical filtering settings, you can specify the maximum number of texels covered by the minor radius in the highest resolution pyramid.  My standard has aways been 4, but for example, I was able to decrease the render above that took 3m12s down to 1m37s by taking this value down to 2.  That's an improvement, but nowhere near what would be needed to get back to more reasonable render times.  I've already been over this a good while back, but it's pretty annoying that MR reads the texture filter bias (the multi-resolution texture blurring parameter on the clip) from the .map file (basically because they chose to implement on-disk memory mapping for the entire image structure, instead of just the data portion of it, as they should have).

Anyway, I'm not holding my breath for any major revelations about how to optimize a scene with lots of gigantic textures (unless someone's got some?), but I just thought this was a good opportunity to push the envelope a bit, do a few tests and think about possible improvements for the future.  As storage gets more and more affordable, 8K textures and "taller" pyramidal maps are going to become more and more common.  Not so much because you really need the higher resolution, but because you "could" need it on a close-up render of an asset, and it's often easier to just paint one high resolution texture and have it be dealt with dynamically.  I think that at some point, MR needs a re-write of the direct-from-disk texturing method.  A multi-channel format would be a good start, to optimize situation #5 above.  A new format should ideally also be able to completely emulate the behavior of lower resolution textures with as little performance loss as possible.  And on the implementation side, it should be optimized as much as possible for read-ahead.

But honestly, I'm still kind of impressed that it's even stable (32-bit Windows).

Now, I'll just shut up and down-rez all my textures to 1/4th resolution.

- Andy