The grayscale into a RGBA channel trick is one of the bests, but often forgotten...
|> - It looks like that MR load in memory only the texel
|> visible of the texture. Since XSI keep the texture in
|> memory when you do a render region. Your second render is cached.
Forgot that: If you don't use .map files, then select all clips in your XSI explorer and set them to "load from disc".
Then XSI will not keep them in memory while rendering an image. The memory flushing I mentioned for the textures not used will not
work.
(Of course you cannot use the texture effect filters, but who uses them, for final renderings I apply the effect in Photoshop)
If you have a lot of textures controlling the shading, you can also use jpegs (80% quality), it will speed up your network if you
have a lot of render farm machines.
And you don't see any artifact in jpegs as long as you don't do any fancy effects like increasing the contrast a lot.
And as you mix multiple textures in the render tree + the light-shading in the rendering, I don't think that there will be any
artifacts left in the final render, which you can see if you increase the contrast a lot.
Holger Schönberger
technical director
The day has 24 hours, if that does not suffice, I will take the night
|> I may add these about texture resolution that may help
|> you. The problem you describe are common and are generate
|> by this leitmotiv : I will got more details in my texture
|> if I am using higher resolution. Well that the common
|> mistake and it 's not related to Mental Ray it's generic
|> to any render system. You will need to resize down your
|> texture to get all the details.
|> Ok that sound weird, paradoxal ( it s a scandal monsieur
|> !!!! , ...... please choose the word you prefer ) so Why
|> ? if you render let's in 2K a 8K texture ( with a lot of
|> fine details ).
|> For one pixel rendered you will get several texels to be
|> render. So renderer ( Mr, PRman, Vray .... ) will average
|> ( it's called filter ) the texture to get theses texels to
|> fit in the rendered pixel. The result is that you will
|> loose all the details of your texture. So the first
|> reflex is to increase filtering sampling and AA value but
|> it's very inefficient and your are not guaranteed to
|> retrieve all the details.
|> So having 8K textures are pretty useless until your render in 4K.
|> But that doesn't mean you should paint your texture in
|> lower resolution. Ask your texture artist to paint it in 8K.
|> As Holger mentioned reduce the source and keep it with a
|> good filter ( sinc or lanczos ) the details will be kept
|> and will be anti aliased.
|>
|> I see this question coming : Yes ok but if I convert my
|> texture in a pyramidal .map file I should already get my
|> reduced texture so Why should I need to scale down it ?
|> Again this is a common mistake. 8K texture reduced in 2k
|> with a sinc filter and then used as a 2K texture will
|> reveal much more details than a 2K mipmaped version of a
|> 8K texture.
|> Why ? Again because of the filtering process. To choose
|> the right mipmap resolution you need to look up the higher
|> resolution and the lower resolution of you current mipmap
|> version and filter them with the current one. If you don't
|> do that you will end up with some transition problem if
|> your object will move away of your camera.
|>
|> So reducing the texture will also reduce your space disk
|> thus your network traffic thus decrease your render time.
|> Hope it was clear, it's pretty unintuitive. But again I
|> experimented theses stuff on The Golden Compass with PRman
|> and I could stabilise render and memory usage and verify
|> that I was not smoking cracks.
|>
|>
|> More information about .map that I observed.
|>
|> - It looks like that MR load in memory only the texel
|> visible of the texture. Since XSI keep the texture in
|> memory when you do a render region. Your second render is cached.
|> - If you add the new texture layer then you will have to
|> rebuild your cache again. The first render may be slower
|> but the next one should be faster.
|> - Memory limits should be set everytime if you aim stability.
|> - .map are network killer so have a local copy on your render node.
|> - .map on a 32 bit system works on 64 bits system not the
|> opposite. I suspect the way the memory is managed in 64
|> bits is incompatible with 32 bits system.
|> - tiled option increase speed but is incompatible with
|> older version of MR.
|>
|> Others tips with texture is to use the 4 channels you have
|> ( RGBA ) to store different type of data.
|> eg.
|> Spec map 1 in R
|> Spec map 2 in G
|> Reflection map in B
|> Occlusion map in A
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
