Texture caching... amazing improvement in memory with Cycles, could be great in LuxCore!

[juangea]

HI there.

Steffen Dunner has been doing some tests with the Texture Caching branch from Stefan Werner, and he did a test with a ton of 8k textures, I have to say that the results are incredible:

Here is the branch in case it's useful:

https://git.blender.org/gitweb/gitweb.c ... ture_cache

This would be amazing, just with this the amount of memory taken by textures in general could be reduced A LOT and that would make 8Gb GPU's much more viable to render serious projects

[Odilkhan Yakubov]

HI there.

Steffen Dunner has been doing some tests with the Texture Caching branch from Stefan Werner, and he did a test with a ton of 8k textures, I have to say that the results are incredible:

chrome_VJmgCbdm9I.png

Here is the branch in case it's useful:

https://git.blender.org/gitweb/gitweb.c ... ture_cache

This would be amazing, just with this the amount of memory taken by textures in general could be reduced A LOT and that would make 8Gb GPU's much more viable to render serious projects

Outstanding news if it will be a new egg!

[Dade]

This would be amazing, just with this the amount of memory taken by textures in general could be reduced A LOT and that would make 8Gb GPU's much more viable to render serious projects

You may misunderstand the feature: it is only for CPU rendering. It is what Arnold does (actually .tx is an Arnold format): the images use mip-maps and are broken in tiles, and you load the mi-maps/tiles on-demand, when they are required for the rendering. It allows to use very large image data sets and a very fast starting of the rendering (people uses 100+GBs of textures with Arnold).

I can add the support for it but it is cpu-only and, given most people use GPUs for rendering, doesn't sounds very useful.

[Sharlybg]

This would be amazing, just with this the amount of memory taken by textures in general could be reduced A LOT and that would make 8Gb GPU's much more viable to render serious projects

You may misunderstand the feature: it is only for CPU rendering. It is what Arnold does (actually .tx is an Arnold format): the images use mip-maps and are broken in tiles, and you load the mi-maps/tiles on-demand, when they are required for the rendering. It allows to use very large image data sets and a very fast starting of the rendering (people uses 100+GBs of textures with Arnold).

I can add the support for it but it is cpu-only and, given most people use GPUs for rendering, doesn't sounds very useful.

I can't count the number off time when my CPU couldn't render a scene just because i ran out of Memory even with 32/64 GB.
I mean it would only make use attractive and production friendly if available.

[juangea]

@Dade

True, however Stefan is working in the GPU version of this, in Cycles it will support both, GPU and CPU

[Dade]

True, however Stefan is working in the GPU version of this, in Cycles it will support both, GPU and CPU

On GPUs, it will suffer of a HUGE (really HUGE) performance hit. I assume it will be no different from using out-of-core rendering with LuxCore.

[bestman8]

This would be amazing, just with this the amount of memory taken by textures in general could be reduced A LOT and that would make 8Gb GPU's much more viable to render serious projects

You may misunderstand the feature: it is only for CPU rendering. It is what Arnold does (actually .tx is an Arnold format): the images use mip-maps and are broken in tiles, and you load the mi-maps/tiles on-demand, when they are required for the rendering. It allows to use very large image data sets and a very fast starting of the rendering (people uses 100+GBs of textures with Arnold).

I can add the support for it but it is cpu-only and, given most people use GPUs for rendering, doesn't sounds very useful.

i think it can be very usefull for cpu rendering but i think it shouldn't be a main priority

[AndreasResch]

Every option to get around (GPU) memory problems in Luxcore already suffers huge performance hits, loss in quality and often doesn't work at all (like out of core). You might maybe want to keep an eye on this development and if it's stable, you can ditch "Tiled Path" and "Out of core" and end up having a viable alternative.

[juangea]

Well, will see what's the outcome

Of course if it's going to be a big performance hit it makes no sense and it should not be a priority, I agree.

However, what do you think about using MipMapping, something that is native for the GPU's and maybe can be easily handled? (I may be wrong, that's why I ask )

[kintuX]

Here's CPU for the win & it makes more sense considering hybrid approach.
Anyways, why I still prefer CPU engines is because I find those more stable, predictive, maneuverable, easier to handle, faster & effortless to deliver bigger projects... = more dough, better ROI
Also, after baking gets to BlendLuxCore users will have a choice and be able to "smack bitch up" in an instant.
So Yes! for texture caching.

And next, better, faster BiDir, MLT, code, new materials..."