|
 |
POV-Ray 3.7.beta.11c 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 Light and vista buffers. These will be replaced with a more efficient system.
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 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.
o Photons do not currently work.
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