"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:4a3edb32@news.povray.org...
> Windows binaries for POV-Ray 3.7 beta 33 are now available from
> http://www.povray.org/beta/. Linux and windows source code will follow 
> shortly.
>
> -------------------------------------------
> Changes between 3.7.beta.32 and 3.7.beta.33
> -------------------------------------------
>
>  Fixed following bugs:
>    http://bugs.povray.org/task/13 (4k files crash in Windows 64-bit 
> editor)
>    http://bugs.povray.org/task/14 (coincident transparency issue)
>    http://bugs.povray.org/task/15 (julia fractal, trace and inside cause 
> crash)
>    http://bugs.povray.org/task/16 (reflective texture map crash)
>    http://bugs.povray.org/task/17 (square blotches in transparency)
>    http://bugs.povray.org/task/21 (unix scripts have wrong version set)
>    http://bugs.povray.org/task/24 (isosurface, bounding box & threads)
>    http://bugs.povray.org/task/31 (function pattern in image map)
>    http://bugs.povray.org/task/32 (tiff file extension error)
>    http://bugs.povray.org/task/33 (parse accepting invalid vector 
> components)
>    http://bugs.povray.org/task/34 (could not link against boost_thread)
>
>  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).
>
>  Added some more radiosity stats for performance tweaking
>
>  On unix, drop support for --with-boost-src configure option.
>  Note: with this change, the libraries/ folder is no longer distributed.
>  Also get rid of --disable-vsnprintf-check and unimplemented SVGA support
>  (--with-svga).
>
>  Fixed ARRAYS_WriteDF3 macro (16-bit depth output and parse warning).
>
>  Added no_radiosity keyword, as known from MegaPOV:
>    Specifying "no_radiosity" in an object block makes that object 
> invisible to
>    radiosity rays, in the same way as "no_image", "no_reflection" and
>    "no_shadow" make an object invisible to primary, reflected and shadow 
> test
>    rays, respectively.
>
>  Revival of Radiosity Load/Save + various other radiosity code changes:
>
>    The following .ini / command line parameters are recognized:
>
>      Radiosity_File_Name=<name>" or "+RF<name>" to set the cache file 
> name;
>      Radiosity_From_File=<on/off>" or "+RFI" to enable reading the 
> radiosity
>        file at startup
>      Radiosity_To_File=<on/off>" or "+RFO" to enable writing new samples 
> to the
>        radiosity file
>
>    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).
>

Hi, does this version still have a use by date?  Ie will it stop working 
after a certain date?

Cheers Dre

Post a reply to this message