 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2020-02-29 à 15:07, GioSeregni a écrit :
> 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.
>
>
>
Since the alpha of version 3.7, the image file is not generated until
the render have finished. The data needed are saved in the *.povstat
file allowing the continuation of an interrupted render.
Radiosity is not that new as it was introduced with version 3.0.
In the povstate file, the value of each pixel is represented as 3 single
precision float number similar to that of an EXR file. This is, to my
knowledge, only a superficial similarity. Also, those data are often not
in a sequential order and the file may be sparse.
The new mechanism allow rendering with all the available cores of modern
computers and seamless continuation of interrupted radiosity scenes.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 01/03/2020 à 19:56, Alain Martel a écrit :
> Le 2020-02-29 à 15:07, GioSeregni a écrit :
>> 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.
>>
>>
>>
>
> Since the alpha of version 3.7, the image file is not generated until
> the render have finished. The data needed are saved in the *.povstat
> file allowing the continuation of an interrupted render.
> Radiosity is not that new as it was introduced with version 3.0.
> In the povstate file, the value of each pixel is represented as 3 single
> precision float number similar to that of an EXR file. This is, to my
> knowledge, only a superficial similarity. Also, those data are often not
> in a sequential order and the file may be sparse.
>
Nearly correct, but IIRC you are confusing two files.
The continuation file (C option) is more complex and contains the
sequence of block as they are rendered (with more than just 3 floats per
pixel). It is not sparse, but can become huge.
The image buffer (IM option, default is: disabled unless final image
would use more than 128 MB with 20 bytes per pixel) is actually that
sparse file, with N floats per pixel (and special data at the very end
of the file, see documentation).
The first file is used when you ask for continuation (and is able to
rebuild the second file). The second file is only used (when memory
setting requires it) between the start of the render and the write of
the rendered image in the requested file format.
Both files I/O can significantly slow down your render speed (irrelevant
when the render speed is so slow that it is better to have a continue
option instead of spending again a few hours)
> The new mechanism allow rendering with all the available cores of modern
> computers and seamless continuation of interrupted radiosity scenes.
>
> Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Many Thanks to all for the help.
I understand, and I also hope I no longer have the crash problem.
To check the backward compatibility of my Pov parser from CAD, that I update
continuously, I had taken some old dwgs to render.
I was surprised because I had big problems with drawings quietly rendered with
other previous versions of PovRay.
In another thread, casually, I also found the reason. The boolean "difference".
Many years ago I built my leaf (which uses every tree of mine), using the
difference. Now, if it is repeated, it is terrible.
I rewrote the leaf code in another polygonal way, I gave up the edges softened
by two curves, but the difference of time and memory is amazing.
A tree with the new version (detailed but without Boolean operator) takes 1/4 of
the time.
And memory does not continually increase. With the old version of the leaf,
exactly (sigh) at the end of the rendering, crashes often occurred
OLD VERSION
difference{
polygon {5 <.04,0,0><0,0,.06><-.04,0,0><0,0,-.06><.04,0,0>}
sphere {<0.04,0,0>, .065 inverse}
sphere {<-0.04,0,0>, .065 inverse}
translate <0,Rad,0> }
rotate <rand(R1)*360,rand(R2)*360,rand(R3)*360>
scale <rand (R1),rand(R2),rand(R3)>}
NEW VERSION (4 time faster)
object{polygon{13<-.013,0,-.037><-.0217,0,-.02><-.025,0,0><-.0217,0,.02><-.013,0,.037><0,0,.051>
<.013,0,.037><.0217,0,.02><.025,0,0><.0217,0,-.02><.013,0,-.037><0,0,-.051><-.013,0,-.037>
translate <0,Rad,0> }
rotate <rand(R1)*360,rand(R2)*360,rand(R3)*360>
scale <rand (R1),rand(R2),rand(R3)>}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
sorry if I insist on off topic but I think it's something to know.
I am reviewing the code of my libraries. I have had confirmation that removing
the "difference" from the loops is gaining 3/4 of the time.
Another example, the basic atom of my Palm Washingtonia (Washingtonia) revised
and corrected.
#declare Subpalm0_Old = object {difference {difference {
sphere{<0,0,0>,1 scale<.5,.2,1>}
plane{<1.2,1,0>,0} plane{<1.2,-1,0>,0 inverse}}
sphere{<0,0,0>,1 scale<.5,.2,1>}}
translate<0,0,1> scale<.09,.3,.3> rotate<0,-100,0>
pigment{colour OLIVE} finish{ambient (0.45 * AmbientFact) diffuse .7}
normal{bumps .25 scale .04}
}
#declare Subpalm0 = object{sphere{<0,0,0>,1
scale<.5,.2,1>clipped_by{plane{<1.2,-1,0>,0}} clipped_by{plane{<1.2,1,0>,0
inverse}}}
translate<0,0,1> scale<.09,.3,.3> rotate<0,-100,0>pigment{colour OLIVE}
finish{ambient (0.45 * AmbientFact) diffuse .7}
normal{bumps .25 scale .04}
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"GioSeregni" <gms### [at] hotmail com> wrote:
> sorry if I insist on off topic but I think it's something to know.
> I am reviewing the code of my libraries. I have had confirmation that removing
> the "difference" from the loops is gaining 3/4 of the time.
Yeah, difference{} can be a killer if it's not implemented in a way that
optimizes its usage.
You might find this enlightening as well:
http://www.econym.demon.co.uk/holetut/index.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "GioSeregni" <gms### [at] hotmailcom> wrote:
> > sorry if I insist on off topic but I think it's something to know.
> > I am reviewing the code of my libraries. I have had confirmation that removing
> > the "difference" from the loops is gaining 3/4 of the time.
>
> Yeah, difference{} can be a killer if it's not implemented in a way that
> optimizes its usage.
>
> You might find this enlightening as well:
> http://www.econym.demon.co.uk/holetut/index.htm
Yes, but in my last example the geometric shape has identical result, even if
described in two different ways.
I believed that theare are infinite way to render light and surface, because
they depend on the programming of each user.
But I thought that the forms, which instead have a unique and indisputable
spatial result, were optimized and stored in a internal database, by the parser,
in its best way.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 04/03/2020 à 03:57, GioSeregni a écrit :
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> "GioSeregni" <gms### [at] hotmailcom> wrote:
>>> sorry if I insist on off topic but I think it's something to know.
>>> I am reviewing the code of my libraries. I have had confirmation that removing
>>> the "difference" from the loops is gaining 3/4 of the time.
>>
>> Yeah, difference{} can be a killer if it's not implemented in a way that
>> optimizes its usage.
>>
>> You might find this enlightening as well:
>> http://www.econym.demon.co.uk/holetut/index.htm
>
> Yes, but in my last example the geometric shape has identical result, even if
> described in two different ways.
> I believed that theare are infinite way to render light and surface, because
> they depend on the programming of each user.
> But I thought that the forms, which instead have a unique and indisputable
> spatial result, were optimized and stored in a internal database, by the parser,
> in its best way.
>
The problem of difference optimisation is the bounding box.
Plane have infinite bounding box, so they are killing the difference
optimisation. Something that does not occurs when clipping.
It might be worth testing with a box instead of plane (as small as
possible box to make the same as the plane did, even if it is a bit more
complex to describe (due to having to rotate the box to match the normal
vector of the plane)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
