Many thanks for the reply. These days I have discovered the reason of the
crashes. It is the memory exhausted just towards the end of the work (strange,
but my system, at that moment, does not swaps on the disk, it must be win 10's
fault).
I want to check something about my rendering modes, because radiosity doesn't
seem to change the previous calculations. I will save a copy of the unfinished
preview image. Then I will compare it to the regularly generated TGA. I'm
curious to see the differences between the RGB, I never exceed the width
1280x1024...).
Thanks again!

William F Pokorny wrote:
> On 2/29/20 3:07 PM, GioSeregni wrote:
> >........Now, for memory lack reasons, I have encountered an unpleasant problem. I
am
> > unable to find the incomplete BMP/TGA file when when pov stops, for various
> > reasons.
> > I understand that the new Radiosity (excellent) does not allow the quite
> > prosecution of the job, but the question is different. The partial bmp was
> > useful for various reasons (use of the part, crash analysis ...).
> > Now I ask, is this option still possible? And if it is not possible, what is the
> > structure of the "state" file?
> > I would have no problem capturing the data, but knowing the structure it would
> > take less time to develop the tool.
> >...........
> >
> Hello,
>
> 'Progressive image output is not possible,' is the answer which has been
> given previously by core developers(1). I'm not aware of any state file
> documentation other than the code itself.
>
> If your aim is debugging bugs or development-throw triggered crashes,
> what I've done in in v3.7 onward is use a wrapper script built around
> running POV-Ray with the +sc,+ec,+sr,+er flags.
>
> I called the script scan4ThrowPixel(2). It starts by being sure I see
> the crash with the whole image before rendering ever smaller blocks. The
> first block which crashes being divided into smaller ones until finally
> arriving at a single pixel / camera ray(3).
>
> Bill P.
>
> (1) - Meaning I expect, probably possible with enough code work - but
> not going to be done.
>
> (2) - It's got a scene file globbing feature which lets me run many test
> scenes looking for crashes / or particular code use inside POV-Ray via
> throws I've added to some bit of code.
>
> (3) - If the crash is related to a non-camera ray driven process, the
> sub-division of the image is no help, but that was true for the 'where
> did we stop rendering in the image' method too. And there is the issue
> that, unless running single threaded, knowing which thread (image block)
> is the problem is much less clear these days - even if we had partial
> image output on a crash.

Post a reply to this message