![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Jan Walzer wrote:
>
> sounds like the thing, that I reported here:
>
> http://news.povray.org/povray.beta-test/25268/
Yes, it seems to be the same.
> I never got an answer to this ...
You did not provide a scene... No scene, no gain ?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> You did not provide a scene... No scene, no gain ?
This is independent of a scene, isn't it?
so take this:
//----------------
sphere {0,1,pigment{color rgb 1}finish{reflection 0.8 diffuse 0.1}}
plane {y,-1 pigment {checker color rgb 1 color rgb 0}}
light_source {10, color rgb 1}
//----------------
should _THIS_ be the reason ?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
3d413860@news.povray.org...
>
> > You did not provide a scene... No scene, no gain ?
>
> This is independent of a scene, isn't it?
>
> so take this:
>
> //----------------
> sphere {0,1,pigment{color rgb 1}finish{reflection 0.8 diffuse 0.1}}
> plane {y,-1 pigment {checker color rgb 1 color rgb 0}}
> light_source {10, color rgb 1}
> //----------------
Untested, uh? Your sphere is a little on the way of sight :-)
I would made it:
sphere { <0, 0, 3>, 1 pigment { color rgb 1 } finish { reflection 0.8
diffuse 0.1 } }
plane { y, -1 pigment { checker color rgb 1 color rgb 0 } }
light_source { 10, color rgb 1 }
(I like to space my code :-)
OK, I render it as 1280x1024 AA 0.3 PNG output, stop it in the middle
(Alt+G). I add +C, restart: preview display quickly the done job and
calculate the remainder. Again, OK. The intermediate PNG images are even
displayed OK by IrfanView.
So, no problem for me on WinNT4.
Mmm, however, I got two rendered files (seemingly identical) and a message
indicating it wasn't able to open the original file, so it was creating a
new one.
This can be related to WinNT file access problem I have sometime (ie. a file
is locked even after the end of the locking program).
Regards.
-- #=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=# --
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> OK, I render it as 1280x1024 AA 0.3 PNG output, stop it in the middle
> (Alt+G). I add +C, restart: preview display quickly the done job and
> calculate the remainder. Again, OK. The intermediate PNG images are even
> displayed OK by IrfanView.
> So, no problem for me on WinNT4.
>
> Mmm, however, I got two rendered files (seemingly identical) and a message
> indicating it wasn't able to open the original file, so it was creating a
> new one.
> This can be related to WinNT file access problem I have sometime (ie. a file
> is locked even after the end of the locking program).
This doesn't show the prob I mean ...
Don't stop the image in the middle of the render...
Let it render once, completely!
then render it again with the +c switch ...
afterwards the original file got corrupted.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Jan Walzer" <jan### [at] lzer net> wrote:
> > OK, I render it as 1280x1024 AA 0.3 PNG output, stop it in the middle
> > (Alt+G). I add +C, restart: preview display quickly the done job and
> > calculate the remainder. Again, OK. The intermediate PNG images are even
> > displayed OK by IrfanView.
> > So, no problem for me on WinNT4.
> >
> > Mmm, however, I got two rendered files (seemingly identical) and a
message
> > indicating it wasn't able to open the original file, so it was creating
a
> > new one.
> > This can be related to WinNT file access problem I have sometime (ie. a
file
> > is locked even after the end of the locking program).
>
> This doesn't show the prob I mean ...
>
> Don't stop the image in the middle of the render...
>
> Let it render once, completely!
> then render it again with the +c switch ...
>
> afterwards the original file got corrupted.
Oh, I though +C was to continue rendering on an unfinished image...
Well, sorry, but the two images produced are still readable by IrfanView.
How are they supposed to be corrupted?
Mmm, did further testing... Two renderings without +C give the same file.
Between normal and +C rendering, the files are different (compared with FC
/b). IrfanView (3.70) and SlowView (0.9.9.5) read the +C files OK, XnView
(1.31) chokes on these. So there is indeed something...
-- #=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=# --
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Jan Walzer wrote:
> http://news.povray.org/povray.beta-test/25268/
I can confirm this. You don't even need an animation:
povray -iscene +FN
povray -iscene +FN +C
POV-Ray produces broken image files with every format except PPM (it
doesn't recognize the existing file [1]) and BMP (can't test it on my Linux
system).
[1] Warning: Cannot open continue trace output file. Opening new output
file /home/felix/pov/images/scene.ppm.
--
light_source{0#macro L(K,H,W)sphere{H.5}sphere{K.5}sphere{W.5}cylinder{
H,K.5}cylinder{H,W.5}#end 3}union{L(0v*-2<2,-2>)L(y*-3z-v*5z*3-y)L(-y*3
0u*3)L(y*-3v*-5-z,z*-3-y)rotate-v*clock pigment{rgb.5}translate<0,2,9>}
// +KFF200 +KF720 +W120 +H90 -F -A -GA -P
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Felix Wiemann" <Fel### [at] gmx net> schrieb im Newsbeitrag
news:3d454939@news.povray.org...
> Jan Walzer wrote:
>
> > http://news.povray.org/povray.beta-test/25268/
>
> I can confirm this. You don't even need an animation:
ahh ... at least one ...
interestingly the Win-Version seems to suffer from a different,
but seamless problem (see Philippes posts)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Sorry for messy report, done in a hurry.
For simple scene, camera+sphere+light. File sizes after completed
render, +c option added for the second run (All Win98SE). Only one PNG
rendered.
+w320 +h240 +fn
v3.1: 6.80KB (6.965 bytes), +c 6.71KB (6.876 bytes)
Mega: 6.80KB (6.965 bytes), +c 6.71KB (6.876 bytes)
v3.5: 6.79KB (6.955 bytes), +c 6.69KB (6,852 bytes)
No problem reading the PNGs with PSP 5/7 or IrfanView.
For DOS versions of 3.1 and megapov 0.7, file sizes remain the same
but the time stamp is updated.
BTW if the PNG is deleted and "show" selected in 3.5, the file is
displayed again. Pov keeps a copy of the PNG somewhere?
Alf
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Alf Peake wrote:
> BTW if the PNG is deleted and "show" selected in 3.5, the file is
> displayed again. Pov keeps a copy of the PNG somewhere?
Of course, you don't even need to save the file to disk (-F). POV-Ray
doesn't keep a copy when you deactivate displaying (-D).
--
light_source{0#macro L(K,H,W)sphere{H.5}sphere{K.5}sphere{W.5}cylinder{
H,K.5}cylinder{H,W.5}#end 3}union{L(0v*-2<2,-2>)L(y*-3z-v*5z*3-y)L(-y*3
0u*3)L(y*-3v*-5-z,z*-3-y)rotate-v*clock pigment{rgb.5}translate<0,2,9>}
// +KFF200 +KF720 +W120 +H90 -F -A -GA -P
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> BTW if the PNG is deleted and "show" selected in 3.5, the file is
> displayed again. Pov keeps a copy of the PNG somewhere?
POV saves some data blocks, that aren't written yet into
the png in *.tpn (temporary-png) files. So it is possible
to continue from the last rendered pixel on, and not only
from the last written compressed chunk in the png-file.
But this behaviour seems to break (at least the linux-version)
when the png-file is already completely rendered, but the option
+c is used to render. IMO this should read the file, detect that
the image is already complete, and quit ....
What it does is, that it somehow writes/changes some bytes of the
file. There _ARE_ some progs, that don't have probs, to read such
a "corrupted" file, but most viewers get confused...
could someone please check my assumptions, so we can do a proper
bug-report?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |