Chambers wrote:

> This should probably go in the beta group

Oops ... sorry, didn't notice that one, redirecting follow-ups.

>> 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)
>
> 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.

yes, that's why I suggested the list, to see what's of interest
in the new version for people which don't need the threading ;)

>> 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).
 >> Furthermore, I think the thread count in the Windows GUI
 >> should persist.
> 
> There is some overhead on single threaded processors; there always
> will be when writing multithreaded code.  

Well, not *that* much overhead. Warp mentioned compiler problems
on the Windows version, is this a known open issue? Has anyone else
checked rendering speed with 3.7b24 on a P4 running Windows XP?
I know everything will be dualcore in a few years but today
it shouldn't yet be such an uncommon system ;)

 >> 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.

ok, I now checked this with 3.6.1 and it also accepts any value
for map_type so this parser problem is not specific to the beta.
Just a minor pitfall when adapting MegaPOV HDR scenes to 3.7.
Otherwise, of course, no one enters undocumented values ;)

 >> can 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.

I succeeded using the built-in version variable:

#if (version < 3.7)
#version unofficial megapov 1.2;
#end

Post a reply to this message

Christian Froeschlin wrote:
>  >> 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.
>
> ok, I now checked this with 3.6.1 and it also accepts any value
> for map_type so this parser problem is not specific to the beta.
> Just a minor pitfall when adapting MegaPOV HDR scenes to 3.7.
> Otherwise, of course, no one enters undocumented values ;)

You could also use spherical mapping (map_type 1) for your probes - use
something like HDRShop to apply panoramic transformation from Light Probe
(Angular map) to Latitude-Longitude map. Then you can freely switch between
versions. I do agree that it would be nice to support both!


>  >> can 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.
>
> I succeeded using the built-in version variable:
>
> #if (version < 3.7)
> #version unofficial megapov 1.2;
> #end

Nice trick, I'll have to try that when I get home! If combined with spherical
mapping (above) then you could have a portable scene file.


- sooperFoX

Post a reply to this message

>> I succeeded using the built-in version variable:
>>
>> #if (version < 3.7)
>> #version unofficial megapov 1.2;
>> #end
> 
> Nice trick, I'll have to try that when I get home! If combined with spherical
> mapping (above) then you could have a portable scene file.

If POV-Ray 4.0 will be GPL, I expect more forks to show up, and this 
problem would appear more often.

How about a feature_supported("HDR"), instead of comparing version 
numbers? :D

Post a reply to this message