 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
POV-Ray 3.7.beta.7 is available from http://www.povray.org/beta/.
This beta is currently for the Windows platform only and includes standard,
SSE2, and 64-bit binaries.
---------------------------------------------------------------------------
Note: to view an original bug report, prefix the message ID with the URL
http://news.povray.org/. For example, to read <42765ef3$1@news.povray.org>,
visit http://news.povray.org/<42765ef3$1@news.povray.org>. The '<' and '>'
are optional (if using a shell you may want to omit them).
---------------------------------------------------------------------------
The following features are not supported but will be added prior to release
---------------------------------------------------------------------------
o Radiosity.
o Dispersion.
o Mosaic preview.
o Light and vista buffers. These may replaced with a more efficient system.
o Ability to choose block size allocated to threads.
o Windows rerun dialog and statistics.
o Redirecting text message output to files.
Known issues which will be fixed
--------------------------------
o There is an issue with media and transparency. See
<42769324$1@news.povray.org>.
o The windows editor does not always detect new files as type 'povray'.
o In many cases speed is not as good as 3.6.
o Photon support is not yet completed.
o There are some differences in the way gamma correction works.
o Anti-aliasing method 2 currently takes more samples than in version 3.6
and earlier.
Changes between 3.7.beta.6 and 3.7.beta.7
-----------------------------------------
New thread-safe random number generator added.
Continue trace support added. See below for details.
Animation support added.
Made render cancellation more responsive when large numbers of threads are
in use.
Fixed most wrapping problems in windows message display.
Continue Trace Support
----------------------
The continue trace support has completely changed from the method used by
past versions of POV-Ray. Previously, various means of attempting to detect
the rendered and non-rendered portions of an output image file were used to
determine where to resume rendering, and the pre-rendered portion of the
image was read from the partially-written output file.
As of POV 3.7, *no output file is written until the render is complete*.
It is vital to remember this if you depended on having a partial image
written for some reason other than POV's internal use. Instead of a image
file, POV will (providing image file output is turned on) write a render
state file, which has a name based on the output image file name. For
example, if POV would write 'sphere.png' as the output file, the render
state file would be called 'sphere.png.pov-state'.
This render state file contains the raw floating-point image data that is
generated by POV, including filter and transmit. It will later on also
contain other information such as all render options, etc. The data itself
is stored in an internal format that we may document at a later stage.
If a render if sucessful, the render state file is deleted and the output
file written. Note that this order will be changed (the state file should
not be deleted until the image is written, in case the write fails). We may
give the option of preserving the state file at some future point.
If a render is started with the +C option (continue trace), POV will first
check to see if the output image exists and is of non-zero length. If so
the render will be skipped. Note that no attempt is (currently) made to
sanity-check the file to ensure it is a valid image file or of appropriate
format or size.
If the output file does not exist, POV will then look for the render state
file. If found it does a basic sanity check on it then loads the data in it
and proceeds to render the unrendered portion of the image.
It is very important to note that the data is stored in the state file in
'blocks' (the same size as the render blocks that were used when the first
part of the image was rendered). The size of render blocks can change if
image resolution changes. Currently the continue code does NOT check for
this and will simply load what is there. If the render size has changed
sufficiently enough to change the block size when you run a continued trace
it is almost guaranteed that you will not get what you expect.
Changes between 3.7.beta.5a and 3.7.beta.6
------------------------------------------
Fixed quadric bounding problem.
Fixed CSG merge problem.
Made numerous other changes to speed up code, should be closer to v3.6.1 now.
Changes between 3.7.beta.5 and 3.7.beta.5a
------------------------------------------
Fixed bug reported in <428de855@news.povray.org> re:sunsethf.pov.
Worked around SMP bug in trace related to lighting code altering lightsources
during render.
Changes between 3.7.beta.4 and 3.7.beta.5
-----------------------------------------
Fixed a photon building issue that caused progressive slowdown.
Fixed scattering media problem reported in <427ca163@news.povray.org>.
(This also fixes <427c0121@news.povray.org>).
Parser now honors Split_Unions and Remove_Bounds options.
Fixed lathe artifacts bug reported in <427c0f95@news.povray.org>.
Fixed no_image and no_reflection issues reported in
<427c1900@news.povray.org>.
Fixed area light orient issue reported in <427c14ef@news.povray.org>.
Fixed issue where a new clip statement would overwrite a previous one rather
than appending to it.
Fixed speed issue with quadrics by reverting to old bbox calculation method.
Fixed a swathe of memory leaks.
Changes between 3.7.beta.3 and 3.7.beta.4
-----------------------------------------
Fixed indexed PNG alpha problem reported in <42765ef3$1@news.povray.org>.
Fix area light problem reported in <427a3fa5$1@news.povray.org>.
Fixed crash during trace of lathe reported in <42796797@news.povray.org>.
Improved handling of cancel/pause render.
Fixed max_trace_level calculation and display (see
<42769105@news.povray.org>).
Fixed image memory leak.
Fixed speed issues reported in <42769f6d@news.povray.org>.
Fixed shadow problem mentioned in <42769f6d@news.povray.org>.
Fixed sphere_sweep bug reported in <42773e51@news.povray.org>.
Fixed 'inverting pre-declared union' crash reported in
<42769b59@news.povray.org>.
Fixed focal blur issue.
Fixed omnimax camera bug reported in <42775c1b$1@news.povray.org>, plus
several other related camera issues.
Fixed facets pattern crash reported in <42773fab$1@news.povray.org>.
Changes between 3.7.beta.2 and 3.7.beta.3
-----------------------------------------
Partial render (start col/row etc) now works
Fixed CSG merge issue reported in <42645c3b@news.povray.org>.
Added warning and better progress reporting to photons.
Some hollow media fixes.
Re-enabled alpha display in render window for windows port.
Fixed alpha bug reported in <web.426402d627a031d914107e060@news.povray.org>
Fixed no_image bug from <web.426402d627a031d914107e060@news.povray.org>
Changed default bounding threshold back to 3 as per v3.6.
Fixed alpha inversion bug in BMP, Targa, and PNG file reading/writing.
Fixed crash mentioned in <42689685@news.povray.org>.
Fixed noise generator default issue reported in <426898db@news.povray.org>.
Fixed irid problem reported in <42680b39@news.povray.org>.
Fix for area light problem from Massimo Valentini.
Made quick_colour work as it should.
Changes between 3.7.beta.1 and 3.7.beta.2
-----------------------------------------
CSG should now work properly
Problem with too many recursions when rendering shadows fixed
I/O restrictions should now work
Fixed recursion bug in renderer
Initialise photon variables
Restore ability to open error file in editor (note: column number not always
correct).
Fixes no-display crash
Fixes image closing bug
Tweak to some radiosity local vars
Fixes rendering area bug
Fixes AA method 2 brightness issue
Add output file type '+FB' (bmp).
Add 'bmp' token to parser.
Fix for BMP reading.
File output defaults to on.
Fix render quality options output.
Change references to 'CPU(s)' to 'thread(s)'.
Update render time output to include fractional seconds.
Fix crash reported in <4263125b@news.povray.org> and one related bug.
Intentional changes for POV-Ray 3.7
-----------------------------------
The version directive and command-line setting no longer provide compati-
bility with most rendering bugs in versions prior to POV-Ray 3.5. However,
compatibility with the scene language is provided for scenes as old as POV-
Ray 1.0 just as in all previous versions of POV-Ray. Nevertheless, we
strongly recommend you update scenes at least to POV-Ray 3.5 syntax if you
plan to use them in future versions of POV-Ray.
This version uses multi-threaded rendering by default. The ability to render
in more than one thread is primarily of use to those users who have SMP
machines (i.e. more than one CPU). There have been reports of benefits for
users of hyperthreading systems, particularly with higher thread counts (e.g.
16 threads).
You can render in only one thread by using the '/THREADS 1' switch in the
Windows version. Note that parsing and photon building will only use one
thread no matter how many are specified. However photon scenes will benefit
from multiple threads once photon building has completed.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In povray.general Chris Cason <nos### [at] deletethis povrayorg> wrote:
> This render state file contains the raw floating-point image data that is
> generated by POV, including filter and transmit.
A voice in my head says "postprocessing, postprocessing,
postprocessing..." :P
By the way, doesn't this require awful amounts of disk space, especially
for larger images?
Well, I suppose you can assume that if someone is working with graphics
he will have tons of space. :)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> A voice in my head says "postprocessing, postprocessing,
> postprocessing..." :P
>
> By the way, doesn't this require awful amounts of disk space, especially
> for larger images?
> Well, I suppose you can assume that if someone is working with graphics
> he will have tons of space. :)
Yes, depending on the render block size you can expect about 24 bytes per
pixel or so on average. There is a fixed overhead per block, plus that of
each pixel. Eventually we are considering to allow zlib compression.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > This render state file contains the raw floating-point image data that
is
> > generated by POV, including filter and transmit.
>
> A voice in my head says "postprocessing, postprocessing,
> postprocessing..." :P
Yeah, I think this intermediate file format offers a lot of possibilities.
POV-Ray is no longer simply writing an image to a file; it's now storing
information about the image that it can use for its own purposes.
One possibility, for instance, is the potential to reuse mosaic preview data
in the final trace. If it were stored somehow in this intermediate file, it
could be read from during the final trace or during a continued trace. (This
may have difficulties with the "block" storage format, I dunno).
You could take a render state file from a completed render and produce a new
image from it with some changes - perform anti-aliasing on an image that
wasn't anti-aliased, change the brightness (and not suffer from clipping in
the original output because floating points are available), and if
anti-aliased pixel colors were separated from pre-anti-aliased colors, you
could double the horizontal and vertical resolution (by rendering the areas
"between" pixels). You could rerender certain areas of the image while
keeping old areas.
I guess a lot of these ideas will end up being not worth the effort, but I'm
excited about the possibilities. =)
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In povray.beta-test Chris Cason <nos### [at] deletethispovrayorg> wrote:
> Known issues which will be fixed
> --------------------------------
> o There is an issue with media and transparency. See
> <42769324$1@news.povray.org>.
> o The windows editor does not always detect new files as type 'povray'.
> o In many cases speed is not as good as 3.6.
> o Photon support is not yet completed.
> o There are some differences in the way gamma correction works.
> o Anti-aliasing method 2 currently takes more samples than in version 3.6
> and earlier.
I notice that this list does not include the problem with antialiasing
method 1 in some scenes (such as stackertransp.pov). Perhaps it should
be added.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The 3.7 beta 7 license has expired as of this morning (2005/8/15). Can
someone report when the next beta will be released?
Thanks.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chuck Y wrote:
> The 3.7 beta 7 license has expired as of this morning (2005/8/15). Can
> someone report when the next beta will be released?
Before version 4.0
--
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
