OTOY Forums

GeoPappas wrote: So I thought that it might be worth looking into.

I agree that the development should find new ways to better use the limited resources (and memory on GPU is quite a bottleneck). It's just that image decompression is a very slow process (miliseconds on CPU). That's for a single image, once. Even with 100x decompression speedup on GPU, doing it millions of times per render pass (since you can't cache) would kill all the performance of Octane.

They might find ways to optimize memory usage in this segment, but a general workflow with compressed texture images is IMO not possible.

Their time is better spent in coding tools that will allow us to optimize and better reuse texture data.

A fair chunk of the memory used on the GPU is the final output size.What about using camera offset and stitching the resultant images together in Photoshop.Using camera offset with say 1000x1000 pixel output across 10-20 frames and stitching the lot together in photoshop means you should be able to get poster size images whilst keeping the memory usage under control.This would then also free up some of the memory for increased complexity of the textures and mesh's.

Another option just before export would be to optimise the mesh after smoothing.In Max there is Pro Optimise functions to do this.Not sure about the other 3D packages.Also as previously mentioned.Use Octanes procedural textures where possible and use image textures as little as possible.

The final bit is of course Instancing when it becomes available in Octane.So there is a fair few ways to reduce the memory footprint in the scene to fit within the GPUs memory.

Hi all,

compressed textures is not possible currently in octane.
although GPUs texture units can decode blocks of pixels from DXT texture compression (which is very low quality and used for games),
these only work if CUDA would expose the hardware for it (which it does'nt), and it would never work anyway as raytracers read texture pixels completely randomly (eg random access), instead of a predictable access like OpenGL/DirectX.

it's not possible to read random pixels from any other form of compression as you will need to decompress the whole image first to be able to look up the right pixel, which does not solve anything.

You are better to think about how you use textures, make sure you use floatimage where needed (specular, bump, alpha), and don't load huge textures for tiny objects in your scene,
aswell as trying to use procedurals for repetitive patterns, as these consume zero memory.

Trust me, if there were other options we would have implemented them already.

Radiance

What about a "resolution" option on image nodes? A slider from 1% to 100%? It could even show the used RAM for the texture right next to the slider, updating in real time as you increase/decrease it.

Often when you unwrap an object for UV mapping, all the surface of the image used as texture is not used. For my own, I try to fill these spaces with small textures used by other objects.

When I have to texture a ground where is set a building, I also use the parts under the building to draw textures used by the building itself, or other city props. This to avoid empty surfaces and to optimize the memory use.

colorlabs wrote:What about a "resolution" option on image nodes? A slider from 1% to 100%? It could even show the used RAM for the texture right next to the slider, updating in real time as you increase/decrease it.

Be aware, that this will then affect all usages of the same texture, which can be shared. Anyway, good idea. Noted.

Cheers,
Marcus

-i just wonder if the uv mapping options will be improved in the next release..
http://www.refractivesoftware.com/forum ... 4&start=80

dave62 wrote:-i just wonder if the uv mapping options will be improved in the next release..
http://www.refractivesoftware.com/forum ... 4&start=80

No unfortunately not. To do it right it needs a bit more work, which we couldn't squeeze in yet. -> You have to wait until a later release.

Cheers,
Marcus