LuxRender v0.6 Release Candidate 1 - Windows/Linux/MacOSX

[manitwo]

thanks radiance

[Lord Crc]

I've re-launched a project that was only done in Blender before but would be nice to see rendered in Lux too. Small issue though: besides the earlier mentioned "alpha background" there are artifacts that have no filling, they are exact squares so it are pixels that are not filled with rendered stuff

I seem to get them too on a scene here. Think it's metropolis related.

[akhenathon]

Luxrender crashed again with my project, when building KDTree.

Luxrender memory: 1.2 GB
Primitives: 1,595,547

Windows XP Pro SP2 | 3 GB RAM

[loramel]

I am now in the stages of starting the highres render for my crown project and think I have found quite a huge memory leak.

Luxrender always kept crashing always after ~5 min, so I investigated and saw that the linux OOM killer terminated lux.

I watched the memory consumption and am now able to reproduce the problem. The leak seems to have to do with the film writing turned on, as with each flm write you have a higher step in the memory consumption, allthough once the first time a film is written to disk, memory consumption starts to increase even after each tonemapping step.

See attached zipped blend file for a demonstration of this problem. I used 6 lightgroups and a resolution of 1600x2000, tonemapped tga and exr is written.
Lux starts at ~330 MB and stays there until the first film write. After that its at 530 and continously climbing and will eventually be killed by the linux OOM killer.

( BTW I am using the CVS from 19.03.2009, 10.00 am GMT+1, compiled with intel icc 10.1.018 64bit, linux kubuntu 8.04.2)

[Radiance]

Hi,

These are limitations of a 32bit process on a 32 bit windows system.
KDtree's can get large for large meshes quickly.

the approximate process limits:

window 32bit: 1.2-1.3GB
linux 32bit: 3.0GB

windows and linux 64bit: 8TB+

As such, you can either install a 64bit OS, which i'd recommend, but in this case you could lighten your scene a bit, make sure you're not using lots of heavy subdivision.

Radiance

[loramel]

Additional info the my memory leak topic.

The supplied file does not show the behaviour, but my crown scene does.
I will try to strip down the scene, so that the problem is still visible.

I'll keep you posted ...

[Radiance]

I am now in the stages of starting the highres render for my crown project and think I have found quite a huge memory leak.

Luxrender always kept crashing always after ~5 min, so I investigated and saw that the linux OOM killer terminated lux.

I watched the memory consumption and am now able to reproduce the problem. The leak seems to have to do with the film writing turned on, as with each flm write you have a higher step in the memory consumption, allthough once the first time a film is written to disk, memory consumption starts to increase even after each tonemapping step.

See attached zipped blend file for a demonstration of this problem. I used 6 lightgroups and a resolution of 1600x2000, tonemapped tga and exr is written.
Lux starts at ~330 MB and stays there until the first film write. After that its at 530 and continously climbing and will eventually be killed by the linux OOM killer.

( BTW I am using the CVS from 19.03.2009, 10.00 am GMT+1, compiled with intel icc 10.1.018 64bit, linux kubuntu 8.04.2)

Hi,

One issue is that when using 6 lightgroups, you'll have 6x 2 buffers (when using bidir), as such that cost a LOT of memory at high resolutions.
You should use lightgroups to tweak lighting in your scene, then replicate the configuration to luxblend,
which will allow you to render the final in spectral space instead of lightgroups which work in RGB space, giving more realism/better quality.
since then you only have 1 copy of all the buffers active, you can runat high resolutions.

the writing of files of very large multibuffer films also consumes more memory during writes as these need to be mixed and buffered for writing, in temporary buffers.

Radiance

PS: i thought you were working with 64bit lux? is this still an issue with it ?

[loramel]

OK, here we go.

See the stripped crown file attached which should produce this problem.

It looks like the thread, which writes the film does actually take longer to write the film than the writing interval is. On my machine the interval is set to 120 sec, but the actual film transmission lasts for ~4 min. So immediately after the film is written another one starts to write again, and here is were the memory gets lost.

When trying out this file, keep in mind that the basic memory consumption when rendering is tarting is 1.2Gb increasing rapidly, so a 64bit machine is probably a must here.

[loramel]

PS: i thought you were working with 64bit lux? is this still an issue with it ?

See my previous post with the attached example file. Yes its an issue with 64bit too, as there seems to be a real leak there.

I understand that my setup costs a lot of memory, but that should be initial costs and not accumulating ones. So my memory footprint at the start of rendering is 4Gb, but with each film write another 800Mb gets added, so even with 8Gb of RAM I will eventually run out of memory .

[Radiance]

OK, here we go.

See the stripped crown file attached which should produce this problem.

It looks like the thread, which writes the film does actually take longer to write the film than the writing interval is. On my machine the interval is set to 120 sec, but the actual film transmission lasts for ~4 min. So immediately after the film is written another one starts to write again, and here is were the memory gets lost.

When trying out this file, keep in mind that the basic memory consumption when rendering is tarting is 1.2Gb increasing rapidly, so a 64bit machine is probably a must here.

Hi,
Yeah indeed, although i thought you were working with 64bit lux already
However, as i mentioned before, you should render your final at high res without lightgroups,
or in case of using large renders with lots of lightgroups, set your writeinterval to 15-30 minutes or so.

with tga/exr output this is less of an issue but with FLM it is

Radiance