Crash using mesh light with lux 0.5

[Genscher]

Hey, using luxrender 0.5 official binaries (and selfcompiled) i get a crash with the following lux file:

http://dldw.de/tmp/index.php?file=default.tar.gz


Exporter: luxblend
Ubuntu 8.04, 64bit

(but shouldn't be interesting since lux shouldn't crash)

[Dade]

You are using as light source a sphere with 1984 triangles. You are also applying a Loopsudiv step so you end with 7936 light sources (=triangles)

It is a bit extreme as setup

If you at least disable Loopsubdiv on sphere light source, it will work fine. I'm going to check if the problem is in using a Loopsubdiv object as light source

[Dade]

it will work fine. I'm going to check if the problem is in using a Loopsubdiv object as light source

Ok, found the problem: it is a bug in Luxblend.

Luxblend correctly forbid the creation of a Loopsubdiv as light source however there is a bug. If you enable Loopsubdiv when material is matte and than switch the material type to "light", the light source will still be exported as a loopsubdiv shape.
To fix this problem in your scene just switch the light material back to matte, disable subdivision and than switch back the material to light.

[Radiance]

nevertheless it should'nt crash

i've created a mantis task for this: http://www.luxrender.net/mantis/view.php?id=355

Radiance

[Lotuspec]

I investigated this problem and posted my comments and a solution on Mantis.

Summary:
the trianglemesh (created from the loopsubdiv) was deleted during refinement of the shape. I think a similar problem also occurs in the GeometricPrimitive::FullyRefine (but not deleting at all instead of too early).

An alternative to the solution I proposed would be to detect the case (loopsubdiv+mesh) and show an error. The question is: do we want loopsubdiv + arealight or not?

[Radiance]

Hey,

Well, how i see it is that an area light using a shape, so any shape should be supported...

I'll have a look at the stuff you posted in the mantis task after work...

Radiance

[Lotuspec]

There may be a better solution then the one I first proposed (see Mantis).

MOD: there seems to be some memory leaks in cleaning up a scene (loopsubdiv's are not deleted, and therefore also are their refined meshes with the second solution)

MOD2: the memory leak problem (is this a known limitation or something?) seems to be related to the (Geometric)Primitives not being deleted (they are stored in the Context::Renderoptions I think, but RenderOptions has no proper destructor)