Chris Cason wrote:
> Beta 32 for Windows (32 and 64-bit) is now available at:
> 
>   http://www.povray.org/beta/
> 
> Source code will be updated in due course. Linux users will need to wait a
> few days, sorry :)
> 
> -------------------------------------------
> Changes between 3.7.beta.31 and 3.7.beta.32
> -------------------------------------------
> 
> Added ARRAYS_WriteDF3 macro to arrays.inc for writing an array to a df3 file.
> 
> Fixed bug creating artifacts in output file when mosaic preview is used
> with +EP2 and -A.
> 
> Several Unix build fixes.
> 
> Added radiosity octree performance stats and fixed stats for max trace
> level & parse time.
> 
> Made some improvements to performance in crackle cache, and optimised the
> management of the crackle cache size by setting limits in megabytes
> (currently per-thread and not user-settable: this will change).
> 	
> -------------
> Binary #write
> -------------
> 
> It is now possible to write 8, 16 and 32-bit words to an external file.
> These words may be arranged in either little or big-endian fashion.
> 
> Placing one of the following keywords in the argument list of a #write
> statement causes the values up to the next comma to be written in binary
> format, using 2's complement integer representation, rounded to the nearest
> integer in the representable range:
> 
>   uint8              - unsigned byte (0..255)
>   sint8              - signed byte (-128..127)
>   uint16be, uint16le - unsigned 16-bit word (0..65535)
>   sint16be, sint16le - signed 16-bit word (-32768..32767)
>   sint32be, sint32le - signed 32-bit word (-2^31..2^31-1)
> 
> As of now, unsigned 32-bit words are not supported.
> 
> 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).
> 
> The values to be written in binary must be numbers or vectors; the latter
> will be written component by component as specified, in the standard x-y-z
> order, without any separating or enclosing characters.
> 
> There is a sample macro called 'ARRAYS_WriteDF3' in arrays.inc which shows
> how this feature may be used.
> 
> ---------------------------------
> Subsurface Light Transport (SSLT)
> ---------------------------------
> 
> Beta 32 adds experimental support for subsurface light transport (aka
> subsurface scattering).
> 	
> Currently, SSLT is activated for a particular object by adding the
> following statement to its finish (note that this is very likely to change):
> 	
>   subsurface { COLOR, COLOR }
> 	
> specifying the (reduced) scattering coefficients (sigma'[s]) and absorption
> coefficients (sigma[a]), respectively, in units of 1/mm, for each of the
> three basic colors. The object's IOR will also affect the results.
> 	
> The algorithm is designed to give realistic results at a scale of 10 mm per
> POV-Ray unit by default; for other scales, place the following statement in
> the global_settings section:
> 	
>   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:
> 	
>   subsurface { samples NUMBER, NUMBER }
> 
> There is a sample SSLT scene in scenes/subsurface/subsurface.pov.
> 
> SSLT is still in alpha stage.
> 

OK... so, playing around with SSLT, it looks like radiosity does not 
currently interact with the the scattering? Is that correct? Neat 
feature, nonetheless, it's going to cost me a significant amount of time.


-- 
~Mike

Post a reply to this message