|
|
clipka <ano### [at] anonymousorg> wrote:
> > This changes your scene's version number to 3.5, *if* you leave out
> > a #version directive in your scene...
>
> Actually pretty much the very opposite happens.
>
> The standard include files (including `colors.inc`) have the following
> structure:
>
> #ifndef(Foo_Inc_Temp)
> #declare Foo_Inc_Temp = version;
> #version 3.5; // typical; value may differ
> ...
> #version Foo_Inc_Temp;
> #end
>
> This structure is designed to reset the effective language version back
> to whatever it was before the include file.
Yep, I do understand that; but I didn't understand why the ending #version
statement was NOT changing it back (in the case when there was no #version
number in the scene file itself.) My only guess was, for some reason or other
the #version 'compatibility' was staying at 3.5. (Or maybe 3.62, as you
mentioned?) I didn't know how to explain that in detail :-)
BTW, I was running the examples in v3.7.1 beta 9, but adding #version 3.7 into
the scene instead (or not, to see the difference.) Just tried the scene using
#version 3.71 (or not); same behavior that I described. The other 'variable' was
assumed_gamma 1.0. Adding it to the scene -- even without a #version number--
fixed all the problems (no change in the gray color or gamma behavior, with or
without "colors.inc.") I think I understand that: The example code uses gradient
-z... which by default is using 'linear' rgb values... which agrees with
'linear' assumed_gamma 1.0 no matter what.
Post a reply to this message
|
|