|
 |
POV-Ray 3.7.beta.13 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 yet supported but will be added prior to release
-------------------------------------------------------------------------------
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 There are issues with transparency (+UA) in general.
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 Radiosity support is still alpha quality.
o No preview during radiosity pre-trace.
o Dispersion support is alpha and there are some issues.
o 'Pixels rendered' count during mosaic preview will be incorrect.
Changes between 3.7.beta.12a and 3.7.beta.13
--------------------------------------------
Some fixes to bounding and object count statistics.
Fixed render percentage error when a large number of pixels are being
rendered.
Parse and bounding times are now included in stream output.
Implemented debug output to stream.
Bugfix for printing of max depth stopped nodes per node.
Improved error reporting when exception is caught in renderbackend.
Fixed sombrero.pov bug reported in
<web.442c3cd3ccb62fd8c7294af50@news.povray.org>.
Fixed issue with ray interior being removed during evaluation of area lights.
Fixed issue with intersection min depth being too coarse (e.g. the liquid in
the glass in balcony.pov did not render).
No longer send mem usage stats as they are not accurate (will restore this
before final release).
Fixed photon memory issue referred to in
<web.444b4f4ed5b924f08b9c27240@news.povray.org>.
Fixed object count when no bounding is used, rendering empty file leaves stop
icon, and winpov exit command not working issues as reported in
<442df1da$1@news.povray.org>.
Changes between 3.7.beta.12 and 3.7.beta.12a
--------------------------------------------
Fixed issue with BSP that caused long build times on large trees.
Changed default BSP child access cost to 5.0 (was 1.5).
Fixed issue with BSP trees that would cause some objects to vanish.
Added an optimization which speeds up BSP renders.
Changes between 3.7.beta.11c and 3.7.beta.12
--------------------------------------------
Fixed spheresweep copy bug reported in <43fbaf97$1@news.povray.org>.
Fixed 'aa incorrectly reported to be on' issue reported in
<43fc75f9$1@news.povray.org>.
Added progress and stats reporting for BSP bounding.
Fixed camera inside media/interior mostly lost bug.
Fixed debug message output.
AA method 1 block artifact fix (<43ebe0bc@news.povray.org>). Also correct
some jitter option issues. NB it is still technically possible that
block-boundary AA artifacts could occur but they are much less likely.
Fixed bug in generation of lit intervals for media.
Fixed "light doesn't pass through transparent image_map" issue
(<43a97c75$1@news.povray.org>).
Fixed 'trace fails with no_image object in union' bug
(<43f57a9d$1@news.povray.org>.)
Fixed issue where cancelling a render may not work if all CPU resources
are committed to the render.
Fixed 'unrecognized file format' warning when HDR output is selected.
Fixed flipped image HDR reading bug (<43e8190e@news.povray.org>)
Fixed one dispersion bug (long render times).
Re-implemented display retention and bitmap preservation during animation.
Added fix for image filename generation and rendered pixel counting.
Fixed gamma assignment in PNG output.
Render Window
-------------
Due to issues with CPU usage, the new render window is now by default
off. To work well this feature requires that hardware-assisted alpha
blending is available on the target system, and as of the time of writing
this is not common enough to justify turning it on by default.
Note: it will remain turned on if you already had it on (e.g. from a
previous beta).
BSP Bounding
------------
BSP (Binary Space Partitioning) tree bounding is now available. To turn
it on use '+B2' or 'Bounding_Method=2' in the INI file or on the command-
line. When it is in use you will get some additional statistics in the
output pane regarding the built tree.
Please keep in mind that this implementation of BSP is highly beta and
will not speed up scenes in many cases (and in fact may slow some down).
In particular the building of the tree can take a long time and lots of
memory in severe cases. Using the BSP tree rather than our traditional
BVH system (default or +B1) is a choice best made for specific scenes
that will benefit from the way the BSP operates, and in particular if
the render is long enough to offset the build time. (The BSP tree build
time will be constant for a given scene and set of BSP parameters,
regardless of the output resolution. A 30-second BSP build may not be
a good choice on a 60-second test render but may be acceptable for a
60-minute final render if the use of BSP adds a few PPS).
On some scenes the difference however will be dramatic, with short
build times and radically increased render speed.
We have provided some BSP-related options via the INI file and encourage
you to experiment with them to see if you can get better results than
the default values built in to POV-Ray. We will listen to feedback from
this and if necessary tweak the defaults. We do not guarantee that all
of the following INI file settings will remain in the final release of
3.7.
BSP_MaxDepth=128
BSP_BaseAccessCost=1.0
BSP_ChildAccessCost=1.5
BSP_IsectCost=150.0
BSP_MissChance=0.2
The values shown above are the default. You can also get the defaults
if you use a value of 0 for any of the above (or of course just by not
specifying the option at all). For an explanation of what the values
mean you may refer to Ray Tracing News v17n1 (look for Eric Haine's
article on BSP), or follow the discussion on BSP that is sure to crop
up in the beta-test group.
Please note that we are aware of some render artifacts visible with +B2
and are seeking to address them. Don't be surprised if you find some,
and if you can generate a minimal scene demonstrating them feel free to
post it to the appropriate group.
Example BSP scene
-----------------
There is a scene included with this release called 'Tango.pov' which is
a good example of a scene that benefits from the BSP bounding.
Tango.pov rendered at 800x600, no AA -
With +B1 : 70 seconds total
With +B2 : 48 seconds total
Changes between 3.7.beta.10 and 3.7.beta.11c
--------------------------------------------
No core bugs have been fixed. This release extends the expiration time
to the start of April 2006 and provides a new render window feature.
Render Window
-------------
The new render window mode is only available on Windows 2000 or later.
The presence of this code may case the beta to be unable to load on
Windows 9x systems; if this occurs it will be fixed in the next beta.
Note that we have not tested this new code on a Windows 2000 system,
so we can't comment on how well it will work on those systems.
To activate the new render window, open the 'Render Window' sub-menu in
the 'Options' menu, and select the 'Use New-style Render Window' entry.
The new render window is designed to help users get around the issue of
the render window getting in the way when doing edit/render/fix cycles.
It supports a 'transparency' mode that is in effect two things: both
optical transparency (or more specifically translucency), and input
transparency (more specifically, the Windows WS_EX_TRANSPARENT style).
'Input transparency' means that the window is transparent to input -
so if you move your mouse over it or attempt to click on it, the mouse
messages are in fact sent to whatever is underneath the window. In
effect therefore it is as if the window were not there - even if you
can still see it.
The effect of this is that, coupled with translucency, you can both
see what is under the window (e.g. the POV-Ray editor), and also work
with it (typing or selecting with the mouse, etc).
'Input Transparency' is enabled whenever you set the translucency of
the render window to 25% or more (see below). At settings less than
this, the render window will behave more or less as normal (though
without some of the features of the classic render window, such as the
ability to be de-coupled from the main window such that it does not
get hidden when the main window is minimized).
To set the translucency of the render window, either rotate your mouse
wheel when the render window has focus (this is the preferred method),
or alternatively right-click on the window's title bar and choose a
setting from the context menu that is provided.
When the render window has input focus, translucency is removed and it
becomes opaque. It will switch back once another window gets focus, or
if you adjust the translucency using one of the above methods.
If you want to work with input transparency, it is important that you
understand that this means you can't work with the render window in
the manner you are accustomed to, since of course the window will pass
input to the application below it. To allow for interaction with the
window in this circumstance, we have added a feature whereby hovering
the mouse over the render window's caption for a short time, or clicking
on the title bar, will activate the window, make it opaque, and allow
input to be processed normally.
(Of course the ability to click on the caption means that it's not
completely input transparent, and we might disable this feature later
if the hover feature works out well).
You will know if your mouse is over the appropriate area of the window
since the cursor will turn to a hourglass shape during the 'hover' time.
Provided that the window is left in input transparency mode, if you
move your mouse out of the window for a short time, it will automatically
snap back into its former translucent mode.
You can tell if the window is in input transparency mode by looking for
a '[T]' at the start of the render window caption. If present, then it's
going to pass input to the application underneath it. While adjusting
the translucency with the mouse wheel, the caption will display the new
translucency setting and, if appropriate, a comment that the window has
switched to passing input. (Recall however that this doesn't kick in
until you switch focus to another window).
Changes between 3.7.beta.9 and 3.7.beta.10
------------------------------------------
Added gamma correction support.
Add more frequent stop-checking to all render tasks.
Radiosity now works a lot better than beta.9.
Fixed some memory leaks in radiosity.
Fixed crash in some image file reads.
Improved handling of cancel render in windows version.
Fixed output filename generation logic.
Changed all internal file paths to UCS2.
Fix for using truetype in CSG.
Improved responsiveness in backend.
Gamma Correction
----------------
The way POV-Ray 3.7 handles the 'assumed_gamma' keyword has changed.
Previously the presence of this keyword in global_settings caused a
'possible error' warning and its presence was ignored. In addition
no gamma correction was available in previous betas. Starting with
beta.10 however, gamma correction is performed on both the display and
file output, subject to the following criteria:
o If the scene language version is set to 3.7 (or not set at all), then
gamma correction will default to ON, with the value used being set by
the 'display_gamma' INI file setting. Note that in previous versions of
POV-Ray gamma correction was OFF by default but otherwise this is the
same.
o If the scene language version is set to earlier than 3.7, then gamma
will be OFF by default.
o Notwithstanding the above, if the keyword 'assumed_gamma' is present
in the scene's global_settings, then POV will take one of the following
actions:
a) if "assumed_gamma 2.2" is present, gamma correction will be turned
OFF and a warning issued. the same thing will happen if the value
specified is not 2.2 but happens to be the default for the
platform setting given to POV-Ray when it was compiled (e.g.
Windows is 2.2).
b) if "assumed_gamma 1.0" is present, gamma correction will be turned
ON (if it's not already on) and in any case a warning will be
issued.
c) if a value other than the above is specified, it is ignored and a
'possible error' message is issued.
You will note from the above that therefore it is no longer possible to
adjust the amount of gamma correction from a scene file. This is as
designed since scene files should be as much as possible be platform
independent, and the gamma of particular display hardware does not
belong in the scene file. If you really need to specify 'assumed_gamma'
you can do so in an INI file or on the command-line; however in those
cases you may as well just use 'display_gamma' in its place.
When writing file formats that support gamma specification, the inverse
of the assumed_gamma value will be embedded in the file headers, so
that an appropriately equipped display program can 'undo' the gamma
correction if it is so desired. This is as per previous versions of
POV-Ray.
Frontend and Backend
--------------------
Note that POV-Ray uses a logical separation of frontend and backend. The
'frontend' is that part which deals with the user-interface, locating
files, parsing command-line options, reading INI files, and so forth. The
'backend' deals with parsing the scene file and doing the actual render.
These two parts of POV-Ray communicate via a message-passing interface,
even when linked into the one executable program.
Whilst currently not supported, it is entirely possible to separate the
front and back ends via for example a network interface, and have the
render done on one machine while the user interface (and display) is on
another. Knowing this may make it easier to understand why, for example, we
are moving away from allowing things such as gamma correction to be
specified in the scene file; there is no reason to assume the scene file is
on the same machine as the image will be displayed upon, and as such the
specification of gamma should be done in the frontend via INI or
command-line options.
There will be more changes along these lines as we prepare for the future
transition to a fully network-capable renderer. The POV-Team will attempt
to ease the change to the new system by doing things such as the
assumed_gamma interpretation above, where it is possible to do so.
Changes between 3.7.beta.8 and 3.7.beta.9
-----------------------------------------
Fixed crash caused by resource exhaustion (too many threads); refer
<4303d267$1@news.povray.org>.
Addressed state issue referred to in
<web.42af2f04951c51e46a3607400@news.povray.org>.
Fixed output file reporting issue reported in
<web.430dc75ff23d654e726bd13c0@news.povray.org>.
Fixed AA method 2 crash reported in <430358ed@news.povray.org>.
Fixed render window re-display problem.
Moved assumed_gamma to command-line or INI-file only option (causes
warning if found in scene).
Fixed focal blur problem.
Render block size
-----------------
You now have the ability to specify the render block size via either an
INI-style option ("Render_Block_Size=n") or on the command-line ("+BSn"),
where 'n' is an integer larger than or equal to 4. This represents the
edge size of the square used to distribute work to the render threads,
and thus the number of pixels in each block will be n squared.
The default value is 32. If you specify a value that is greater than the
larger of the width or height of the image being rendered, it is clipped
to that value.
Note that using render block sizes of less than eight can impact
performance, particularly on large images that render quickly, as it
significantly increases the amount of message traffic between the render
backend and the graphical frontend (which communicate using a shared-memory
queue).
Editor
------
A few changes have been made to the editor in the hope of avoiding the
error that some users get when it attempts to open a file that has been
removed from the disk. We have not been able to replicate this error
ourselves (the code was already designed to handle this situation) so we
have added some extra checks. The net result of this is that when a file
no longer exists, instead of opening a blank file, the edit session for
that file will instead be discarded.
Additionally we have improved the handling of modified files during active
application changes; now, you should never get more than one message box
displayed at any one time (which previously could happen if you switched
focus multiple times).
Dispersion
----------
Dispersion has been added back, however this is still mostly untested.
There will be numerous issues with this; we would appreciate help in
identifying what they are and where they may lie (i.e. reports that
'dispersion doesn't work properly' with no additional information will
not be of much help).
Radiosity
---------
Radiosity has been re-enabled. Currently it is limited to a single thread
and has some issues. As stated for dispersion, we would appreciate
assistance in determining where individual issues lie and what influences
them.
Multi-thread support will be added later, once the radiosity code settles
down and is functioning as expected in single-thread mode.
Mosaic Preview
--------------
Mosaic preview now works again. The same issue as mentioned in the above
section on render block size apply; we don't recommend using an end preview
size of less than 8. Note that unless you specify an end preview size the
code will default to using +ep2, so it is strongly recommended that you
do provide it.
Be aware that when using mosaic preview, the count of rendered pixels shown
in the status bar will be wrong. This will be fixed later.
Improved handling of large render sizes
---------------------------------------
Handling of large renders (e.g. 10,000 x 5,000 pixels) has been improved.
Previously the intermediate data structure used to store rendered pixels
was held in RAM. On windows it is now stored in a virtual-memory backed
file which maps to the swap file. This means that your swap file needs to
have at least enough free space to store this file at the start of a
render. For reference, the amount of room needed is roughly 20 bytes per
pixel, so the above example 10,000 x 5,000 pixel image would need one
gigabyte in the swap file.
One other issue to be aware of is that, on windows, there has to be enough
contiguous virtual address space available to hold the file. This can be a
problem since by default many Win32 systems only provide each process a
total of two gigabytes of address space, which is then divided up amongst
the exe and its various DLL's, the local heap, stack, and so forth.
Additionally some Win9x versions (at the least Windows 95) will only allow
a maximum of one gigabyte to be mapped in this way, and that is divided up
amongst other resources as well.
Therefore it is entirely possible that even if you have sufficient swap
space the allocation of the memory mapped file will fail, at least for
win32 users (win64 won't have this problem). We are working to fix this
limitation by moving to a less efficient but more reliable file-based
solution.
One final note: please be aware that the Windows process manager will add
the amount of virtual memory mapped by a process in this way to its total
memory statistics. Please don't assume that the figure reported by Windows
is necessarily the amount of physical RAM being used.
Changes between 3.7.beta.7 and 3.7.beta.8
-----------------------------------------
AA buffering restored; AA should be as efficient as version 3.6 now.
Fixed major problem in crackle when using more than one thread.
Reverted to older version of Intel compiler to avoid some optimization bugs.
Added HDR file support (RGBE, as used in Radiance).
Added EXR file support using OpenEXR library (http://www.openexr.org/).
Fixed animation clock jump issue.
HDR Support
-----------
As of this beta POV-Ray now supports two HDR formats for input and output.
Firstly, .HDR files (as used in Radiance), and secondly, .EXR files (see
www.openexr.org).
The OpenEXR format is currently supported in basic form; no options can be
set and we do not store any additional data such as a thumbnail or camera
transform. We will add options later on. The EXR reading code should handle
any valid EXR file, while the writing code currently only creates RGBA data
in Half format.
The EXR support is based on OpenEXR (http://www.openexr.org/) from ILM, who
use it internally for all their film production. The format is flexible; we
recommend anyone interested in HDR read the introduction that can be found
at http://www.openexr.com/TechnicalIntroduction.pdf.
Also at the above site you can obtain a HDR image viewer and a Photoshop
plugin (Windows and Macintosh) that reads and writes EXR files.
Please note that POV-Ray does not gamma-adjust the HDR or EXR files; they
are stored with a gamma of 1.0. The OpenEXR viewer assumes a gamma of 2.2
so the images will look washed out. The Photoshop plugin allows you to set
the gamma to 1.0 on loading and thus will work as expected.
To use HDR input, use file type 'hdr' in your SDL. To write a HDR file,
specify '+fh'. For EXR use 'exr' and '+fe'.
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
|
|
povray