 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In POV-Ray v3.8.0, default values will be chaned as follows:
- The default pigment is now plain white (rgb <1,1,1>) instead of black.
- The `ambient` setting now defaults to zero instead of 0.1.
- The camera `right` vector length now defaults to the output image
aspect ratio (presuming square pixels; for example, at 1280x1024 the
vector will have a length of 1,25) instead of 1.33. The rules governing
the direction of the vector remain unaffected.
The new defaults require that the language version is explicitly set to
3.8 or higher via the `#version` directive, the `Version=n.n` INI
setting or the `+MVn.n` command-line option, otherwise POV-Ray will fall
back to legacy defaults for backwards compatibility.
The `#version` directive can be used to switch back and forth between
the defaults, as long as no explicit `default` statement is specified.
However, as soon as the first `default` statement is encountered, any
subsequent `#version` directives that would normally affect the defaults
will instead just cause a warning.
For example, consider the following scene:
#version 3.7;
#declare LegacyTexture = texture { ... }
#version 3.8;
#declare ModernTexture = texture { ... }
default { pigment { color rgb <1,0,0> } }
#version 3.7;
#declare OtherTexture = texture { ... }
The first `#version` directive switches to v3.7 defaults, so if
`LegacyTexture` does not explicitly specify an ambient value, it will
have an ambient value of 0.1.
The second `#version` directive switches to v3.8 defaults, so if
`ModernTexture` does not explicitly specify an ambient value, it will
have an ambient value of zero.
The thirst `#version` directive just creates a warning, because the
earlier `default` statement has "locked" the v3.8 defaults (overriding
the pigment in the process)., so if `OtherTexture` does not explicitly
specify an ambient value, it will also have an ambient value of zero.
---------------------------------------------------------------------
Notes NOT intended for the docs:
- The current v3.8.0-alpha releases do not yet allow switching back and
forth between defaults after the first `#version` statement; this will
be changed in the next development releases.
- As soon as that behaviour is released, users may experience lots of
warnings regarding `#version` and `default` in standard include files.
This is to be expected for any v3.8 scenes that place a `default`
statement before the standard include files, and will be fixed later
(probably with the first beta) by changes to the standard include files.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> In POV-Ray v3.8.0, default values will be chaned as follows:
>
> - The `ambient` setting now defaults to zero instead of 0.1.
Great! Nice and consistent with the other newer finish defaults.
> - The default pigment is now plain white (rgb <1,1,1>) instead of black.
I''m curious about the reason for this change. (Personally, it will take some
getting used to.) Is it perhaps due in some philosophical way to the change of
#default ambient to 0.0 (where pure shadows would now be pure black instead of
'lit' with ambient 0.1? Meaning, it would be hard to discern a previously
un-pigmented object-- black until now-- from it's now-black shadow duo to
ambient 0.0?)
>
> - The camera `right` vector length now defaults to the output image
> aspect ratio (presuming square pixels; for example, at 1280x1024 the
> vector will have a length of 1,25) instead of 1.33. The rules governing
> the direction of the vector remain unaffected.
>
I don't usually mess with right x*image_width/image_height, and run
different aspect-ratio images simply by choosing another entry in quickres.ini.
(1280X720 instead of 800X600, for example.) Will this change affect the visual
result of the render (in some *strange* way), if I continue to use my simple
scheme? Sorry if my question seems naive, but it's not clear if my quickres.ini
entries would also need changing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 20.09.2018 um 22:19 schrieb Kenneth:
> clipka <ano### [at] anonymousorg> wrote:
>> In POV-Ray v3.8.0, default values will be chaned as follows:
>>
>> - The `ambient` setting now defaults to zero instead of 0.1.
>
> Great! Nice and consistent with the other newer finish defaults.
Um... what other newer finish defaults?
>> - The default pigment is now plain white (rgb <1,1,1>) instead of black.
>
> I''m curious about the reason for this change. (Personally, it will take some
> getting used to.) Is it perhaps due in some philosophical way to the change of
> #default ambient to 0.0 (where pure shadows would now be pure black instead of
> 'lit' with ambient 0.1? Meaning, it would be hard to discern a previously
> un-pigmented object-- black until now-- from it's now-black shadow duo to
> ambient 0.0?)
Since ambient is also multiplied with pigment, traditional default was
pitch-black and thus invisible.
The rationale is simply that hey, the default of pitch black is of no
practical use /at all/ - white, on the other hand, eliminates one of the
N things that you have to do to see /anything/ at all. Those used to be:
(1) Place at least one object in your scene.
(2) Place your camera somewhere outside the object.
(3) Aim your camera at the object.
(4) Place a light source somewhere reasonable outside the object.
(5) Give your object a pigment that isn't pitch black.
(Alternatively to (5), you could also (5a) Set up a background or sky
sphere that isn't pitch black, but that isn't nearly as satisfying.)
With white default pigment, we're only left with steps (1)-(4) for a new
user to produce their first remotely satisfying image.
Also, white makes for nice images if you're really just interested in shape.
>> - The camera `right` vector length now defaults to the output image
>> aspect ratio (presuming square pixels; for example, at 1280x1024 the
>> vector will have a length of 1,25) instead of 1.33. The rules governing
>> the direction of the vector remain unaffected.
>>
>
> I don't usually mess with right x*image_width/image_height, and run
> different aspect-ratio images simply by choosing another entry in quickres.ini.
> (1280X720 instead of 800X600, for example.) Will this change affect the visual
> result of the render (in some *strange* way), if I continue to use my simple
> scheme? Sorry if my question seems naive, but it's not clear if my quickres.ini
> entries would also need changing.
Presuming that by "I don't usually mess with..." you mean "I usually
use..." (as opposed to e.g. "I don't even try to use..."), there's no
need to worry.
First of all, as long as you explicitly specify a "right" vector,
nothing changes at all. User-specified "right" wins over default, as
previously.
And second, "right x*image_width/image_height" is in fact exactly what
the new default boils down to.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/20/2018 05:47 PM, clipka wrote:
> Am 20.09.2018 um 22:19 schrieb Kenneth:
>
> Also, white makes for nice images if you're really just interested in shape.
Isn't like a mid-grey the accepted graphics "standard" for "nothing".
> First of all, as long as you explicitly specify a "right" vector,
> nothing changes at all. User-specified "right" wins over default, as
> previously.
The quickres.ini he mentions does not have "Right" as an attribute (just
Width, Height, and Antialias foo). So 1280x720 *will* look different
then he has previously seen. It will be more correct :) but it will be
different.
>
> And second, "right x*image_width/image_height" is in fact exactly what
> the new default boils down to.
>
--
dik
Rendered 1024 of 921600 pixels (0%)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/20/2018 06:43 PM, dick balaska wrote:
>
> The quickres.ini he mentions does not have "Right" as an attribute (just
> Width, Height, and Antialias foo). So 1280x720 *will* look different
> then he has previously seen. It will be more correct :) but it will be
> different.
That was a dumb statement. There is no camera in quickres, so there
couldn't be a "right".
--
dik
Rendered 1024 of 921600 pixels (0%)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 20.09.2018 um 22:19 schrieb Kenneth:
> > I don't usually mess with right x*image_width/image_height...
>
> Presuming that by "I don't usually mess with..." you mean "I usually
> use..." (as opposed to e.g. "I don't even try to use..."), there's no
> need to worry.
>
Yeah, that's the case-- I always specify right... in a camera, but almost always
leave it alone (at the default.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/20/2018 8:00 PM, Kenneth wrote:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 20.09.2018 um 22:19 schrieb Kenneth:
>
>>> I don't usually mess with right x*image_width/image_height...
>>
>> Presuming that by "I don't usually mess with..." you mean "I usually
>> use..." (as opposed to e.g. "I don't even try to use..."), there's no
>> need to worry.
>>
>
> Yeah, that's the case-- I always specify right... in a camera, but almost always
> leave it alone (at the default.)
>
>
By specifying `right` you are not using any defaults at all. The
defaults only come into play when you *don't* specify `right`.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 21.09.2018 um 00:43 schrieb dick balaska:
> On 09/20/2018 05:47 PM, clipka wrote:
>> Am 20.09.2018 um 22:19 schrieb Kenneth:
>
>>
>> Also, white makes for nice images if you're really just interested in shape.
>
> 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.
> The quickres.ini he mentions does not have "Right" as an attribute (just
> Width, Height, and Antialias foo). So 1280x720 *will* look different
> then he has previously seen. It will be more correct :) but it will be
> different.
It will be more correct for people who don't use the `right
x*image_width/image_height` idiom. Which is pretty much the point of it ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 21.09.2018 um 02:21 schrieb Mike Horvath:
> On 9/20/2018 8:00 PM, Kenneth wrote:
>> clipka <ano### [at] anonymousorg> wrote:
>>> Am 20.09.2018 um 22:19 schrieb Kenneth:
>>
>>>> I don't usually mess with right x*image_width/image_height...
>>>
>>> Presuming that by "I don't usually mess with..." you mean "I usually
>>> use..." (as opposed to e.g. "I don't even try to use..."), there's no
>>> need to worry.
>>>
>>
>> Yeah, that's the case-- I always specify right... in a camera, but
>> almost always
>> leave it alone (at the default.)
>>
>>
>
> By specifying `right` you are not using any defaults at all. The
> defaults only come into play when you *don't* specify `right`.
Absolutely right.
(Irresistible.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Horvath <mik### [at] gmailcom> wrote:
>
> By specifying `right` you are not using any defaults at all. The
> defaults only come into play when you *don't* specify `right`.
>
Oh. I actually had to look that up in the docs-- it's been ages since I read
those sections. (I rarely if ever think about right, up etc). Just to clarify, I
always use AND specify
right x*image_width/image_height
Honestly, I thought that was the default(!). But I see that 4/3*x or <1.33,0,0>
is the real one. I can't recall when I started using one vs. the other-- it
was in the dim and murky past!
Thanks for the clarification.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 21.09.2018 um 13:24 schrieb Kenneth:
> right x*image_width/image_height
>
> Honestly, I thought that was the default(!).
Well, it is now ;)
> But I see that 4/3*x or <1.33,0,0>
> is the real one.
The latter actually. Which means that by default the aspect ratio wasn't
even really fitting for classic 4:3 images.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/19/18 4:46 PM, clipka wrote:
> In POV-Ray v3.8.0, default values will be chaned as follows:
haven't started on this yet...a quick glance was all i did for now but i
/think/ i've already done some of them. i'm burnt so give me a bit
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.09.2018 um 00:40 schrieb Jim Holsenback:
> On 9/19/18 4:46 PM, clipka wrote:
>> In POV-Ray v3.8.0, default values will be chaned as follows:
>
> haven't started on this yet...a quick glance was all i did for now but i
> /think/ i've already done some of them. i'm burnt so give me a bit
The new `ambient` and camera defaults are indeed already doc'd, so it's
a matter of finding a good place to document the new pigment colour (the
old default of pitch black doesn't seem to be explicitly mentioned) and
to overhaul the behaviour of the `#version` statement with respect to
the defaults.
Nothing too urgent I think, so no pressure.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/22/18 8:14 PM, clipka wrote:
> Am 23.09.2018 um 00:40 schrieb Jim Holsenback:
>> On 9/19/18 4:46 PM, clipka wrote:
>>> In POV-Ray v3.8.0, default values will be chaned as follows:
>>
>> haven't started on this yet...a quick glance was all i did for now but i
>> /think/ i've already done some of them. i'm burnt so give me a bit
>
> The new `ambient` and camera defaults are indeed already doc'd, so it's
> a matter of finding a good place to document the new pigment colour (the
> old default of pitch black doesn't seem to be explicitly mentioned) and
> to overhaul the behaviour of the `#version` statement with respect to
> the defaults.
>
> Nothing too urgent I think, so no pressure.
>
for default pigment just a brief /change/ annotation:
http://wiki.povray.org/content/Reference:Pigment
i created a talk page for the rest:
http://wiki.povray.org/content/Reference_Talk:Version_Directive
i cleaned up the intro paragraph. after the syntax diagram i grouped the
expanded discussions together. followed by examples.
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] anonymousorg> 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
|
|
| |
| |
|
|
|
|
| |
