On 2/29/20 3:07 PM, GioSeregni wrote:
> Hi to all, thank for the add  to this group and excuse me for mybad english.
> I am new in this forum, but I am a old user of POV-Ray (I remember the old dkb
> ....). 30 years ago (!) I starting my first parser, in lisp, from the AutoCAD
> ambient (from the data base, at run time, no dxf needed...)
> 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.
> Many thanks in advance and regards!
> G.S.
> 
> 
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