Take a look at the scene I attached.

Look for the line:

#declare camera_eye = -1; // -1 = no eye, 0 = left eye, 1 = right eye

Render the scene. Then change the above variable to 0 or 1 and render 
the scene again.

Why are the colors so different between the two renders?


Mike

Post a reply to this message

Attachments:
Download 'ldr_androbot_mech_new_stereoscopic_test.pov.txt' (583 KB)

Am 24.01.2016 um 13:15 schrieb Mike Horvath:

> Why are the colors so different between the two renders?

Because you're not paying attention to the parse warnings ;)

------ (camera_eye=-1)
Parse Warning: assumed_gamma not specified, so gamma_correction is
turned off for compatibility with this pre POV-Ray 3.7 scene. See the
documentation for more details.
Parse Warning: This scene did not contain a #version directive. Please
be aware that as of POV-Ray 3.7, unless already specified via an INI
option, a #version is expected as the first declaration in a scene file.
POV-Ray may apply settings to some features that are
intended to maintain compatibility with pre-3.7 scenes. You are strongly
encouraged to add a #version statement to the scene to make your intent
clear. Future versions of POV-Ray may make the presence of a #version
statement mandatory.
------

In other words: Your scene has no "#version" statement at all => POV-Ray
now presumes a legacy scene, so you get 3.6 gamma handling defaults
(which is no gamma handling).


------ (camera_eye=0)
Possible Parse Error: assumed_gamma not specified in this POV-Ray 3.7 or
later scene. Future versions of POV-Ray may consider this a fatal error.
To avoid this warning, explicitly specify 'assumed_gamma 1.0' in the
global_settings section. See the documentation for
more details.
Parse Warning: This scene had other declarations preceding the first
#version directive. Please be aware that as of POV-Ray 3.7, unless
already specified via an INI option, a #version is expected as the first
declaration in a scene file. If this is not done, POV-Ray
may apply compatibility settings to some features that are intended to
make pre-3.7 scenes render as designed. You are strongly encouraged to
add a #version statement to the scene to make your intent clear. Future
versions of POV-Ray may make the presence of a
#version mandatory.
------

In other words: Your scene has a belated "#version 3.7" statement => you
get 3.7 gamma handling defaults (which is "assumed_gamma 1.0").


"But where does this '#version 3.7' statement come from?" you might ask.

The secret lies in the inclusion of "transforms.inc", which you only
pull in for camera_eye=0 or 1:

As is customary for library include files, it does specify its own
"#version" statement, so that future versions of POV-Ray may invoke
backward compatibility mode for that paticular file in case they
introduce some breaking changes to functionality. However, in order to
not break the main scene's "#version" choice, it needs to revert the
change at the end of the file; this is done using the following
construct (which also acts as a guard against double inclusion):

    #ifndef(FOO_INC_TEMP)
    #declare FOO_INC_TEMP = version;
    #version 3.5; // for example

    // include file content goes here

    #version FOO_INC_TEMP
    #end

Enter a quirk of the version handling as of version 3.7: As you can
infer from the warning you get, as long as you don't specify a
"#version" directive the /effective/ SDL version will be 3.6, because we
presume that anything without a "#version" statement is a legacy scene.
*But* the "version" pseudo-variable will return 3.7 (or whatever is the
actual version of the POV-Ray binary you are running) in this case.

This is to allow scenes to have "#version" as their very first statement
(which is officially a mandatory requirement for 3.7 and later scenes),
but still be able to adapt to the actual version used, by employing a
construct like the following:

    #version version;
    #if (version >= 3.70)
      #version 3.7; // use 3.7 features if we can have them
      #declare Subsurface_On = yes;
    #else
      #version 3.6; // need at least 3.6
      #declare Subsurface_On = yes;
    #endif

Thus, if you don't explicitly specify a "#version" directive, you'll get
3.6 behaviour by default, but including any standard include file will
effectively set "#version 3.7" at the end of that include.

Post a reply to this message

On 1/24/2016 10:52 AM, clipka wrote:
> Am 24.01.2016 um 13:15 schrieb Mike Horvath:
>
>> Why are the colors so different between the two renders?
>
> Because you're not paying attention to the parse warnings ;)
>
> ------ (camera_eye=-1)
> Parse Warning: assumed_gamma not specified, so gamma_correction is
> turned off for compatibility with this pre POV-Ray 3.7 scene. See the
> documentation for more details.
> Parse Warning: This scene did not contain a #version directive. Please
> be aware that as of POV-Ray 3.7, unless already specified via an INI
> option, a #version is expected as the first declaration in a scene file.
> POV-Ray may apply settings to some features that are
> intended to maintain compatibility with pre-3.7 scenes. You are strongly
> encouraged to add a #version statement to the scene to make your intent
> clear. Future versions of POV-Ray may make the presence of a #version
> statement mandatory.
> ------
>
> In other words: Your scene has no "#version" statement at all => POV-Ray
> now presumes a legacy scene, so you get 3.6 gamma handling defaults
> (which is no gamma handling).
>
>
> ------ (camera_eye=0)
> Possible Parse Error: assumed_gamma not specified in this POV-Ray 3.7 or
> later scene. Future versions of POV-Ray may consider this a fatal error.
> To avoid this warning, explicitly specify 'assumed_gamma 1.0' in the
> global_settings section. See the documentation for
> more details.
> Parse Warning: This scene had other declarations preceding the first
> #version directive. Please be aware that as of POV-Ray 3.7, unless
> already specified via an INI option, a #version is expected as the first
> declaration in a scene file. If this is not done, POV-Ray
> may apply compatibility settings to some features that are intended to
> make pre-3.7 scenes render as designed. You are strongly encouraged to
> add a #version statement to the scene to make your intent clear. Future
> versions of POV-Ray may make the presence of a
> #version mandatory.
> ------
>
> In other words: Your scene has a belated "#version 3.7" statement => you
> get 3.7 gamma handling defaults (which is "assumed_gamma 1.0").
>
>
> "But where does this '#version 3.7' statement come from?" you might ask.
>
> The secret lies in the inclusion of "transforms.inc", which you only
> pull in for camera_eye=0 or 1:
>
> As is customary for library include files, it does specify its own
> "#version" statement, so that future versions of POV-Ray may invoke
> backward compatibility mode for that paticular file in case they
> introduce some breaking changes to functionality. However, in order to
> not break the main scene's "#version" choice, it needs to revert the
> change at the end of the file; this is done using the following
> construct (which also acts as a guard against double inclusion):
>
>      #ifndef(FOO_INC_TEMP)
>      #declare FOO_INC_TEMP = version;
>      #version 3.5; // for example
>
>      // include file content goes here
>
>      #version FOO_INC_TEMP
>      #end
>
> Enter a quirk of the version handling as of version 3.7: As you can
> infer from the warning you get, as long as you don't specify a
> "#version" directive the /effective/ SDL version will be 3.6, because we
> presume that anything without a "#version" statement is a legacy scene.
> *But* the "version" pseudo-variable will return 3.7 (or whatever is the
> actual version of the POV-Ray binary you are running) in this case.
>
> This is to allow scenes to have "#version" as their very first statement
> (which is officially a mandatory requirement for 3.7 and later scenes),
> but still be able to adapt to the actual version used, by employing a
> construct like the following:
>
>      #version version;
>      #if (version >= 3.70)
>        #version 3.7; // use 3.7 features if we can have them
>        #declare Subsurface_On = yes;
>      #else
>        #version 3.6; // need at least 3.6
>        #declare Subsurface_On = yes;
>      #endif
>
> Thus, if you don't explicitly specify a "#version" directive, you'll get
> 3.6 behaviour by default, but including any standard include file will
> effectively set "#version 3.7" at the end of that include.
>

Thanks for clearing this up! The file was created using an LDraw to 
POV-Ray converter. For some reason they bundle the program along with 
POV-Ray 3.7 even though issues like these can easily arise. I will 
forward this information along to the group.


Mike

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>
> .... However, in order to
> not break the main scene's "#version" choice, it needs to revert the
> change at the end of the file; this is done using the following
> construct (which also acts as a guard against double inclusion):
>
>     #ifndef(FOO_INC_TEMP)
>     #declare FOO_INC_TEMP = version;
>     #version 3.5; // for example
>
>     // include file content goes here
>
>     #version FOO_INC_TEMP
>     #end
>

Thanks for that. It's the best explanation I've seen for why that code is
placed at the beginning and end of all built-in #include files. I have to admit
that I've never fully understood the code's full purpose until now.

The way that the #version directive is described in the documentation may have
been part of the reason why I didn't fully grasp it.  The docs give this
example...

#local Temp_Vers = version;  // Save previous value
#version 1.0;              // Change to 1.0 mode
..... // Version 1.0 stuff goes here...
#version Temp_Vers;        // Restore previous version

IMO, the comment "Save previous value" (or version) in that first line should
instead say, "Save current version", as that is what is really meant there.  (I
do now realize that, when including an #include file in a scene, the SCENE's
#version would be the meaning of "previous value"-- but it's a little bit
confusing, when read 'out of context' in the docs there.)

A question out of curiosity (and using your #include file example above of the
variable name #ifndef(FOO_INC_TEMP) : Is the reason for using such 'odd'
variable names in #include files (of which some *are* rather odd) so that the
chances of it being an *actual* variable name in a scene file are very low? In
other words, are they purposely odd so that they won't be confused with other
scene file variables that we would normally think to use? OR does it matter at
all? (as #include files use #local variables, not #declared ones)

By the way, in the 3.7 documentation concerning #version for SCENE use, it says
(in error?), "Naturally the default setting for this option is #version 3.5."
Should that say 3.62 now?

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> A question out of curiosity (and using your #include file example above of the
> variable name #ifndef(FOO_INC_TEMP) : Is the reason for using such 'odd'
> variable names in #include files (of which some *are* rather odd) so that the
> chances of it being an *actual* variable name in a scene file are very low? In
> other words, are they purposely odd so that they won't be confused with other
> scene file variables that we would normally think to use? OR does it matter at
> all? (as #include files use #local variables, not #declared ones)

Yes, that's exactly the rationale behind the variable name. This is of
particular importance if the include file use "#declare" instead of "#local",
which some files do (and actually all files should, unless they are supposed to
be included multiple times) to detect whether they have been included before.

> By the way, in the 3.7 documentation concerning #version for SCENE use, it says
> (in error?), "Naturally the default setting for this option is #version 3.5."
> Should that say 3.62 now?

Looks like that portion of the docs is very much outdated.

Post a reply to this message