Professional Documents
Culture Documents
Changes
Changes
# Note: To view an original flyspray bug report (FS#xxx), replace the leading
# FS# of the bug ID with the URL http://bugs.povray.org/.
# For example, to read FS#270, visit http://bugs.povray.org/270.
# To view a referenced newsgroup posting (<xxxxx@news.povray.org>), 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).
#----------------------------------------------------------------------------
----------------------------------------------------------------------------
Changelog information is available in the file revision.txt, which should be
located in the same directory as this file is.
----------------------------------------------------------------------------
---------------------------------
Changes between 3.7.RC7 and 3.7.0
---------------------------------
- This is the version 3.7.0 release, and mostly things are in order,
however a few minor bugs have been addressed. Continued efforts towards
addressing static code analysis issue's resulted in the inclusion of
several high profile fixes into this release. The scene files included
with the distribution have been reviewed as well. This includes
version branding, deleting some older irrelevent files, and a few new
additions. The windows version insert menu files were also updated and
expanded. Additionally the insert menu templates are now also available
in HTML for convenient use with 'cut and paste'. The distribution package
has been branded with a different (AGPL3) license.
- For technical reasons the Macintosh OS graphical user interface was not
ready at the time of this release. However, the source code will be made
available to users so they can build there own binary if the wish.
Windows Related:
----------------
- Several fixes were rolled back, pending further investigation. They have
been tabled for inclusion in a future release.
Other Noteworthy:
-----------------
-----------------------------------
Changes between 3.7.RC6 and 3.7.RC7
-----------------------------------
Windows Installer:
------------------
Other Noteworthy:
-----------------
- Several updates to #5678 (FS#233): workaround for fmod() apparently not
conforming to C++ standard on some linux machines.
- Fixed radiosity issues with "diffuse albedo" syntax.
- Fix for benchmark thread vs CPU count (windows version).
- Fix to get rid of a shape/poly.cpp compile warning on Linux variants
- Added (re-enabled) crand support.
- Couple of fixes for an issue caused by a "boost" change.
- Build-in benchmark can now render without external distribution files.
- Fixed a bug in file-backed image container.
- Bump benchmark version to 2.01
- Various windows user interface refinements
- Added new option to prevent the system (windows) from sleeping whilst a
render is in progress. by default this is selected.
- Fix a long-standing bug where pressing 'pause' during a parse or render
could sometimes put the frontend/backend sync into an unrecoverable state
- Updated copyright information for some 3rd party libraries.
- A few signedness fixes in image handling code.
- Continued code cleanup including getting rid of unused code & parameters.
- Updated VS project libraries: zlib, libpng, libjpeg
- Added Append_File +GP option, which allows users to append streamed
console to existing console stream output file(s).
----------------------------------------
Changes between 3.7.beta.RC5 and 3.7.RC6
----------------------------------------
Windows Installer:
------------------
Other Noteworthy
----------------
----------------------------------------
Changes between 3.7.beta.RC4 and 3.7.RC5
----------------------------------------
- This release candidate primarily addresses the crash dump report #357
triggered by non-closed SSLT-enabled mesh inside CSG. This fix also
addressed several issue's with another outstanding bug report.
- The Windows installer and crash dump submitter have been improved.
- Changes to the post processing of the Windows help file corrected the
broken searchable index.
----------------------------------------
Changes between 3.7.beta.RC3 and 3.7.RC4
----------------------------------------
- This release candidate primarily improves upon the SSLT code, but there
are also some other noteworthy enhancements and/or additions.
- Building from the windows source distribution has also been simplified
- Introduced a new windows installer
- Added AMD optimizations for noise
- A Windows Editor crash fix
- Over two dozen bug reports have addressed
- A few scene file fixes and/or additions
- Updated the Windows help file
The pigment determines the SSLT material's overall appearance when applied
to an object with sufficiently large structures. The translucency color
(which can alternatively be a float) determines the strength of the
subsurface light transport effect (note that the values may be >1.0; also
note that the effect doesn't scale with the object; instead, to adjust
materials to the dimensions of your scene, use the global mm_per_unit
setting). The material's index of refraction also affects the appearance of
the material, and is mandatory for SSLT materials.
Due to the experimental status of SSLT, there are currently some caveats:
- Incorrect use may result in hard crashes instead of parse warnings.
- Pigments having any zero color components currently don't play nice with
SSLT; for example instead of "rgb 1" you should use something like
"rgb <1,0.05,0.05>".
- A Diffuse finish attribute of zero can cause the program to have an
assertion failure.
- changes to improve robustness regarding low translucency and/or high
mm_per_unit settings for objects in general and blobs in particular
added support for CSG (caveat: unions of overlapping components will cause
unexpected results; use merge instead)
Other Noteworthy
----------------
- Added new "albedo" keyword, that can be used right after "diffuse",
"phong" or "specular" to specify that the parameter is to be taken as the
total diffuse/specular reflectance, rather than peak reflectance. E.g.:
Note that for brilliance = 1, the "albedo" keyword has no effect on the
diffuse parameter.
- Added AMD optimizations for noise. Note that these are currently disabled.
A subset of the Boost 1.45.0 and openEXR 1.6.1 libraries have been added to
the windows source distribution so that users can easily build thier own
statically linked binary from scratch. Added "Console" and "Console-SSE2"
configurations to VS10 solution, but needs to be back-ported to VS8/9 as
there is no debug configuration yet. Extensive testing still required ...
expect shellout to be still dysfunctional.
- The crash reporter tool has been reworked to always generate both full and
mini dumps because often insufficient information was available to resolve
the crash, consequently compression support was also added.
- A windows editor fix for a problem that was reported in crashdump #111
Windows Installer:
------------------
Introduced a new windows version NSIS based installer, further improvements
pending. Currently there are a few caveats:
- It won't ask you to uninstall the old beta (don't use MSI anymore)
- It won't object if you try to re-install over the top of an existing install.
- It also requires elevation on Vista and Windows 7 as it allows installation
to the program files directory (the default now).
----------------------------------------
Changes between 3.7.beta.RC2 and 3.7.RC3
----------------------------------------
This release candidate is primarily to correct a bug in media that was causing
crashes. It also improves a performance issue related to output file caching.
The efficiency of the code for caching output files on disk has been improved.
In addition, the point at which an output file is cached has been changed from
a compiled-in number of pixels to a user-defined number of megabytes.
When rendering an image that has output to file turned on, POV-Ray will cache
the image in two places: firstly, a .pov-state file, which is always on disk.
This is not technically an image file but a record of the communication
between the internal frontend and backend, which also contains the image pixels.
This file is only ever needed if you wish to re-start a render using the +c
option. It is deleted upon successful completion of a render.
The second place an image is cached is in an image buffer, which contains only
the image pixels. This buffer is what is used to create the final output image
once a render completes. The buffer is stored in a neutral format (i.e. not in
any way related to the selected output file type), and may either be in RAM or
on disk.
Storing it in memory removes the above performance penalty, but may add a worse
one if you are rendering at a very high resolution and the size of the resulting
memory buffer causes parts of the parsed POV-Ray scene to be swapped to a page
file by the operating system. This can slow down a render by several orders of
magnitude, depending on the circumstance.
The point at which POV-Ray will change from an in-memory buffer to a disk buffer
is controlled by the new Max_Image_Buffer_Memory INI parameter (+IM if specified
via the command-line). If not supplied, POV-Ray will default to 128mb. If supplied,
the number represents the approximate number of megabytes (1,048,576 bytes) that
POV-Ray will allow the internal image buffer to occupy. If an image exceeds this
size, the image buffer will be placed in a temporary file on disk instead. Note
that this decision is made upon the start of the render - the buffer does not grow
during render, but is pre-allocated to the size required to hold all the pixels.
As a guide, you can expect POV-Ray to use 20 bytes per pixel to store the image
during render. Thus, the default 128mb size allows an image of up to about 6.7
million pixels to be stored in RAM (approximately 2600 x 2600 pixels).
You should definitely consider reducing this default if your system is memory-
constrained or you are rendering a scene that generates a particularly large
dataset.
The windows version of POV-Ray has a small memory monitor in the statusbar. It
updates several times per second with an estimation of the amount of memory being
used by the application. You can use this as a guide to determine the amount of
RAM in use.
---------------------------------------
Changes between 3.7.beta.41 and 3.7.RC2
---------------------------------------
-----------------------------------------
Fixed or mitigated the following reports:
-----------------------------------------
fixed crash found by crashdump #77 (platform base can be NULL before the image
class gets destroyed in the case of unusual shutdown).
using "color srgb" (or similar) before assumed_gamma was defined resulted in
a hard crash; fixed by generating a proper parse error instead.
------------
Misc Changes
------------
make windows status pane a bit wider and add process memory usage slot in
status bar.
go back to using the current version as the default language version and
modify the warning messages associated with a missing or late #version.
-----------
SDL Changes
-----------
Gamma Handling:
Colors specified using "srgb" & co. will be converted from sRGB to the
working color space.
For render preview, the generated image will be converted from the working
color space to that specified by the Display_Gamma setting. If
Display_Gamma is not specified, a platform-specific default will be
presumed.
For file output, the generated image will be converted from the working
color space to whatever the file format mandates (this applies to OpenEXR
and Radiance HDR); if no such mandatory color space exists, the image will
be converted into that specified by the File_Gamma setting. If File_Gamma
is not specified either, the image will be converted into whatever is
officially recommended for that file format, or the de-facto standard; if
even that doesn't exist, no gamma adjustment is performed. In any case, if
the file format provides a means to specify a gamma in the image header
(this applies to PNG), the respective data is set according to whatever
gamma the image is converted to, regardless of the working color space.
--------------------------------------------
Changes between 3.7.beta.40 and 3.7.beta.41
--------------------------------------------
-----------------------------------------
Fixed or mitigated the following reports:
-----------------------------------------
------------
Misc Changes
------------
Added new include file, "ior.inc", defining ior & dispersion constants for a
lot of materials.
-----------------
Dithering Support
-----------------
Add support for output file dithering; dithering is controlled by the INI
file settings "Dither=BOOL" and "Dither_Method=xx" as well as the command
line option "+/-THxx", where xx is one of:
The default is "-THfs", i.e. dithering is off, with Floyd-Steinberg being the
default if only "+TH" is specified.
Dithering works for all file formats except JPEG and OpenEXR (no intention to
implement) as well as Radiance HDR (non-straightforward to implement); these
file formats simply ignore the setting.
Display_Gamma now supports the "sRGB" option just as File_Gamma already did;
besides "sRGB", "srgb" and "SRGB", any combination of upper-/lowercase
letters is now recognized.
-----------
SDL Changes
-----------
Added new way to describe a polynomial equation (the old way is still valid):
Updated colour syntax for gamma pre-corrected colours; dropped the "gamma"
keyword
there (it remains enabled for image input files) in favor of the following
syntax:
Changed the mechanism to retrieve & format the current time from SDL; new
syntax is as follows:
- The keyword "now" evaluates to the time elapsed since 2000-01-01, 00:00:00
GMT in days, with a precision of seconds or better.
--------------------------------------------
Changes between 3.7.beta.39 and 3.7.beta.40
--------------------------------------------
-----------------------------------------
Fixed or mitigated the following reports:
-----------------------------------------
------------
New Features
------------
--------------------------
Pavement & Tiling patterns
--------------------------
Tiling # (#: 1 to 24) provide 24 classical tiling pattern with 1 or more kind
of tiles. The full map is used when rendering a tiling. All centers of tile
is at i/num, border at (i+1)/num) (for i from 0 to num-1). The gradient on
each tile is the same for every tiles on the same tiling. When more than one
kind of tile is used (#), the border are at 1/#, 2/#, ... #-1/#
* pattern (depend on side & tile) (1 to ...): how the basic are combined
together
* interior (1 to 3)
Added square & triangular pattern (2D, in xz plane, 4 & 6 area in shape of
squares and triangles)
--------------
Ovus Primitive
--------------
----------------------
Fractal pattern update
----------------------
Experimental, add exterior type 7 & 8 for fractal pattern, using the number
of actual iteration to get out (=e) and the factor (=n). 7 gives back
mod(e,n)/n (covering 0 to n-1/n), while 8 covers 0 to 1 with mod(e,n+1)/n.
----------------------------
New windows priority setting
----------------------------
Add new option to set render priority to background (only available on Vista
or later).
--------------------
New animation option
--------------------
Added +STP / Frame_Step= animation option inspired from megapov with two
restrictions: only positive step value are supported (forward, no backward
rendering) and the value is not available in the SDL.
-----------------------------------
New render pattern and step options
-----------------------------------
2: Closing from left & right to center, top & bottom alternatively
to middle
3: Starting at center-middle, going left & right, then to top & bottom.
4: Closing top & bottom to middle, alternatively left & right to centre.
5: Opposite of -4 (starting at middle-center).
The block step is used to work out what block to render next, as an offset
from the current block number (blocks are numbered from 0, which is the
top-left of the image). The block size is determined by the existing
render_block_size option, which defaults to 32x32 pixels. Blocks are
allocated to render threads in the order specified by the combination
of the render_pattern option and this option.
With N > 0, it's about 1 square every N (N might get reduced to allow clock
arithmetic to cover the whole picture). N must be pseudo-prime; at worst it
is shrunk to 1).
--------------
Image Metadata
--------------
Most image formats now include metadata (BMP is a notable exception). This
metadata contains the POV-Ray version, render date/time (GMT), platform
(e.g. x86_64-pc-win), and compiler used to build the POV-Ray executable.
----------------
SDL Improvements
----------------
Add new function now(), which can have a string parameter (but can also be
used without; the parenthesis are mandatory in either case). When provided
with a string, the value is used for formatting the time. Formatting
documentation is the one of strftime() C function. Without a parameter, the
format is "%Y-%m-%d %H:%M:%SZ". The time base is GMT.
-------------
Gamma Changes
-------------
Removed file_gamma keyword. Input image file default can now be set via
or
For backward compatibility with legacy scenes, POV-Ray 3.7 will now mimick
all the gamma handling of POV-Ray 3.6 if the scene has a #version statement
specifying a version of 3.6x or earlier, and/or specifies an assumed_gamma,
with the following exceptions:
* If the scene overrides the default input file gamma, POV-Ray will fall
back to the new gamma handling model.
* If the scene is rendered using the File_Gamma INI file setting, or using
an INI file setting or command-line option to specify a version of 3.7 or
later, input file gamma handling will still mimick 3.6 behaviour, but
output file gamma handling will use the new model.
* For PNG files carrying both an sRGB chunk and a fitting gAMA chunk,
results will slightly differ. (This is due to POV-Ray 3.7 recognizing sRGB
chunks, which POV-Ray 3.6 did not do.)
* For PNG files carrying an sRGB chunk but no gAMA chunk (or a wrong one),
backward compatibility is not provided. (Again this is due to POV-Ray 3.7
recognizing sRGB chunks.)
------------------
Misc Fixes/Changes
------------------
Fixed divide-by-zero crash in editor support code (refer crash report #50).
Updated support for file-backed RGBFT images to allow 64-bit seek offsets,
and added code to automatically switch to using file-backed intermediate
images when width >= 32 and pixel count >= 1024*1024. This will significantly
reduce memory usage for large renders, at the cost of more I/O overhead.
Fixed issue where a shutdown after a render that allocated a lot of memory
blocks (or any other case where the shutdown takes more than five seconds)
could throw an uncaught exception. This could then cause the 'terminated in
an unusual way' windows error message.
--------------------------------------------
Changes between 3.7.beta.38 and 3.7.beta.39
--------------------------------------------
----------
Bugs fixed
----------
- Fixed some dormant photons code that, was broken with radiosity change #4761
- Fixed a parser issue related to the obsolete "max_intersections" keyword.
- A shellout fix.
------------
New Features
------------
---------------------------------------------------------------------------------
Mesh Camera
---------------------------------------------------------------------------------
The mesh projection is a special camera type that allows complete control of
the ray origin and direction for each pixel of the output image. The basic
concept is to associate pixels with faces defined within a mesh or mesh2
object. The mesh need not be instantiated in the scene, though it can be, and
doing so can lead to some interesting uses, such as texture baking or
illumination calculations.
In its simplest form, each pixel of the output image is assigned to a face of
the mesh according to (width * (int) y) + (int) x, however, more complex
mapping is possible via multiple meshes and multiple rays per pixel. The type
of mapping in use is determined by the distribution type parameter in the
camera declaration. Except for mapping #3, the ray origin will be set to the
centroid of the face, and the direction will be that of the face's normal. For
mapping #3, barycentric co-ordinates are determined from the UV co-ordinates of
the first face to match the X and Y position, and those are then converted to a
position on the face which will serve as the ray origin. Support is provided to
move the origin off the face along the normal, and to reverse the ray
direction.
For most of the distribution methods, any POV feature that causes sub-pixel
positioning to be used for shooting rays (e.g. anti-aliasing or jitter) will
not do anything useful, because X and Y are converted to integers for indexing
purposes. At this time, no warning is issued if anti-aliasing or jitter is
requested when rendering a non-applicable distribution; this may be added
later.
camera {
mesh_camera {
rays per pixel
distribution type
[max distance]
mesh {
MESH_OBJECT_IDENTIFIER
[TRANSFORMATIONS]
}
[mesh ...]
}
[location]
[direction]
[smooth]
}
This float parameter controls the number of rays that will be shot for each
pixel in the output image. Each distribution allows different values, but the
minimum is always 1.
Distribution Type
-----------------
This float parameter controls how pixels are assigned to faces as documented
below:
* distribution #0
This method allows single or multiple rays per pixel, with the ray number
for that pixel allocated to each mesh in turn. The index into the meshes is
the
ray number, where rays per pixel is greater than one, and the index into the
selected mesh is the pixel number within the output image. If there is no
face
at that pixel position, the resulting output pixel is unaffected.
You must supply at least as many meshes as rays per pixel. Each pixel is
shot rays per pixel times, and the results averaged. Any ray that does not
correspond with a face (i.e. the pixel number is greater than or equal to the
face count) does not affect the resulting pixel color. Generally, it would be
expected that the number of faces in each mesh is the same, but this is not a
requirement. Keep in mind that a ray that is not associated with a face is
not
the same thing as a ray that is but that, when shot, hits nothing. The latter
* distribution #1
This method allows both multiple rays per pixel and summing of meshes, in
other
words the faces of all the supplied meshes are logically summed together as
if
they were one single mesh. In this mode, if you specify more than one ray per
pixel, the second ray for a given pixel will go to the face at (width *
height
* ray_number) + pixel_number, where ray_number is the count of rays shot into
a
specific pixel. If the calculated face index exceeds the total number of
faces
for all the meshes, no ray is shot.
The primary use for this summing method is convenience in generation of the
meshes, as some modelers slow down to an irritating extent with very large
meshes. Using distribution #1 allows these to be split up.
* distribution #2
In this mode, you can (currently) only have a single ray per pixel.
* distribution #3
This method will reverse-map the face from the UV co-ordinates. Currently,
only
a single ray per pixel is supported, however, unlike the preceding methods,
standard AA and jitter will work. This method is particularly useful for
texture baking and resolution-independent mesh cameras, but requires that the
If used for texture baking, the generated image may have visible seams when
applied back to the mesh, this can be mitigated. Also, depending on the way
the
original UV map was set up, using AA may produce incorrect pixels on the
outside edge of the generated maps.
Max Distance
------------
The primary use for this parameter is to allow a mesh camera to 'probe' a scene
in order to determine whether or not a given location contains a visible
object. Two examples would be a camera that divides the scene into slices for
use in 3d printing or to generate an STL file, and a camera that divides the
scene into cubes to generate voxel information. In both cases, some external
means of processing the generated image into a useful form would be required.
Mesh Object
-----------
One or more mesh or mesh2 objects to be used for the camera. These will be
treated differently depending on the distribution method, as explained above.
Transformations on the meshes can be used here, and will reflect on the
resulting image as it would be expected for a regular camera.
Location
--------
With this special camera, location doesn't affect where the camera is placed
per se (that information is on the mesh object itself), but is used to move the
origin of the ray off the face, along the normal of that face. This would
typically be done for texture baking or illumination calculation scenes where
the camera mesh is also instantiated into the scene, usually only a tiny amount
of displacement is needed. The X and Y for location is not currently used, and
the Z always refers to the normal of the face, rather than the real Z direction
in the scene.
Direction
---------
Like location, this doesn't correspond to the real direction vector of the
camera. It serves only to reverse the normal of all the faces, if necessary. If
the Z component is less than -EPSILON, then the rays will be shot in the
opposite direction than they would otherwise have been. X and Y are not used.
Smooth
------
This optional parameter is only useful with distribution #3, and will cause the
ray direction to be interpolated according to the same rules as are applied to
smooth triangles. For this to work, the mesh must have provided a normal for
each vertex.
---------------------------------------------------------------------------------
Added support for focal blur with user-defined bokeh, using the following syntax:
camera {
// ... focal blur camera...
bokeh {
pigment { ... }
}
}
If bokeh is specified, focal blur will use a custom sampling sequence based
on the specified pigment's brightness in the range <0,0,0> to <1,1,0>, i.e.
the unit square in the XY plane.
---------------------------------------------------------------------------------
Introduced new framework for internal random number generators, intended for
reducing the memory footprint (by sharing precomputed values among
generators with identical parameters) as well as easier replacement of
implementations.
---------------------------------------------------------------------------------
------------
Improvements
------------
Radiosity improvements:
- Removed the max 1600 count limit; if the count exceeds 1600, POV-Ray will
now use a Halton sequence instead of the built-in sequence.
where IMPORTANCE is a value in the range from >0.0 to <=1.0 specifying the
percentage of rays to actually compute on average. A particular ray will
only be fully computed if it is within the first COUNT*IMPORTANCE rays of
the sampling sequence; due to the low-discrepancy sub-random nature of the
sequence, this is mostly equivalent to a per-ray weighted random choice,
while maintaining a low-discrepancy uniform distribution on a per-object
basis. Rays actually computed are weighted to compensate for those
not computed.
---------------------------------------------------------------------------------
- Extra samples are now generated from a halton sequence rather than a
random stream.
---------------------------------------------------------------------------------
SSLT improvements:
---------------------------------------------------------------------------------
------------
Misc Changes
------------
--------------------------------------------
Changes between 3.7.beta.37 and 3.7.beta.38
--------------------------------------------
----------
Bugs fixed
----------
Fixed an issue with SSLT that could cause rendering threads to hang
Fix crash reported in http://news.povray.org/4bd949b3@news.povray.org
Fixed error in windows version expiry test causing timeout message from 1 July.
Fixed UV mapping for bezier spline lathe.
--------------------------
Changes to Windows version
--------------------------
Default output file type is now PNG (SYS format is still mapped to BMP though).
----------------------------------------
Gamma and color-handling related changes
----------------------------------------
Partial fix for broken alpha channel output; v3.6 behavior is now reproduced
exactly (including bugs), regardless of version. Further changes will address
the premultiplied-alpha issue (which was already handled wrong in 3.6) and
possibly add options for use cases where v3.6 behavior might be undesired.
-----
For bump_map and image_pattern, images with alpha channel are treated as if
they had a black background (unless the alpha channel itself is used).
-----
- TGA and BMP 32-bit RGBA (an inofficial extension to BMP) will use
straight alpha, retaining file input compatibility for now, until a final
decision has been made on these formats.
When used with file formats for which alpha output is currently not
supported by POV-Ray (or only via an inofficial extension, as with BMP),
turning on alpha output via Output_Alpha=on or +UA will now generate a
warning.
-----
-----
-----
COLOR_BODY:
COLOR_VECTOR [GAMMA] |
COLOR_KEYWORD_GROUP |
COLOR_IDENTIFIER [GAMMA]
...
COLOR_KEYWORD_ITEM:
COLOR_IDENTIFIER |
red Red_Amount |
blue Blue_Amount |
green Green_Amount |
filter Filter_Amount |
transmit Transmit_Amount |
GAMMA
GAMMA:
gamma Gamma_Value |
gamma srgb
Likewise, specifying "gamma srgb" indicates that the colour components are
gamma-precorrected using the sRGB transfer function (being roughly, but not
quite, equivalent to a Gamma_Value of 2.2).
Note that gamma is NOT an additional component, but rather modifies the
interpretation of the other colour keywords. For instance, the following
statements are all fully equivalent:
Also note that specifying gamma does not affect the filter or transmit
components.
-----
-----
Added support for using the sRGB transfer function for output file gamma;
syntax is "File_Gamma=sRGB". ("SRGB" and "srgb" are supported as well.)
Note: When "File_Gamma=sRGB" is used with PNG output file format, POV-Ray
writes an sRGB chunk, thereby claiming that the output conforms to the sRGB
color space; however, this claim is not necessarily true, as POV-Ray is
currently not color space aware; it depends on whether your scene input data
conforms to the sRGB color space.
NB: The other gamma INI file parameters (Antialias_Gamma and DisplayGamma)
do NOT support the "sRGB" value at present.
------------
Misc Changes
------------
Add special handling for INI lines that are shell-out commands and re-implement
support for shellouts.
Using filter in a sky_sphere with layered pigments now has the same effect
as in a large sphere with a multi-layered texture. (For compatibility with
legacy scenes, specifying a #version < 3.70 will revert to the old, poorly
specified behavior.)
Using Output_Alpha=on with legacy scenes (#version < 3.70) will now
suppress sky spheres and background except in reflections, for backward
compatibility with v3.6.
When specifying an input image in SDL without a file type (neither via type
keyword nor via extension), parser would not fall back to system default
(broken since change #4932); fixed.
When specifying an IFF input image in SDL, POV-Ray would instead attempt to
read it as a TIFF file; should be fixed (not that anybody would probably care
these days...).
Some code pertaining to histogram output was not updated with change #4932;
fixed. (no symptoms there, as histogram output is presently out of order
anyway)
Validity check for Grayscale_Output setting was broken with change #4932;
fixed.
-----------------
Radiosity Changes
-----------------
POV-Ray will now create only one set of threads for the whole pretrace,
instead of one set for each pretrace step; likewise, progress report will
pertain to the whole pretrace rather than each step; POV-Ray will no longer
wait for a pretrace step to be fully completed, and instead assign threads to
the next step as soon as all blocks of the previous step are either finished
or already assigned.
-----
Parser now checks for plausible relation between radiosity minimum_reuse and
maximum_reuse:
------------------------------
Other SDL Changes/Enhancements
------------------------------
Added #elseif statement; the #if, #ifdef and #ifndef directives syntax is
changed as follows:
IF_DIRECTIVE:
#if ( Cond ) TOKENS... [ELSE_DIRECTIVE] #end
IFDEF_DIRECTIVE:
#ifdef ( IDENTIFIER ) TOKENS... [ELSE_DIRECTIVE] #end
IFNDEF_DIRECTIVE:
#ifndef ( IDENTIFIER ) TOKENS... [ELSE_DIRECTIVE] #end
ELSE_DIRECTIVE:
#else TOKENS... |
#elseif ( Cond ) TOKENS... [ELSE_DIRECTIVE]
Example:
#if (Foo)
#debug "Foo is true\n"
#elseif (Bar)
#debug "Foo is false, but Bar is true\n"
#else
#debug "Foo and Bar are both false\n"
#end
-----
Added "emission" parameter to the finish block; syntax and effect are
virtually identicall to "ambient", except that "emission" is unaffected by
the global "ambient_light" parameter, which will now effectively be set to 0
if radiosity is active (except in legacy scenes having #version set to < 3.70).
--------------------------------------------
Changes between 3.7.beta.35 and 3.7.beta.37
--------------------------------------------
Photon changes
--------------
Radiosity changes
-----------------
When a new sample has been gathered after sample lookup returned insufficient
samples, sample lookup is no longer run again; instead, the new sample is
interpolated with the results of the earlier lookup.
New features
------------
AOI Pattern:
Implemented AOI pattern (thanks to Grimbert Jerome for most of the code);
the syntax is as follows:
The pattern gives a value proportional to the angle between the ray and the
surface; for consistency with the slope pattern, values range from 0.5 where
ray is tangent to the suftace, to 1.0 where perpendicular; in practice,
values below 0.5 may occur in conjunction with smooth triangles or meshes.
(Note that this differs from the current MegaPOV implementation, where the
values
range from 0.5 down to 0.0 instead.)
(Note that this variant currently does *not* allow for the "altitude" keyword
to be used.)
desired);
#local R = seed(4711);
#for (I, 1, 100)
#if (rand(R) < I/1000)
#break // terminate loop early
#end
#debug concat(str(I,0,0), " iterations and counting\n")
#end
Where multiple #switch, loop and/or #macro blocks are nested, #break will
leave only the innermost of these.
is now available for simple loops incrementing Identifier from Start to End
(inclusive) with the given Step size (default: +1.0). Basically, it works the
"countdown" pattern.
macros are effectively global); inside the loop, any tampering with the
variable is possible for effect, as long as it is defined as a local
numeric
variable at the end of each iteration.
- After the loop has terminated, the variable will remain defined,
typically
holding the value End+Step.
Image file output now uses the GammaCurve mechanism already in use for
image file input, to allow for arbitrary transfer functions (e.g. as used by
sRGB) in the future.
Radiance HDR image output no longer writes the proprietary GAMMA header field.
PPM image output now supports 16-bit greyscale output (effectively writing a
PGM file instead), to be activated via the "Greyscale_Output=on" option or
the "+FPg" file type switch.
--------------------------------------------
Changes between 3.7.beta.35 and 3.7.beta.35a
--------------------------------------------
-------------------------------------------
Changes between 3.7.beta.34 and 3.7.beta.35
-------------------------------------------
Subsurface light transport code should now properly handle light attenuation
due to distance, spotlight falloff or intervening non-opaque objects
(including media and projected_through objects). Diffuse ambient illumination
is also supported to some extent (multiple-scattering term only) when
radiosity is turned on (however, it does not actually call radiosity code at
present).
Various bug fixes and minor improvements in input file reading code.
Added "out-of-the-box" transparency support for GIF files.
Added support for PNG sRGB chunks.
NOTE: Non-legacy scene default gamma handling for image input files has
changed significantly from previous betas, affecting all file formats except
OpenEXR, Radiance HDR and (with minor differences) most flavors of PNG; there
will be NO corresponding warnings. See below for more detail.
---------------------------------------------------
Changes to improve input image file gamma handling.
---------------------------------------------------
Input image files not carrying unambiguous gamma information will now be
assumed to match a common gamma setting, and gamma-adjusted accordingly; this
common input file gamma setting can be specified in the scene file using the
following syntax:
global_settings {
file_gamma GAMMA
}
where GAMMA is either a numeric expression specifying the approximate display
gamma for which input files are assumed to be gamma pre-corrected, or the
keyword 'srgb' indicating that input files are assumed to match the sRGB
standard. (In the latter case, gamma adjustment is applied according to the
sRGB standard, instead of approximating with a gamma 2.2 power-law function.)
The default setting is sRGB.
Default gamma handling rules for any image input file can be overridden by
specifying 'file_gamma GAMMA" immediately after the file name, e.g.:
image_map {
jpeg "foobar.jpg" file_gamma 1.8
interpolate 2
}
This also applies to contexts where gamma adjustment is not normally applied,
e.g. file formats that are defined to be encoded linearly, or files used in
height fields, to simplify handling of files not conforming to standards.
NOTE: Gamma handling for PNG input files has changed as follows in legacy
('#version 3.6') scenes:
- PNG files with an sRGB chunk but no gAMA chunk may appear significantly
different than with POV-Ray 3.6.
- PNG files may generally appear slightly different than with POV-Ray 3.6.
-------------------------------------------
Changes between 3.7.beta.33 and 3.7.beta.34
-------------------------------------------
The following .ini file / command line options control whether pretrace
performs all computations so it can double-feature as a coarse preview
("vain pretrace"):
Note that with vain pretrace off, preview will look remarkably odd during
the radiosity pretrace phase; this is normal, and no reason to be alarmed.
At the moment, turning vain pretrace off will affect only classic lighting
computations (diffuse lighting, higlights and iridescence); other features
expendable during pretrace may follow in future versions.
-------------------------------------------
Changes between 3.7.beta.32 and 3.7.beta.33
-------------------------------------------
Improved support for image output to stdout/stderr for supported file types.
This does not implement progressive output - the image is only written after the
render completes. Progressive output will be added in a later beta. Also, don't
fclose stream if it's stdout, stderr or stdin, which fixes some issues with using
stdout for animations. Also adds support for image output to stderr.
Optimized the way imageProcessing handles creating new images; this should reduce
the chance of an out-of-memory error when rendering with image output enabled.
Added support for file-backed RGBFT image container; this is used for
intermediate
image storage if allocating a memory-backed one fails. This ought to
significantly
reduce "out of memory"-type errors, particularly "cannot allocate intermediate
image
storage". This implementation is basic in that it doesn't support large files
(anything
more than what fseek/fwrite etc can handle) and only buffers a single line. A
better
solution to the intermediate image storage issue is to go away from using an
image
container and cache the render blocks on disk instead, using a class that can
stream
fully-completed rows to the image output code (required for writing to stdout to
work
properly again).
NOTE: The parameter names are preliminary, and may still be subject to change;
there is
a potential conflict between the shorthand forms)
If both +RFI and +RFO are specified, new samples gathered are appended;
otherwise, +RFO
causes the file to be overwritten if it exists.
New samples gathered are written whenever an SMP block is completed. Tests
indicate
that this is almost neutral regarding performance, compared to operation with
radiosity
file output disabled.
New radiosity "high reproducibility" mode: when specifying "High_Reproducibility"
or "+HR"
on the command line, POV-Ray will spend extra effort to make sure renders are
deterministic
despite SMP (currently, radiosity is the only code to use this flag; in HR mode,
radiosity
pretrace starts out with fewer threads, and some extra rules are imposed on
sample re-use
that may cause surplus samples to be gathered).
-------------------------------------------
Changes between 3.7.beta.31 and 3.7.beta.32
-------------------------------------------
Fixed bug creating artifacts in output file when mosaic preview is used with +EP2
and -A.
Added radiosity octree performance stats and fixed stats for max trace level &
parse time.
-------------
Binary #write
-------------
Keywords ending in "be" will cause the values to be written most significant
byte first ("big endian", aka network byte order) while those ending in "le"
will instead write the least significant byte first ("little endian", Intel
format).
---------------------------------
Subsurface Light Transport (SSLT)
---------------------------------
Beta 31 adds experimental support for subsurface light transport (aka subsurface
scattering).
mm_per_unit NUMBER
To tune the algorithm for quality or performance, the number of samples for the
diffuse
scattering and single-scattering approximation, respectively, can be specified by
placing
the following statement in the global_settings section:
-------------------------------------------
Changes between 3.7.beta.29 and 3.7.beta.31
-------------------------------------------
Implemented filename display in console warning and error message output where
name is supplied from core code.
Changed windows progress panel to auto-size render progress bar such that it
will either fit in remaining status panel space, or not be shown at all. This
ought to resolve several reported issues where it overlaid the panel text.
Fixed bug that caused wrong radiosity illumination on transformed mapped textures.
Fixed Windows install issue where shortcut to SSE2 binary was always used even
if system didn't have SSE2.
-------------------------------------------
Changes between 3.7.beta.28 and 3.7.beta.29
-------------------------------------------
Allow POVWIN 'save as' to succeed without 'file is already open in editor'
error if case of current file is being changed.
Improved detection of true number of logical and physical cores on Intel CPU's.
Added colored text output to POVWIN message window. warning and debug messages
get different colors than error messages and standard text.
Many updates to scene and include files (see revision.txt for more details).
Worked around issue where new (for 3.7) crackle hash function returns large
range of possible values, causing memory used by cache to grow quickly. Work-
around is to revert to old hash function (this may also make crackle faster
since now we will get more cache hits).
Changed POVWIN UCS2 handling so that ASCII codes > 127 but < 256 are able to
be used. This should solve the issue reported in <48c04138$1@news.povray.org>.
Deprecation Support
-------------------
The ability to add a 'deprecated' flag to a #declare has been added. This is
to aid in migrating scenes away from old constructs (e.g. old textures). The
usage is illustrated below:
-------------------------------------------
Changes between 3.7.beta.27 and 3.7.beta.28
-------------------------------------------
Fixed 'white outlines in df3 patterns with interpolate 2' issue reported in
<483d2920@news.povray.org>.
Fixed bounding box calculation flaw that caused in some cases major slow-downs
in scenes using difference (e.g. abyss.pov).
Re-implemented light color cache for textures. without this, each subsequent
layer (after the first) in a multi-layered texture will cause an unnecessary
call to TraceShadowRay and its subsequent intersection test to determine the
light color at that point.
Improvements to Windows installer: now asks if install is for one user or all
users, and sets default install dir to suit. Note: it would be nice to detect
if a user has Administrator permissions prior to showing this option, but
unfortunately - at least on Vista - the windows installer engine intentionally
provides false information about the privileges of the user. This will lead to
non-privileged Vista users being offered the opportunity to do a global install
which of course will fail (presuming they accept the default destination). The
workaround for this (setting a property) causes the opposite problem: all users
get tagged as not having Administrator permissions, even if UAC elevation would
have granted it during install.
-------------------------------------------
Changes between 3.7.beta.26 and 3.7.beta.27
-------------------------------------------
Fixed incorrect flag test which would have resulted in issues with cutaway
textures and CSG or objects with double_illuminate set.
Added support for specifying grayscale output via INI file or command-line.
This is intended to replace the use of hf_gray_16 in global_settings.
hf_gray_16, if encountered, has no effect on the output type and will
additionally generate a warning message (as before).
Currently only PNG file support is provided with grayscale output; others
will be added over time.
Caveat: grayscale output implies the maximum bit-depth the format supports;
for PNG this is 16. it is not valid to specify bits per color channel with
'g' (e.g. '+Fng16' is not allowed, and nor for that matter is '+Fn16g'). If
bits per channel is provided via an INI option, it is ignored.
Fixed issue whereby manual bounds, clips, patterns, UV, and interior were left
behind when a transformation was applied to a CSG object.
Changed back to using pvengine.ini to store POVWIN options and improved the
code that migrates version 3.6 options (if present) to 3.7. NOTE: not all
options from the v3.6 pvengine.ini are migrated: this is intentional and may
change later (it mainly involves options that contained pathnames).
Further split the POVWIN install and data dirs - this moves the ini, scenes,
and insert menu directories to the user's Application Data folder, for example,
c:\Documents and Settings\<user name>\Application Data\POV-Ray\v3.7\.
Created a Windows Installer which takes care of setting up the above for Win32
systems. Win64 is pending. NOTE: the installer currently only installs for the
user who ran it: that is, the 'Application Data\POV-Ray\v3.7\...' files are
only installed for that user. This won't be the case with the final installer;
it will set things up such that when pvengine.exe is run for the first time by
a user who has not had the program set up for them, the appropriate files are
created in their Application Data directory (this is a Windows Installer feature).
-------------------------------------------
Changes between 3.7.beta.25 and 3.7.beta.26
-------------------------------------------
Workaround for race condition that would cause 'timed out waiting for worker
thread' error.
-------------------------------------------
Changes between 3.7.beta.24 and 3.7.beta.25
-------------------------------------------
Windows: moved all settings that used to be in PVENGINE.INI into the registry.
This means that all PVENGINE settings (not to be confused with editor settings,
which were already in the registry) will revert to their defaults. PVENGINE.INI
is no longer used by POV-Ray 3.7.
Windows: moved the location of PVTOOLS.INI into the user profile folder: e.g.
C:\Documents and Settings\<user>\Application Data\POV-Ray for
Windows\pvtools.ini
This change only alters the location that POV-Ray for Windows looks for the
tools file - it does *not* automatically copy it. This is because of course
when 3.7 is finally distributed, the installer will put the file in the
correct place. If you use pvtools.ini, please manually copy it as above (the
destination folder will be created the first time the new beta runs).
Linux: add auto setting of thread count and rework --benchmark. The number of
threads is now set as the number of detected CPUs, or 4 otherwise. The built-in
benchmark now accepts +Lpath command-line options and does no longer read any
INI file but the provided one.
Fixed an issue where irid, ground fog, and constant fog were using noise generator
0 rather than the default generator.
-------------------------------------------
Changes between 3.7.beta.23 and 3.7.beta.24
-------------------------------------------
-------------------------------------------
Changes between 3.7.beta.22 and 3.7.beta.23
-------------------------------------------
--------------------------------------------
Changes between 3.7.beta.20b and 3.7.beta.22
--------------------------------------------
Added 'alternate render file' feature to povwin IDE. See comments below.
Added extensions .MCR and .MAC to list of files povwin considers include
files (i.e. which are filtered as such in the various file dialogs and
assigned the POV file type for the editor syntax highlighting).
Added .INI file type to povwin editor syntax highlighting.
Added window menu to povwin IDE. Entries are MRU-sorted.
Activated memory statistics code in Windows build.
Fixed issue with editor window splitting not being restored
(<45620b9e$1@news.povray.org>).
Fixed issue with file type not being set on initial save if 'save as'
was not used (reported many times, including <45602a08@news.povray.org>
and <46092c8a@news.povray.org>).
Currently, the MRU list is not saved on exit. This will be added.
We may also add keyboard accelerators (e.g. ALT-2, ALT-3 etc) as
a shortcut for Alt-W 2, etc.
For this feature to work, you need to have rendered a file which
includes the target file during the current editing session (the
association between include files and source files is not persisted when
POVWIN exits). Additionally you need to have requested to render a
source file which does not have the .POV or .INI extension. When you
request the render, a message box will appear asking you what to do. You
can choose to render the alternate file this time only, to render the
alternate file each time you render this one, or to render this one each
time (i.e. disable the alternate file option).
In all cases, the choice you give only persists for the current editing
session; it is not restored when you re-launch POVWIN. This is by
design.
Added preliminary Linux support for CPU timer; might return incorrect results
depending on the platform.
Added preliminary Linux support for signal catching (e.g. when aborting a
render by hitting Ctrl+C).
Fixed the +p option under Linux to trigger an interframe pause in animations.
Fixed unrestricted display and file gamma; must now be at least 0.001.
Fixed PNG gamma issue reported in <45aa976e$1@news.povray.org> and
<45c11eed$1@news.povray.org>.
Fixed uv mapping issue reported in <45602a08@news.povray.org> and
<46092c8a@news.povray.org>.
Fixed Winpov issue with editor window splitting not being restored
reported in <45620b9e$1@news.povray.org>.
Fixed Winpov issue with file type not being set on initial save if 'save as'
was not used (reported many times, including <45602a08@news.povray.org>
and <46092c8a@news.povray.org>).
Fixed exit code for the Linux build; now 0 = ok, 1 = error, 2 = user abort.
Tweaked a few scene files.
Improved w3c conformance and keyword index for the Linux docs.
Real-Time Raytracing
--------------------
POV-Ray now has some highly experimental support for a real-time raytracing
loop. This is basically a mode where a single pre-parsed scene is rendered
multiple times with no re-parsing inbetween frames. The camera is moved
according to camera definitions provided in the main scene file. Additionally,
on windows, a live video stream (e.g. from a webcam) may be mapped into the
image in exactly the same way that a normal image map may be.
Photon Changes
--------------
We are re-working some areas of the photon support, and as such photons will
not work as well as in the previous beta.
Alpha Changes
-------------
Some changes have been made to the way alpha is handled when +UA is activated.
Firstly, in previous versions, specifying a background with the background
keyword would by default supply a background with transmit set to 1.0 (i.e.
fully transparent provided that +ua is being used). This is no longer the case.
Secondly, the way that objects are blended with the background has changed.
Previously the color of the background was not taken into account when
calculating effects of transmission through translucent objects when +ua is
in effect (i.e. where the background could otherwise have been seen through
the object). Now, however, the background color is taken into account, even
if it is not otherwise visible. (In other words, blending is performed in the
same way regardless of the presence of background transparency).
Note that this change is not affected by the #version directive, so it may
change the appearance of scenes written for version 3.6 and earlier. We will
monitor feedback on this from beta testers to evaluate the impact of this.
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.
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.
BSP Bounding
------------
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).
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 Haines'
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.
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).
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).
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.
(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.
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).
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.
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.
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.
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.
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.
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
---------
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.
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.
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.
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.