Am 19.09.2014 21:54, schrieb FlyerX:

> (1) The version is in the scene ini file as version=3.7 and it seems to
> work as the SSLT works which is a 3.7 exclusive feature. Is using
> #version (pov) instead of version (ini) the proper approach?

Ah, I didn't notice that, as I'm normally not using the .ini file.

I think ideally each file should specify what version it actually needs 
(see below).

As for SSLT working, that's no indicator for the version setting to be 
effective: The version setting governs backward compatibility for 
features that have undergone breaking changes (such as the different 
handling of "ambient", the treatment of transparency in sky spheres, or 
gamma-adjustment of input images), but it doesn't disable new features 
(such as the "emission" keyword in finish statements, SSLT, or the 
"srgb" keyword for specifying colours).

> I used the
> one on the ini file as it was a single entry but I can move it to the
> main pov file as a #version statement. Since the inc files could be used
> on other scenes, can #version be repeated on each file or would that
> lead to problems?

The usual approach for .inc files is to wrap the file's actual content 
in a construct such as this (presuming the file name is "foo.inc"):

   #ifndef(Foo_Inc_Temp)
   #declare Foo_Inc_Temp = version;
   #version 3.70;

   // ... (actual content) ...

   #version Foo_Inc_Temp;
   #end

This allows the .inc file to indicate that it expects a certain minimum 
version (in this case 3.7.0), and request activation of backward 
compatibility (in the scope of the .inc file) if used with a newer 
version, without disrupting version requirements and compatibility 
settings in the main scene file.

The construct also prevents the actual content from being included twice.


> I suppose gamma 1.0 is still needed for transparency
> maps. I tried a while back and I think it was giving me the wrong
> transparency unless I set the gamma to 1.0.

Yes, if you're using the following construct, then POV-Ray 3.7 will 
indeed apply an (in this case typically undesired) gamma adjustment:

   #declare TransMap = pigment { image_map { ... } }
   #declare T = texture {
     pigment_pattern { TransMap }
     texture_map {
       [0.0 MyTransTexture]
       [1.0 MyOpaqueTexture]
     }
   }

This is because POV-Ray can't know that the image_map pigment will 
actually wind up in a pigment_pattern where a linear interpretation of 
the raw image data is typically desired. (This is different for 
bump_map, where linear interpretation is the norm.)

This is indeed a perfectly legit use case for the "gamma 1.0" statement.

Post a reply to this message