 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Why is this such a surprise?
It isn't. I wrote it only to show the difference between +A0.0 and +A0.001,
because the doc says that there isn't a difference.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> Supersampling over a single screen pixel isn't enough to resolve fine
> details if they're magnified by reflections or refractions.
Since it's all math anyways, and you already know where the surfaces
are...can't you do a trace along the edges instead of a grid of rays?
If there's a reflective surface, can you spawn a new set of rays and
shoot them and do their edgetrace for those fine details?
No, I don't know what I'm talking about, no I probably don't want
to know how long such a thing would take to render if it's longer
than existing methods.
--
Tim Cook
http://empyrean.scifi-fantasy.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Felix Wiemann wrote:
>
> Hi,
> when I use anti-aliasing and treshold 0.0 (+A0.0) with an empty (black)
> scene, every pixel is super-sampled. The doc says every pixel which differs
> *more* than threshold is sampled, but that's not true. Try +A0.001: No pixel
> is sampled anymore!
Um. If all your pixels are the same color, then none of them have any
difference from each other greater than zero. Duh.
Are you implying that the docs are in error by not saying "equal to or
more"? If so, you may be correct.
> Now I use the recursive AA method (+AM2) and use a depth of 2 (+R2). The
> messages say: 16.06 (@160x120) / 16.01 (@640x480) samples are taken per
> pixel. This is dependent on the resolution, so the pixels in the edges seem
> to be handled in a different way. The doc says: At a depth of 2 the maximum
> number of taken samples is 25!
>
> Why are the pixels at the edges sampled in a different way than the others
> with method 2 (but not method 1)?
> Why isn't the maximum number of samples taken?
Because that's how recursive AA works; instead of blindly supersampling
everything within a pixel's area, the algorithm attempts to find edges
and only use the samples that are needed to better define those edges,
while interpolating the rest.
Check the docs again. The explanation is a bit hard to understand if you
don't already understand it, but the answers you seek are there.
-Xplo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> That's scanline rendering...a completely different situation from
> raytracing.
I know, but you can still look at how they sample pixels... They do that X
shaped type sampling you suggested.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Tony[B] <ben### [at] catholic org> wrote:
> : Has the Team ever considered adding more AA methods? It'd be nice if you
> : found one that handled very thin lines a little better.
>
> You are welcome to suggest an algorithm for that.
The only thing I can think of is to add a keyword to the parser, similar
to hollow, which would sit somewhere in an object, and which would
instruct the rendered to use different AA parameters for everything
inside that object's bounding box.
I have to say, though, that I question how useful this would be. Tony
evidently wants the renderer to find features that are far too small to
appear on his display, and which would therefore necessarily have
minimal effect on a scene since even if they were found the most they
would contribute is an additional set of values for the AA algorithm
which would then be averaged almost out of existence anyway. I will
admit that I've seen scenes where poor rendering of fine details was
painfully noticible, but you almost have to set a situation like that up
deliberately.. and one of them that I've seen involved a ground plane
textured with two gradients to make a grid; in such a case, the whole
plane would use the picky AA settings, and one might almost as well just
use those settings (most likely some ridiculously fine non-recursive AA)
for the whole image anyway.
-Xplo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 13 Feb 2002 15:16:15 -0500, Timothy R. Cook wrote:
> Ron Parker wrote:
>> Supersampling over a single screen pixel isn't enough to resolve fine
>> details if they're magnified by reflections or refractions.
>
> Since it's all math anyways, and you already know where the surfaces
> are...can't you do a trace along the edges instead of a grid of rays?
If we knew where the surfaces were, we wouldn't need to trace rays at all.
As it turns out, we don't know where they are. The vista buffer tells us
where on the screen their bounding boxes fall, but that's not entirely the
same thing.
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Felix Wiemann" <Fel### [at] gmxnet> wrote in message
news:3c6ac756@news.povray.org...
> > Why is this such a surprise?
> It isn't. I wrote it only to show the difference between +A0.0 and
+A0.001,
> because the doc says that there isn't a difference.
Why isn't there a difference? IIRC, 1/1000 is the bounding threshold, which
means that anything ~less than~ 0.001 would have no difference.
<does some quick renders>
In fact, it appears that ~any~ number is enough to put a non-zero value in
for the threshold; that is, no matter what you put for the threshold (unless
it is zero), identical pixels will not be supersampled.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
From: Ben Chambers
Subject: Re: More methods? was Re: anti-aliasing
Date: 13 Feb 2002 16:04:31
Message: <3c6ad4df@news.povray.org>
|
|
|
| |
| |
|
|
"Xplo Eristotle" <inq### [at] unforgettablecom> wrote in message
news:3C6ACD85.38C040E3@unforgettable.com...
> The only thing I can think of is to add a keyword to the parser, similar
> to hollow, which would sit somewhere in an object, and which would
> instruct the rendered to use different AA parameters for everything
> inside that object's bounding box.
Such a setting belongs in the INI file, not in the scene.
> I have to say, though, that I question how useful this would be. Tony
> evidently wants the renderer to find features that are far too small to
> appear on his display, and which would therefore necessarily have
> minimal effect on a scene since even if they were found the most they
> would contribute is an additional set of values for the AA algorithm
> which would then be averaged almost out of existence anyway. I will
> admit that I've seen scenes where poor rendering of fine details was
> painfully noticible, but you almost have to set a situation like that up
> deliberately.. and one of them that I've seen involved a ground plane
> textured with two gradients to make a grid; in such a case, the whole
> plane would use the picky AA settings, and one might almost as well just
> use those settings (most likely some ridiculously fine non-recursive AA)
> for the whole image anyway.
The only use I can think of would be hanging wires.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> If we knew where the surfaces were, we wouldn't need to trace rays
> at all. As it turns out, we don't know where they are.
But they're defined by mathematical formulae. You know (or can find
out) exactly where the surface is by solving for the formula.
As I pointed out earlier, POV is a honking big souped-up fancy
graphing calculator. With colour.
--
Tim Cook
http://empyrean.scifi-fantasy.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 13 Feb 2002 16:22:33 -0500, Timothy R. Cook wrote:
> Ron Parker wrote:
>> If we knew where the surfaces were, we wouldn't need to trace rays
>> at all. As it turns out, we don't know where they are.
>
> But they're defined by mathematical formulae. You know (or can find
> out) exactly where the surface is by solving for the formula.
Not in every case. Some things have to be approximated, which is a messy
and expensive task. Examples include the poly object for higher-order
polynomials, the isosurface object, and lots of others.
--
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
