On 22/11/2010 4:47 AM, Chris Cason wrote:
> On 21/11/2010 03:02, Stephen wrote:
>> I've posted it in p.b-t.b and sent a short dump.
>
> I've had a look at this. Part of the issue is that it hits the internal
> link to frame stage with one top-level union that contains 2,116,139
> sub-objects, spread amongst many other sub-unions (961,880 children at the
> second level, for example).

You try modelling the Sydney "coat hanger" with less. :-P
The Forth Rail Bridge is smaller.


> During shut-down of the Windows version, if the de-allocation of memory
> blocks takes more than five seconds, the worker thread is forcibly shut
> down. However, this was not being handled properly within that code and
> consequently Windows would issue an 'unusual termination' message, or the
> program would just crash. That should now be fixed.
>

That's good :-)

> As for why it's sitting using CPU for a long time after the render is
> finished, or crashing on another render attempt: I can't say exactly what's
> going on there as I didn't see that behavior when testing.
>

Did I say that? I meant to say that PovRay held onto its memory.
Try running a two frame animation. On the second frame I got an "unknown 
internal error".

> Also, in response to your original query as to why the memory is not freed
> after the render: the internal architecture of POV-Ray 3.7 separates the
> scene from the render; i.e. the parsing of the scene is totally separate
> from the render, and technically the same parsed scene data may be used in
> multiple renders (either simultaneously or sequentially).

This has been a feature request for years. :-D

> This isn't
> implemented yet (i.e. you can't actually do it) but that's more a UI
> limitation than anything else. Put another way, the parsed scene data (and
> hence all the memory it uses) stays around after a render until it's
> explicitly destroyed, which doesn't happen until a new render starts or the
> program exits.
>



-- 
Regards
     Stephen

Post a reply to this message