![](/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) |
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) |