 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.09.2018 um 00:26 schrieb Jim Holsenback:
> please review:
>
> http://wiki.povray.org/content/Reference:Tracing_Options#Anti-Aliasing_Options
My thoughts on it:
Stochastic Seed:
- Typo: "Set's a value" should read "Sets a value".
Sampling Methods Synopsis:
- Excellent! Love this mini section!
Details, Type 1:
- The section states that "the adaptive non-recursive method is the
default". I would suggest adding "if anti-aliasing is enabled" or
something along those lines, because the "out of the box" default is no
anti-aliasing at all.
- It may or may not be worth also considering an optional alpha channel
in the formula given (but see further below).
Details, Type 3:
- The formula for the actual maximum number of rays per pixel is
literally written as "4^n" (four-caret-n), rather than using proper
superscript notation. Not sure if this is an oversight or technical
necessity. In the latter case, maybe Unicode character U+207F would be
an alternative to genuine superscript.
- The word "moire" in "moire pattern" lacks an accent.
Common section:
- The common section ("With all methods..."), as currently written,
implies that the `Jitter` setting affects all anti-aliasing modes; that
is incorrect: Anti-aliasing mode 3 always uses a constant amount of
jitter. I would suggest to use something like the following wording instead:
----------------------------------------------------------
Another way to reduce anti-aliasing artifacts is to introduce noise into
the sampling process. This is called jittering and works because the
human visual system is much more forgiving to noise than it is to
regular patterns, and is inherent in anti-aliasing mode 3. When using
one of the other methods, the location of the super-samples is also
jittered or wiggled a tiny amount jittering by default, but may be
turned off with the Jitter=off option or -J option, or the amount of
jittering can be set with the Jitter_Amount=n.n option. When using
switches the jitter scale may be specified after the +Jn.n option. For
example +J0.5 uses half the normal jitter. The default amount of 1.0 is
the maximum jitter which will insure that all super-samples remain
inside the original pixel.
-----------------------------------------------------------
Additional noteworthy information:
- It may be worth noting that if the image contains an alpha channel,
that channel will also be considered in the comparisons, pretty much
like the colour channels, except that unlike the other channels it is
not subject to `Antialias_Gamma`.
> besides the am3 additions i also did some general cleanup and added a
> few visual cues to help better separate the method detail descriptions
Would it make sense to use sub-headings instead of just bold text?
Also, I guess it might be useful to add another visual cue between the
type 3 description and the subsequent description of common features.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/22/18 7:39 PM, clipka wrote:
> Am 23.09.2018 um 00:26 schrieb Jim Holsenback:
>
>> please review:
>>
>> http://wiki.povray.org/content/Reference:Tracing_Options#Anti-Aliasing_Options
>
> My thoughts on it:
>
>
> Stochastic Seed:
>
> - Typo: "Set's a value" should read "Sets a value".
oops
>
> Sampling Methods Synopsis:
>
> - Excellent! Love this mini section!
at least it's better than the run-on sentence that used to be there
>
> Details, Type 1:
>
> - The section states that "the adaptive non-recursive method is the
> default". I would suggest adding "if anti-aliasing is enabled" or
> something along those lines, because the "out of the box" default is no
> anti-aliasing at all.
yep
>
> - It may or may not be worth also considering an optional alpha channel
> in the formula given (but see further below).
if you /really/ think it's worth it help me out a bit...i /did/ do
something near the end of common as there was already a +ag discussion
going on... it seemed to fit.
>
> Details, Type 3:
>
> - The formula for the actual maximum number of rays per pixel is
> literally written as "4^n" (four-caret-n), rather than using proper
> superscript notation. Not sure if this is an oversight or technical
> necessity. In the latter case, maybe Unicode character U+207F would be
> an alternative to genuine superscript.
the hex equivalent was too small... 4<sup>n</sup> looked slightly better.
>
> - The word "moire" in "moire pattern" lacks an accent.
found the hex version used elsewhere on the page
>
> Common section:
>
> - The common section ("With all methods..."), as currently written,
> implies that the `Jitter` setting affects all anti-aliasing modes; that
> is incorrect: Anti-aliasing mode 3 always uses a constant amount of
> jitter. I would suggest to use something like the following wording instead:
>
> ----------------------------------------------------------
> Another way to reduce anti-aliasing artifacts is to introduce noise into
> the sampling process. This is called jittering and works because the
> human visual system is much more forgiving to noise than it is to
> regular patterns, and is inherent in anti-aliasing mode 3. When using
> one of the other methods, the location of the super-samples is also
> jittered or wiggled a tiny amount jittering by default, but may be
> turned off with the Jitter=off option or -J option, or the amount of
> jittering can be set with the Jitter_Amount=n.n option. When using
> switches the jitter scale may be specified after the +Jn.n option. For
> example +J0.5 uses half the normal jitter. The default amount of 1.0 is
> the maximum jitter which will insure that all super-samples remain
> inside the original pixel.
> -----------------------------------------------------------
i mangled this paragraph on purpose because i was fishing for
clarification... lol and you bit!
>
> Additional noteworthy information:
>
> - It may be worth noting that if the image contains an alpha channel,
> that channel will also be considered in the comparisons, pretty much
> like the colour channels, except that unlike the other channels it is
> not subject to `Antialias_Gamma`.
almost verbatim near the end...
>
>
>> besides the am3 additions i also did some general cleanup and added a
>> few visual cues to help better separate the method detail descriptions
>
> Would it make sense to use sub-headings instead of just bold text?
ugh...i'm being lazy
>
> Also, I guess it might be useful to add another visual cue between the
> type 3 description and the subsequent description of common features.
wasn't /feeling/ any of the several things i tried so i left it as is
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/23/18 7:36 AM, Jim Holsenback wrote:
>> ----------------------------------------------------------
>> Another way to reduce anti-aliasing artifacts is to introduce noise into
>> the sampling process. This is called jittering and works because the
>> human visual system is much more forgiving to noise than it is to
>> regular patterns, and is inherent in anti-aliasing mode 3. When using
>> one of the other methods, the location of the super-samples is also
>> jittered or wiggled a tiny amount jittering by default, but may be
>> turned off with the Jitter=off option or -J option, or the amount of
>> jittering can be set with the Jitter_Amount=n.n option. When using
>> switches the jitter scale may be specified after the +Jn.n option. For
>> example +J0.5 uses half the normal jitter. The default amount of 1.0 is
>> the maximum jitter which will insure that all super-samples remain
>> inside the original pixel.
>> -----------------------------------------------------------
one more thing i just thought of...so is -j is useless if using +am3.
does it throw a warning if the user specifies? i couldn't check because
i'm in the middle of my variation of RSOCP...GSOPP (glowing spheres on
pavement plane) beauty run
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.09.2018 um 13:36 schrieb Jim Holsenback:
>> Sampling Methods Synopsis:
>>
>> - Excellent! Love this mini section!
>
> at least it's better than the run-on sentence that used to be there
I consider it genuinely brilliant.
>> Details, Type 1:
>>
>> - The section states that "the adaptive non-recursive method is the
>> default". I would suggest adding "if anti-aliasing is enabled" or
>> something along those lines, because the "out of the box" default is no
>> anti-aliasing at all.
>
> yep
Hm... the new version of the sentence seems garbled.
>> - It may or may not be worth also considering an optional alpha channel
>> in the formula given (but see further below).
>
> if you /really/ think it's worth it help me out a bit...i /did/ do
> something near the end of common as there was already a +ag discussion
> going on... it seemed to fit.
I think that's good enough.
>>> besides the am3 additions i also did some general cleanup and added a
>>> few visual cues to help better separate the method detail descriptions
>>
>> Would it make sense to use sub-headings instead of just bold text?
...
>> Also, I guess it might be useful to add another visual cue between the
>> type 3 description and the subsequent description of common features.
>
> wasn't /feeling/ any of the several things i tried so i left it as is
Mind if I mess with it? Then you can blame it on me if you're still not
totally happy with it ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/23/18 8:00 AM, clipka wrote:
>>> - The section states that "the adaptive non-recursive method is the
>>> default". I would suggest adding "if anti-aliasing is enabled" or
>>> something along those lines, because the "out of the box" default is no
>>> anti-aliasing at all.
>>
>> yep
>
> Hm... the new version of the sentence seems garbled.
my bad...it's been cleaned up
>>> Also, I guess it might be useful to add another visual cue between the
>>> type 3 description and the subsequent description of common features.
>>
>> wasn't /feeling/ any of the several things i tried so i left it as is
>
> Mind if I mess with it? Then you can blame it on me if you're still not
> totally happy with it ;)
go for it...i haven't given up either
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.09.2018 um 13:49 schrieb Jim Holsenback:
> On 9/23/18 7:36 AM, Jim Holsenback wrote:
>>> ----------------------------------------------------------
>>> Another way to reduce anti-aliasing artifacts is to introduce noise into
>>> the sampling process. This is called jittering and works because the
>>> human visual system is much more forgiving to noise than it is to
>>> regular patterns, and is inherent in anti-aliasing mode 3. When using
>>> one of the other methods, the location of the super-samples is also
>>> jittered or wiggled a tiny amount jittering by default, but may be
>>> turned off with the Jitter=off option or -J option, or the amount of
>>> jittering can be set with the Jitter_Amount=n.n option. When using
>>> switches the jitter scale may be specified after the +Jn.n option. For
>>> example +J0.5 uses half the normal jitter. The default amount of 1.0 is
>>> the maximum jitter which will insure that all super-samples remain
>>> inside the original pixel.
>>> -----------------------------------------------------------
>
> one more thing i just thought of...so is -j is useless if using +am3.
> does it throw a warning if the user specifies? i couldn't check because
> i'm in the middle of my variation of RSOCP...GSOPP (glowing spheres on
> pavement plane) beauty run
`+j/-j` has no effect whatsoever when using `+am3`.
I'm not sure whether throwing a warning would be the right thing to do;
it's not general policy to throw warnings for using INI file or
command-line settings that turn out to be without effect due to the
other settings. For example, `+am3` by itself (without `+a`) has no
effect either and also doesn't give you a warning.
This actually makes sense, if you consider that you can set up INI stuff
in the master povray.ini. For example, a user might deliberately specify
Antialias=off
Sampling_Method=3
Antialias_Confidence=0.95
Antialias_Threshold=0.02
Jitter=off
Jitter_Amount=0.2
in their povray.ini to tell POV-Ray that they normally want no
anti-aliasing, but if they do they prefer method 3 with a confidence of
95% and a threshold of 2%, and if they choose a different method they
want no jitter, and if they explicitly turn on jitter they want just a
little of it.
Such a user wouldn't want a warning every time they start a render.
The portions of POV-Ray concerned with the /semantics/ of the ini and
command-line settings cannot tell whether they came from a povray.ini, a
quickres.ini, a scene-specific ini or the command-line, whether they
were specified using ini file style or command-line style, nor even the
order in which they were issued, so they are unable to tell whether the
specific settings were intentional as in the above example, or by
mistake as might be presumed in a `+am3 -j` command-line.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.09.2018 um 14:18 schrieb Jim Holsenback:
>>>> Also, I guess it might be useful to add another visual cue between the
>>>> type 3 description and the subsequent description of common features.
>>>
>>> wasn't /feeling/ any of the several things i tried so i left it as is
>>
>> Mind if I mess with it? Then you can blame it on me if you're still not
>> totally happy with it ;)
>
> go for it...i haven't given up either
Done. Feel free to throw it overboard again if inspiration strikes you.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/23/18 8:37 AM, clipka wrote:
> Am 23.09.2018 um 14:18 schrieb Jim Holsenback:
>
>>>>> Also, I guess it might be useful to add another visual cue between the
>>>>> type 3 description and the subsequent description of common features.
>>>>
>>>> wasn't /feeling/ any of the several things i tried so i left it as is
>>>
>>> Mind if I mess with it? Then you can blame it on me if you're still not
>>> totally happy with it ;)
>>
>> go for it...i haven't given up either
>
> Done. Feel free to throw it overboard again if inspiration strikes you.
>
well i could have done that but i does look better...like i said i was
being lazy and trying to avoid touching the two upstream section map
files that wikidocgen uses to do the section renumbering. adding
sub-sections is not a free move
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.09.2018 um 14:43 schrieb Jim Holsenback:
> On 9/23/18 8:37 AM, clipka wrote:
>> Am 23.09.2018 um 14:18 schrieb Jim Holsenback:
>>
>>>>>> Also, I guess it might be useful to add another visual cue between
>>>>>> the
>>>>>> type 3 description and the subsequent description of common features.
>>>>>
>>>>> wasn't /feeling/ any of the several things i tried so i left it as is
>>>>
>>>> Mind if I mess with it? Then you can blame it on me if you're still not
>>>> totally happy with it ;)
>>>
>>> go for it...i haven't given up either
>>
>> Done. Feel free to throw it overboard again if inspiration strikes you.
>>
>
> well i could have done that but i does look better...like i said i was
> being lazy and trying to avoid touching the two upstream section map
> files that wikidocgen uses to do the section renumbering. adding
> sub-sections is not a free move
Sorry about that.
Any way to help you with that? Or add some automation to it?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/23/18 8:53 AM, clipka wrote:
> Am 23.09.2018 um 14:43 schrieb Jim Holsenback:
>> On 9/23/18 8:37 AM, clipka wrote:
>>> Am 23.09.2018 um 14:18 schrieb Jim Holsenback:
>>>
>>>>>>> Also, I guess it might be useful to add another visual cue between
>>>>>>> the
>>>>>>> type 3 description and the subsequent description of common features.
>>>>>>
>>>>>> wasn't /feeling/ any of the several things i tried so i left it as is
>>>>>
>>>>> Mind if I mess with it? Then you can blame it on me if you're still not
>>>>> totally happy with it ;)
>>>>
>>>> go for it...i haven't given up either
>>>
>>> Done. Feel free to throw it overboard again if inspiration strikes you.
>>>
>>
>> well i could have done that but i does look better...like i said i was
>> being lazy and trying to avoid touching the two upstream section map
>> files that wikidocgen uses to do the section renumbering. adding
>> sub-sections is not a free move
>
> Sorry about that.
> Any way to help you with that? Or add some automation to it?
>
no worries...found my script. i had to fire up an old 32bit box
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
