Vray optimiation

[zanderadrian]

I just saw this on a vray facebook page. Thought i might share.

 

"Just a small tip for every one. Please keep the textures to the numbers of 2^n, reason being, the RAM allocates a higher space for textures with awkward ratio, for example, if I have a texture with the dimension of 512 x 512, RAM would allocate 512 bytes for this texture however if I have a texture of 500 x 600 the RAM would allocate a space which can fit 1024 x 1024 {square} texture, therefore a very small texture will take the size twice of what it should.

 

Thus guys, please remember to optimize your workflow, V Ray is not a slow rendering engine, it's us who make it work hard while calculating textures, materials and lighting!"

[salvador]

Wish that was always possible. Thanks for the tip Zander

[RyderSK]

It's bullshit advice, apart from UDK which has it from past almost no engine require such rule to optimise space required to minimize memory footage. It's ridicolous to do it in Vray to every single bitmap used. It saves zero space and zero time in 2012. Btw, I would never...never, listen to anything he has to say... for your own sake.

 

But there is available optimization when it comes to bitmaps in Vray 2.3. You can now load all types of bitmaps as VrayHDRi instead of regular Bitmap loader, and these should speed up especially render start up times. Other optimizations more for scene sake is to use Bitmap Proxy (can be accesed through Asset Manager).

Loading bitmaps in VrayHDRi produces especially good result when it comes to bump maps, which they come out crisper and sharper (but at same time, disable filtering). Credit for this advice goes to Vlado and Bertrand Benoit.

[Tommy L]

It's bullshit advice, apart from UDK which has it from past almost no engine require such rule to optimise space required to minimize memory footage. It's ridicolous to do it in Vray to every single bitmap used. It saves zero space and zero time in 2012. Btw, I would never...never, listen to anything he has to say... for your own sake.

 

But there is available optimization when it comes to bitmaps in Vray 2.3. You can now load all types of bitmaps as VrayHDRi instead of regular Bitmap loader, and these should speed up especially render start up times. Other optimizations more for scene sake is to use Bitmap Proxy (can be accesed through Asset Manager).

Loading bitmaps in VrayHDRi produces especially good result when it comes to bump maps, which they come out crisper and sharper (but at same time, disable filtering). Credit for this advice goes to Vlado and Bertrand Benoit.

 

Can you explain the logic behind using VrayHDRI for regular bitmaps? Also, is there a script for converting all bitmaps to have a VrayHDRI shell? Rather like the script that changes all bitmap blur to 0.001?

Thanks,

Tom.

[RyderSK]

I would lie if I gave you correct explanation, as I haven't studied too deeply into it :- ) Don't have all the time to sit through Chaos forum, though everytime I visit, there is some new cool info. Vray starts to be bit funny with all these tricks.

I am not aware of such script, but that would be quite cool.

 

I only apply it to bump, and I leave all my textures unfiltered, as with VrayHDRi, you can't preview the result on geometry.

[salvador]

It's bullshit advice, apart from UDK which has it from past almost no engine require such rule to optimise space required to minimize memory footage. It's ridicolous to do it in Vray to every single bitmap used. It saves zero space and zero time in 2012. Btw, I would never...never, listen to anything he has to say... for your own sake.

 

But there is available optimization when it comes to bitmaps in Vray 2.3. You can now load all types of bitmaps as VrayHDRi instead of regular Bitmap loader, and these should speed up especially render start up times. Other optimizations more for scene sake is to use Bitmap Proxy (can be accesed through Asset Manager).

Loading bitmaps in VrayHDRi produces especially good result when it comes to bump maps, which they come out crisper and sharper (but at same time, disable filtering). Credit for this advice goes to Vlado and Bertrand Benoit.

 

Ok, ok. I didn't know either of these, but the fact that Max stores bitmaps in memory at render time.

 

I'll take your word for it but I add up to Tom Livings question. I'd love to know more of what you are saying. EDIT: already answered. Withdrawn.

 

@Zander: where is your background for this statement? I hate to be taken for a ride.

[RyderSK]

The advice is from indian guy who simply assumed it would work this way since he probably came from some game-engine optimization advice from prehistoric times. Of course, the math works as described, but we are in 2012. everyone has 16GB of ram mostly, and the effect of keeping all textures squares and power of 2, would probably help you by.... 0,00001 perc. approximately. There are more reasonable ways to save memory.

 

 

Good idea is to keep texture size proportional to it's respective size in final render. Most of us don't produce close-up renders as commercial work. If you download default DesignConnected TableSet for example, the Napkin will have 2000+px texture size, and about 10 of these. This is ridicolous unless you plan to have the "cool DOF close-up beauty render" that no one will give a **** about. So it's good idea to either downsample (with sharpen filter) it to more affordable size but keeping seemingly same quality, or create proxy of it, and also use that proxy in render time (through 3ds Max AssetManager utility)

 

 

I used to have un-optimised scenes with more than 1-2GB of texture space. Loading these up from fast SSD disk took more then 10 minutes for Max when I opened the scene. It was very troublesome. Now I keep those ultra-size texture only where truly neccesary, as wood grains, floors, walls, important bump maps, but keep them low for decoration, that is only visible in 1-2perc. of screen space.

Edited November 20, 2012 by RyderSK

[salvador]

That makes sense.

I'm looking into loading all bmp's through VRayHDRI. Intriguing. . .

[Scott Schroeder]

CryEngine3 won't use non power of 2 images either. From the Dev docs: http://freesdk.crydev.net/display/SDKDOC3/Texture+Creation+Guidelines Unity won't use them either, though it will allow you to import them and then it will rescale/squash/stretch them to the nearest power of 2.

 

"Texture Sizes

 

Ideally texture sizes should be powers of two on the sides. These sizes are as follows: 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024 or 2048 pixels. The textures do not have to be square, i.e. width can be different from height.

 

It is possible to use other (non power of two) texture sizes with Unity. Non power of two texture sizes work best when used on GUI Textures, however if used on anything else they will be converted to an uncompressed RGBA 32 bit format. That means they will take up more video memory (compared to PVRT(iOS)/DXT(Desktop) compressed textures), will be slower to load and slower to render (if you are on iOS mode). In general you'll use non power of two sizes only for GUI purposes.

 

Non power of two texture assets can be scaled up at import time using the Non Power of 2 option in the advanced texture type in the import settings. Unity will scale texture contents as requested, and in the game they will behave just like any other texture, so they can still be compressed and very fast to load.

 

One potential problem with using non power of two textures this is that Unity will convert these textures internally to power of two, and this stretching process can introduce minor visual artifacts. "

http://docs.unity3d.com/Documentation/Manual/Textures.html

 

That being said, that rule doesn't really apply to what we do. As it has been said before, the .005 seconds it may save us isn't worth the hassle to rescale all of our existing assets.

Edited November 20, 2012 by VelvetElvis