OTOY Forums

Hello everyone. I have recently worked on a quite heavy project with lots of geometry, different textures and I am just confused about how octane calculates memory for materials.

I have found that all the high end texture maps from poliigon, mega scans work great and don't cause problems. But when it comes to custom made textures from photoshop or substance painter, used out of core memory usualy skyrockets.
And it doesn't seem to matter if textures are 8k or 2k, high quality tiff maps, or optimised jpegs. Some texture maps, like simple advertising ads put on a plane, or simple fabric maps uses up gigabytes of memory.

So my question is, how does it all work and what are the best ways to optimise scenes in terms of materials and textures? I found it best to just keep deleting random textures from the scene to see which ones take the most memory in the render and then just deleting most of their maps, leaving it with diffuse map and float textures in other channels.

rokasv44 wrote:Hello everyone. I have recently worked on a quite heavy project with lots of geometry, different textures and I am just confused about how octane calculates memory for materials.

I have found that all the high end texture maps from poliigon, mega scans work great and don't cause problems. But when it comes to custom made textures from photoshop or substance painter, used out of core memory usualy skyrockets.
And it doesn't seem to matter if textures are 8k or 2k, high quality tiff maps, or optimised jpegs. Some texture maps, like simple advertising ads put on a plane, or simple fabric maps uses up gigabytes of memory.

So my question is, how does it all work and what are the best ways to optimise scenes in terms of materials and textures? I found it best to just keep deleting random textures from the scene to see which ones take the most memory in the render and then just deleting most of their maps, leaving it with diffuse map and float textures in other channels.

A few thoughts...

As I understand it, the file format as saved on disk shouldn't make any difference as to how much VRAM is used, although in the old days it could make a significant difference as to how quickly an image could be read into memory. (If the bottleneck was disk performance, it could be faster to read a compressed image and spend some extra CPU cycles decompressing it than to read the larger, uncompressed file, even without any extra CPU time. With the ridiculously fast read times we have these days, and the amount of data stored in gobs of RAM, it's not really an issue anymore.)

Once it is read from disk and into RAM or VRAM, though, a pixel is a pixel, although the bit depth will certainly make a difference. If you can get away with 8 bits, don't waste memory on 16 bits. If 16 is enough, don't use 24, etc. I don't know if it's generally still an issue, but I'm old-school enough that I always make sure my textures are square and fall within powers of 2, dimensionally, such as 512, 1024, 2048, 4096, etc. to get the most texture resolution bang for the memory buck. It used to be the case that a 1024x1025 pixel image would use the same memory footprint as a 2048x2048 image, and as far as I know, it still does. (I should do a test.) Was that single extra row of pixels really worth quadrupling the memory usage?

edit: So I did the test. An old dog can learn new tricks: a 4096x4096 RGB texture takes nearly the same VRAM as 4096x4100. And while an 8k square texture does in fact take four times as much memory as a 4k square texture, there's no real disadvantage, memory wise, to using a 5.7k texture, which will use about twice as much memory as a 4k. Similarly, a 4kx8k uses 2x the memory as 4kx4k. This may seem painfully obvious to some of you, but it was not always so. I guess I'll just go back to working in Swivel 3D on my 1987 Mac II.

Perhaps Ahmet can comment on the internal memory efficiencies of the Octane engine? I imagine a lot of it is pretty low level stuff hard coded into the NVIDIA and CUDA drivers.

- Frank