 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 01.10.2018 um 00:06 schrieb Jim Holsenback:
> for default pigment just a brief /change/ annotation:
> http://wiki.povray.org/content/Reference:Pigment
Just to make sure we're on the same page here: The behaviour you
presumably copy-and-pasted there from ambient is /not/ the way v3.8 will
eventually behave.
> i created a talk page for the rest:
> http://wiki.povray.org/content/Reference_Talk:Version_Directive
...
> in the 1st paragraph after the syntax at the sentence... As with version
> 3.8 or later... things kind of fell apart for me. what you had written
> just didn't make any sense so that was the best i could do. please
> review and edit on the talk page.
See there. I hope the complete rephrasing clarifies things.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/30/18 7:47 PM, clipka wrote:
> Am 01.10.2018 um 00:06 schrieb Jim Holsenback:
>
>> for default pigment just a brief /change/ annotation:
>> http://wiki.povray.org/content/Reference:Pigment
>
> Just to make sure we're on the same page here: The behaviour you
> presumably copy-and-pasted there from ambient is /not/ the way v3.8 will
> eventually behave.
...as long as no explicit #default directive statement is specified????
>
>
>> i created a talk page for the rest:
>> http://wiki.povray.org/content/Reference_Talk:Version_Directive
> ...
>> in the 1st paragraph after the syntax at the sentence... As with version
>> 3.8 or later... things kind of fell apart for me. what you had written
>> just didn't make any sense so that was the best i could do. please
>> review and edit on the talk page.
>
> See there. I hope the complete rephrasing clarifies things.
>
yep... i going to merge that over to reference
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 01.10.2018 um 02:11 schrieb Jim Holsenback:
> On 9/30/18 7:47 PM, clipka wrote:
>> Am 01.10.2018 um 00:06 schrieb Jim Holsenback:
>>
>>> for default pigment just a brief /change/ annotation:
>>> http://wiki.povray.org/content/Reference:Pigment
>>
>> Just to make sure we're on the same page here: The behaviour you
>> presumably copy-and-pasted there from ambient is /not/ the way v3.8 will
>> eventually behave.
>
> ....as long as no explicit #default directive statement is specified????
Sorry, I guess it wasn't clear what exactly I was referring to; this is
about the `#version` interaction.
The text currently reads "When #version is set as either the VERY first
statement of the scene file or via command-line option and the version
is 3.8 or greater ..."
As correctly explained on the `#verison` page, thanks to the recent
overhaul it will no longer be necessary to have a `#version 3.8` as the
VERY first statement to get the changed default; unfortunately the
overhauled behaviour is more complex, and maybe the easiest and least
disruptive way to solve this is just to phrase it something like this:
"The default pigment has been {{Change}}d in version 3.8 from `rgb
<0,0,0>` to `rgb <1,1,1>` (requires `#version 3.8` or equivalent INI
setting or command-line option; see [Version Directive] for more details)."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 01.10.2018 um 02:45 schrieb clipka:
> The text currently reads "When #version is set as either the VERY first
> statement of the scene file or via command-line option and the version
> is 3.8 or greater ..."
(Just for the records, The wording /can/ be interpreted to be correct:
If you don't specify `#version` as the VERY first statement with SOME
value, you can't set it to 3.8 later, and thus can't switch to the new
defaults. And the new defaults are enabled if the version is 3.8 or
greater at SOME particular point. But I guess that's not how most people
would understand it.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 01/10/2018 01:55, clipka wrote:
> Am 01.10.2018 um 02:45 schrieb clipka:
>
>> The text currently reads "When #version is set as either the VERY first
>> statement of the scene file or via command-line option and the version
>> is 3.8 or greater ..."
>
> (Just for the records, The wording /can/ be interpreted to be correct:
> If you don't specify `#version` as the VERY first statement with SOME
> value, you can't set it to 3.8 later, and thus can't switch to the new
> defaults. And the new defaults are enabled if the version is 3.8 or
> greater at SOME particular point. But I guess that's not how most people
> would understand it.)
>
Is there a functional or technical reason that you are implementing
this? It will make things harder for me using my modeller as I can only
change the Pov version from the default (3.6) after the default version
has been declared in the .pov file.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 01.10.2018 um 11:22 schrieb Stephen:
> On 01/10/2018 01:55, clipka wrote:
>> Am 01.10.2018 um 02:45 schrieb clipka:
>>
>>> The text currently reads "When #version is set as either the VERY first
>>> statement of the scene file or via command-line option and the version
>>> is 3.8 or greater ..."
>>
>> (Just for the records, The wording /can/ be interpreted to be correct:
>> If you don't specify `#version` as the VERY first statement with SOME
>> value, you can't set it to 3.8 later, and thus can't switch to the new
>> defaults. And the new defaults are enabled if the version is 3.8 or
>> greater at SOME particular point. But I guess that's not how most people
>> would understand it.)
>>
>
> Is there a functional or technical reason that you are implementing
> this? It will make things harder for me using my modeller as I can only
> change the Pov version from the default (3.6) after the default version
> has been declared in the .pov file.
Wait, what?
Ok, let me clarify:
The text on the Wiki currently reads as quoted above (unless Jim has
already found time to change it).
This CAN be interpreted as:
"To get the new defaults, the VERY first statement in the scene file
must be `#version 3.8` [...]"
And as a matter of fact that's how it was(!) implemented in earlier
v3.7.1 / v3.8.0 pre-releases, and why it was worded like that.
However, the implementation has recently been changed; now the statement
in the wiki can only be considered correct (and only technically so) if
interpreted as:
"To get the new defaults, the VERY first statement in the scene file
must be `#version <whatever>` [...], and it needs to be set to 3.8
eventually.`
To make it completely clear, the updated requirements to get the new
defaults are as follows:
(1) Start the scene with ANY odd `#version` statement. (Not a primary
requirement, but you can't switch to `#version 3.8` otherwise.)
(2) Switch to `#version 3.8` before the `pigment`/`finish`/`camera`
statements that are supposed to be based on the new defaults. (You'll
get v3.7 defaults otherwise.)
(3) Make sure you have switched to `#version 3.8` before any `default`
statement. (`#version` will cease to auto-switch defaults after you have
specified defaults manually, for reasons that I guess are self-evident.)
And here's the same from the implementation point of view:
(A) Defaults are initially set up according to the `Version` INI setting
or equivalent command-line option; if absent, v3.7 [or, technically more
exact, v3.62] defaults are used.
(B) Any `#version` statement changes the defaults accordingly [unless
rule (C) has kicked in].
(C) Any `default` statement prevents all subsequent `#version`
statements from changing the defaults.
(D) If rule (C) has kicked in, any `#version` statement that would
otherwise change the defaults will generate a warning instead.
Plus, unrelated:
(X) If a `#version` statement in the main scene file tries to set the
version to 3.8 or higher, and the first statement was not a `#version`
statement, generate an error.
So unless your modeller is throwing you some additional curveball, I
think you should be fine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/30/18 8:45 PM, clipka wrote:
> "The default pigment has been {{Change}}d in version 3.8 from `rgb
> <0,0,0>` to `rgb <1,1,1>` (requires `#version 3.8` or equivalent INI
> setting or command-line option; see [Version Directive] for more details)."
it's been fixed in pigment and a couple of other places...look here for
all the places i touched:
http://wiki.povray.org/content?title=Special:RecentChanges&hidebots=0
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/1/18 9:24 AM, clipka wrote:
> The text on the Wiki currently reads as quoted above (unless Jim has
> already found time to change it).
yep it's been changed
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 02.10.2018 um 00:41 schrieb Jim Holsenback:
> On 9/30/18 8:45 PM, clipka wrote:
>> "The default pigment has been {{Change}}d in version 3.8 from `rgb
>> <0,0,0>` to `rgb <1,1,1>` (requires `#version 3.8` or equivalent INI
>> setting or command-line option; see [Version Directive] for more
>> details)."
>
> it's been fixed in pigment and a couple of other places...look here for
> all the places i touched:
> http://wiki.povray.org/content?title=Special:RecentChanges&hidebots=0
Looks good.
Just one more thing regardig the "Version Directive" section,
specifically the portion giving example code for the version 3.8
defaults behaviour:
The revised presentation of the example code gives it the air of three
separate examples, but that's not how it was intended; rather, it was
designed as a single example, intended to demonstrate how the `#version`
directive can (or cannot) switch back and forth between defaults.
As a matter of fact, the third portion of the example wouldn't have the
described effect if used stand-alone - even if the `#default` statement
was moved from the end of the 2nd portion to the beginning of the 3rd one.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> > Isn't like a mid-grey the accepted graphics "standard" for "nothing".
>
> Mid-grey is certainly /one/ standard, but it is not the only one - white
> being another (e.g. the default material for geometric primitives in DAZ
> studio).
>
> White has the decided advantage over mid-grey in that it is well-defined
> in terms of gamma: White is always white.
>
> Also, with `diffuse` defaulting to a value below 1.0, it is effectively
> not pearly white.
Also prediction of tint is easier with 1 as multiplier than with anything else,
plus, it provides one less value shift in the case of bitmapped textured
finishes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
