Hi Mark,
You are correct in your deduction that Radiance loads chunks (octrees in this case) as they are first required during rendering, unless you are using the -PP option, which causes the whole scene and all references to be preloaded to maximize memory sharing.
Radiance doesn't do any LRU ejection of memory once it's been loaded. However, virtual memory will swap out pages that are not accessed and this should in general be just as good. You only need to make sure you have enough free disk space to accommodate your VM system.
I hope this helps.
-Greg
ยทยทยท
From: Mark Stock <[email protected]>
Date: September 2, 2008 10:48:06 AM MDTI think I can answer my own question. As the rendering progressed, the memory growth slowed, and it finally ended at 6.4GB. A higher-resolution rendering is showing the same fast initial growth, and slow later growth, also ending near 6.4 GB
I suspect Radiance loads each of the 407 individual geometry chunks (octree instances?) when it is first needed. It took until near the end of the render to load in the last one.
Now I ask: will Radiance ever drop a chunk? If I want 24m instead of 12m cylinders, I'd need ~13GB. I can only presume that Radiance doesn't know this, and will continue to ask for more memory, with the OS obliging with excessive page swapping.
My options for larger scenes seem limited:
1) analyze the geometry and reduce surface overlap, or
2) buy a server with 16 GB RAM.Mark
On Mon, 1 Sep 2008, Mark Stock wrote:
Radiance whizzes,
I've upgraded to 8 GB of RAM, so, naturally, I found a scene that needs all that space. The rpict is eats up 4.6 GB initially, but even with "-aa 0" (turns off ambient caching, right?) I am still seeing my VIRT and RES memory sizes growing. They are at 5.3 GB after only 10 minutes of rendering. I am worried that I will not be able to render high-resolution images of this scene now. How can I prevent this?
FYI: the scene is composed of a sky and 407 "instance"s of separately-compiled octrees, each with 20k-100k primitives.
Mark