POV-Ray : Newsgroups : povray.general : Beta 33 Server Time
27 Nov 2024 00:50:35 EST (-0500)
  Beta 33 (Message 1 to 7 of 7)  
From: Chris Cason
Subject: Beta 33
Date: 21 Jun 2009 21:15:30
Message: <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).


Post a reply to this message

From: Tim Attwood
Subject: Re: Beta 33
Date: 22 Jun 2009 01:25:19
Message: <4a3f15bf$1@news.povray.org>
"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.

Nice! Everything major is fixed! =)


Post a reply to this message

From: Dre
Subject: Re: Beta 33
Date: 23 Jun 2009 02:16:52
Message: <4a407354@news.povray.org>
"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

From: Tim Attwood
Subject: Re: Beta 33
Date: 23 Jun 2009 07:01:53
Message: <4a40b621$1@news.povray.org>
> Hi, does this version still have a use by date?  Ie will it stop working 
> after a certain date?
Beta 33 has an expire date of August 1, but it will continue 
to function with a warning message.


Post a reply to this message

From: Dre
Subject: Re: Beta 33
Date: 23 Jun 2009 21:39:38
Message: <4a4183da@news.povray.org>
"Tim Attwood" <tim### [at] anti-spamcomcastnet> wrote in message 
news:4a40b621$1@news.povray.org...
>> Hi, does this version still have a use by date?  Ie will it stop working 
>> after a certain date?
> Beta 33 has an expire date of August 1, but it will continue to function 
> with a warning message.

Thanks for letting me know.

Pita as I'll pass again then, I dont like things that time out/warn...

Cheers Dre


Post a reply to this message

From: gregjohn
Subject: Re: Beta 33
Date: 26 Jun 2009 12:05:01
Message: <web.4a44f0cd49615c3130bf98980@news.povray.org>
Isn't it a shame that povray development is dead?


Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> -------------------------------------------
> Changes between 3.7.beta.32 and 3.7.beta.33
>  -------------------------------------------
>
>   Fixed following bugs:
>..
>   Improved support for image output...
>   Optimized the way imageProcessing ...
>   Added support for file-backed RGBFT...
>   Added some more radiosity stats ...
>   Fixed ARRAYS_WriteDF3 macro ...
>   Added no_radiosity keyword...
>   Revival of Radiosity Load/Save...
>   New radiosity "high reproducibility"...


Post a reply to this message

From: clipka
Subject: Re: Beta 33
Date: 26 Jun 2009 12:55:01
Message: <web.4a44fd1449615c31a745f7570@news.povray.org>
"gregjohn" <pte### [at] yahoocom> wrote:
> Isn't it a shame that povray development is dead?

Dead as in "dead and kicking", huh? :P


Post a reply to this message

From: Nyoho
Subject: Re: Beta 33
Date: 1 Jul 2009 05:15:01
Message: <web.4a4b27f249615c31edc148970@news.povray.org>
> Linux and windows source code will follow shortly.

I would like to get the source code of beta 33 for unix.
But I couldn't find that "Getting the POV-Ray Unix/Linux source" in
http://www.povray.org/beta/source/.
(Beta 32 is there but no beta 33)
Has not the source of beta 33 been downloadable yet?


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.