|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] 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.
> - 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
|
|
| |
| |
|
|
|
|
| |
|
|