Indigo Renderer Forum

I have trouble with indigo 1.1.15 under 64 bit Linux. It hogs memory out of this world. I have a simple scene of a toy formula 1 car and when rendering just 800*600 with 1 mesh light. and it uses about 3 gigabyte with ram. And thats with subsurf set on minimum. Whats the issuue here? When i try to increase the subsurf to get a smooth surface it hogs above 5 gigabyte of ram.. and thats bad since i only have 4 gigabyte in this computer.

I can confirm this. I've recently switched to 1.1.15 from 1.0.9 stable and observed approximately two-fold increase in memory consumption. Not so drammatic as tobak30 says, but pushing the limits of my Linux amd64 boxes. With 1.0.9 it was possible to comfortably make 2500x1750 high-resolution architectural renders with 4x supersampling and post-processing apperture diffraction. On 1.1.15 however the system crashes on the same scenes because out of memory just trying to preallocate memory buffer.

You mean: using one single layer ? 1.0.9 doesn't support layers, that's why I'm asking.

Yes, I am aware of this. Yep, everything said is related to the single-layer scene: with just hdr/sun light memory consumption is much higher.

As I see now this problem has nothing to do with image buffer allocation and light layering: an image is allocated as much memory as expected with respect to image dimensions, light layers and supersampling settings.

However, newer Indigo versions consume much more memory on meshes xml parsing and kd-tree allocation making it impossible to use on some complex high-poligonal scenes. I'll do some tests in a few days with Indigo 1.0.9, 1.1.15, and latest 1.1.16, and report my results back here.

Looking forward to your tests.. cause this things bugs me imensly

Does switching between bih and bvh trees have an impact on this issue ? Just wondering.

???? What bvh tree or bih tree???

bvh-tree = replacement for bih-tree and as bih-tree before an alternative for kd-tree.

kd-tree builds slower than bvh-tree and might cause problems with huge scenes but usually is more effective during rendering, saving a lot of time. Though, Indigo 1.1.15 had a bug in the kd-tree, which was bypassed by using bih-threshold of 0.

bih-tree, compared to bvh-tree, is both slower at building and less efficient during rendering, making bvh-tree very useful for huge scenes

bvh is said to be 10-20% slower than kd.

yes, I fear that was not quite accurate Kram.

The newest implementation (BVH) will allow Indigo to handle heavier meshes than BIH, and builds faster. Though, it's as fused said.

BIH is both "weaker" and slower at building but provides, like inderectly stated, a faster rendering pace than BVH.

I think it's all about how Indigo builds its representation of the geometries or their distribution in space or akin

Possiblly your exporter is providing a threshold poly count (bih_tri_threshold); meshes with less triangles will use BIH, others BVH.

CTZn wrote:BIH is both "weaker" and slower at building but provides, like inderectly stated, a faster rendering pace than BVH.

wait, isn't bvh supposed to be rendering faster than bih?

I think, BVH was both faster at building AND more efficient... gotta check that now...

Here is a quote...

PureSpider wrote:

<@PureSpider> will only the build speed be faster or render speed in general?
<+CTZn> both if I understood ok
<@OnoSendai> of what vs what?
<@PureSpider> BVH vs "normal" kd
<@OnoSendai> build is faster, render is slower
<@PureSpider> eeeeeh :@
<+CTZn> ah, necessarily slower ?
<@OnoSendai> yes
<+CTZn> ok, good to know
<@OnoSendai> ok, in some cases it may be faster
...
<@OnoSendai> render speed: kdtree > BVH > BIH
<@OnoSendai> mem usage: kdtree > BVH = BIH

Hope that got things clear

I'm confused now, don't know what to think... IIRC WytRaven had half the spp with... arf wich was the buggy tree then ?

Okay my bad, I was confused, BVH is indeed faster at rendering... WytRaven confirmed that I think.