Christian Froeschlin wrote:
> I finally got around to downloading a beta (3.7b24, Windows version).
> First time I tried it, so just my stupid-average-user observations here.
> Not complaining about anything, it's working fine and looks stable ;)

This should probably go in the beta group (that's what its for, after 
all).  That being said,

> o It would be nice if the download ZIP contained a short README
>   listing some "major new features" as compared to 3.6.x (it is easy
>   to overlook them in the multitude of praiseworthy bug fixes), and
>   a quick note about how to best use the files in the beta ZIP to
>   get a runnable 3.7b without destroying the existing 3.6.x (what
>   I did was to create a copy of bin as "bin37b" and dump the
>   contents of the ZIP file in there).

The major new feature of 3.7b is multithreading.  There are a few others 
(improved bounding, full area light calculations for specular and 
diffuse), but most people won't notice those right away.

> o On my P4/2.6Ghz with XP, rendering some random scenes seemed to
>   take at least 2 times longer than with 3.6.1. After setting the
>   thread count from default value of 2 to 1, this improved but still
>   took at least 1.4 times longer than with 3.6.1 (even with sse2).

There is some overhead on single threaded processors; there always will 
be when writing multithreaded code.  Even so, most computers have a 
lifespan of 3-5 years, so within 2 more years almost everyone will be 
using multithreaded computers (from two to eight cores, and AMD is even 
planning a 3 core version :) ).

>   background. Or maybe default thread count = 0, interpreted
>   as automatic: thread count = number of cpus reported by OS?

There is no platform independed way to determine the number of CPUs.  As 
I understand it, under Windows the default is the number of CPUs 
reported by the OS (If you havea  Pentium 4, it's probably reporting two 
CPUs because of Hyperthreading), while under Linux the default is 2.

> o I noticed 3.7 now has support for HDR's but not the map_type 7
>   which is implemented in Mega-POV to support the omnidirectional
>   images which seem to be a typical use case for HDR's. Moreover,
>   there is no syntax error when using an unsupported map_type,
>   the image_map seems to silently revert to map_type 0.

Hmm, sounds like a bug.

> o I know about the #version directive, but is there some built-in
>   define to test the engine version using #ifdef, e.g., how could
>   you create a HDR scene which renders both in MegaPOV and 3.7?

Not that I know of; however, if you try to specify a scene to work with 
Megapov, it won't render in 3.7 without the parser complaining, and like 
wise for the reverse.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message