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!

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?

btw: I use POV-Ray 3.5.
Felix Wiemann

Post a reply to this message

In article <3c6a935b@news.povray.org> , "Felix Wiemann" 
<Fel### [at] gmxnet> wrote:

> 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?

Who cares as long as the result is free of errors?

If you want to know how AA works, take a look at the source code.  It is not
like everything has changed in 3.5 :-)

    Thorsten

Post a reply to this message

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.

Post a reply to this message

Felix Wiemann <Fel### [at] gmxnet> wrote:
: 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!

  I think that's just a colloquial terminology thing. It wants to say that
if(difference_between_adjacent_pixels >= threshold) then supersample.
  However, that '>=' is more difficult to express in fluent english than
just "more than".
  Of course it could be said precisely, but it would require a rewording of
the expression. Instead of being something like
  "If adjacent pixel colors differ more than the given threshold..."
it would need to be something like:
  "If the difference in color between adjacent pixels is more or equal to
the given threshold..."

: 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?

  As Thorsten said, who cares as long as it gives a good result?-)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Tony[B] <ben### [at] catholicorg> 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 problem in raytracing is that rays are infinitely thin and they cover
only an infinitely thin volume of space (they are 1-dimensional). However,
the distance between pixels is huge compared to that. If an object is much
smaller than a pixel then there's a big chance that no ray will hit it.
There's no way the renderer can know that the object is there and that it
should shoot rays towards it. (After all, the reason to shoot rays through
pixels in the first place is to see if there's some object in that direction.)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

On 13 Feb 2002 12:51:24 -0500, Warp wrote:
> There's no way the renderer can know that the object is there and that it
> should shoot rays towards it. (After all, the reason to shoot rays through
> pixels in the first place is to see if there's some object in that direction.)

Actually, there is a way: the vista buffer.  But there's no way to know what
percentage of the pixel that object will take up or how it should be shaded
without shooting lots of rays at it.

-- 
#local R=rgb 99;#local P=R-R;#local F=pigment{gradient x}box{0,1pigment{gradient
y pigment_map{[.5F pigment_map{[.3R][.3F color_map{[.15red 99][.15P]}rotate z*45
translate x]}]#local H=pigment{gradient y color_map{[.5P][.5R]}scale 1/3}[.5F
pigment_map{[.3R][.3H][.7H][.7R]}]}}}camera{location.5-3*z}//only my opinions

Post a reply to this message

On 13 Feb 2002 12:47:46 -0500, Warp wrote:
>   However, that '>=' is more difficult to express in fluent english than
> just "more than".

"at least"


-- 
#local R=rgb 99;#local P=R-R;#local F=pigment{gradient x}box{0,1pigment{gradient
y pigment_map{[.5F pigment_map{[.3R][.3F color_map{[.15red 99][.15P]}rotate z*45
translate x]}]#local H=pigment{gradient y color_map{[.5P][.5R]}scale 1/3}[.5F
pigment_map{[.3R][.3H][.7H][.7R]}]}}}camera{location.5-3*z}//only my opinions

Post a reply to this message

In article <3c6aa79b@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   You are welcome to suggest an algorithm for that.

Hmm...sample initially in a cross or x pattern to find out if a thin 
object goes through the pixel? If one is found, supersample the entire 
pixel. It would be slower than the current adaptive method, because the 
minimum samples per pixel would be higher, but should be faster than the 
completely non-adaptive method.
Also, a multiple pass method might be interesting...render with no or 
very little antialiasing, then run additional supersampling passes. A 
faster preview, and you could let it refine the image indefinitely. A 
pixel could be supersampled if any of the nearby pixels hit an object 
but it didn't.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <chr### [at] netplexaussieorg> , Christopher
James Huff <chr### [at] maccom>  wrote:

> Hmm...sample initially in a cross or x pattern to find out if a thin
> object goes through the pixel?

Won't work well:  Remember that the ray is infinitely thin, so you will have
some spacing between rays.  Of course, you can make the sampling so small that
is scratches floating-point precision, but I doubt this would really improve
quality.

What can be done with every object with a known surface is to find a few
points on the surface and then start sampling from there (so doing AA with
superpixels first).  It would work for all objects with a single surface or a
number of parts/surfaces assuming you can supply one point for each of them.
However, I don't even want to make any guess about the speed to expect from
such a method.  Not to mention it would only work (in finite time) for primary
rays.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: Actually, there is a way: the vista buffer.

  Does it work for reflections/refractions as well?-)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

On 13 Feb 2002 13:49:25 -0500, Warp wrote:
> Ron Parker <ron### [at] povrayorg> wrote:
>: Actually, there is a way: the vista buffer.
> 
>   Does it work for reflections/refractions as well?-)

No.  But then, those are harder for the existing AA methods too.

-- 
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker

Post a reply to this message

> Who cares as long as the result is free of errors?
It should be clear what it does or at least not wrong documentated imho. AA
is a very important thing, so the user should have maximal control of it.

> If you want to know how AA works, take a look at the source code.
> It is not like everything has changed in 3.5 :-)
Does this mean, AA hasn't changed and I can use the 3.1 source?

Post a reply to this message

>   You are welcome to suggest an algorithm for that.

I've had a very hard time finding any information on alternate algorithms.
Most of the ones I found sound like what POV does. I brought it up, because
for example, 3d studio max has about a dozen AA methods. Most of them are
redundant or crappy, but there are one of two which give a nice effect
overall to the rendering. I wonder if the reason I can't find anything is
because it isn't free information? :P

Post a reply to this message

>   You are welcome to suggest an algorithm for that.

By the way... have you looked at the AA methods that the GeForce 4 uses?
Maybe you could find something useful there. Check out the recent review on
AnandTech.com.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
:>   Does it work for reflections/refractions as well?-)

: No.  But then, those are harder for the existing AA methods too.

  How so?

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <3c6ab2c5@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> Won't work well:  Remember that the ray is infinitely thin, so you will have
> some spacing between rays.  Of course, you can make the sampling so small that
> is scratches floating-point precision, but I doubt this would really improve
> quality.

The point of using an X pattern would be to make it more likely to find 
a thin object while using fewer samples. I know it wouldn't be perfect, 
but it might work faster than sampling in a grid.


> What can be done with every object with a known surface is to find a few
> points on the surface and then start sampling from there (so doing AA with
> superpixels first).  It would work for all objects with a single surface or a
> number of parts/surfaces assuming you can supply one point for each of them.

So, if a pixel hit an object but an adjacent one didn't, supersample the 
surrounding ones to make sure they didn't hit it, and supersample 
outwards until you run out of pixels that hit the object?

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <3c6ab883@news.povray.org>, "Tony[B]" <ben### [at] catholicorg> 
wrote:

> By the way... have you looked at the AA methods that the GeForce 4 uses?
> Maybe you could find something useful there. Check out the recent review on
> AnandTech.com

That's scanline rendering...a completely different situation from 
raytracing.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

On 13 Feb 2002 14:04:51 -0500, Warp wrote:
> Ron Parker <ron### [at] povrayorg> wrote:
>:>   Does it work for reflections/refractions as well?-)
> 
>: No.  But then, those are harder for the existing AA methods too.
> 
>   How so?

Supersampling over a single screen pixel isn't enough to resolve fine details 
if they're magnified by reflections or refractions.  That's one of the 
problems that the Tracing Ray Differentials paper was trying to solve.

--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}

Post a reply to this message

"Felix Wiemann" <Fel### [at] gmxnet> wrote in message
news:3c6a935b@news.povray.org...
> 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.

Good point.  As others pointed out, it should say "at least".

> Try +A0.001: No pixel
> is sampled anymore!

Why is this such a surprise?  You're asking for a difference of 0.001, but
all of the pixels are exactly the same (difference = 0), so they _shouldn't_
be supersampled.  This is the expected behavior.

...Chambers

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3c6aa79b@news.povray.org...
> Tony[B] <ben### [at] catholicorg> 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.

Simplified version (for the final viewing plane):
Check the object's bounding hierarchy for the maximum and minimum elevations
above the horizon, as well as the rotations from center.  Plot as a box.
AFAIK, this is the method used for visa buffer.
If a pixel is within the box, but it's neighbor is not, supersample between
them.  If a box lies entirely between the two pixels, supersample them.
If both pixels are within the box, one hits the object and the other does
not, supersample between them.

The current sampling method is color based, and works to ensure all portions
of the screen look nice.  This method, being intersection based, deals with
edges / small objects very nicely, but will not address aliased textures.

BTW, this is off the top of my head, I don't know if it is really practical
or if it has even been previously published (just seems to make sense to
me).

...Chambers

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3c6ab534@news.povray.org...
> Ron Parker <ron### [at] povrayorg> wrote:
> : Actually, there is a way: the vista buffer.
>
>   Does it work for reflections/refractions as well?-)

Does the current method?  I was under the impression that supersampling was
done only on the rays shot from the view plane, and not on reflection /
refracted rays.

...Chambers

Post a reply to this message

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

"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

> The only use I can think of would be hanging wires.

Or other such thin lines, like in the bricks pattern, or when you're trying
to simulate fur and hair.

Post a reply to this message

On Wed, 13 Feb 2002 12:01:20 -0800, Ben Chambers wrote:
> Simplified version (for the final viewing plane):
> Check the object's bounding hierarchy for the maximum and minimum elevations
> above the horizon, as well as the rotations from center.  Plot as a box.
> AFAIK, this is the method used for visa buffer.

Actually, the vista buffer is somewhat more complex, in that it actually
projects the bounding box onto the camera plane as a generalized hexagon.

> The current sampling method is color based, and works to ensure all portions
> of the screen look nice.  This method, being intersection based, deals with
> edges / small objects very nicely, but will not address aliased textures.

Correction: it deals with edges that are within a pixel of the edge of the
bounding box.  This is a far cry from all edges, even for simple boxes and 
cylinders (consider rotation.)

-- 
#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

Ben Chambers <bdc### [at] yahoocom> wrote:
:>   Does it work for reflections/refractions as well?-)

: Does the current method?  I was under the impression that supersampling was
: done only on the rays shot from the view plane, and not on reflection /
: refracted rays.

  Of course it works for reflections/refractions. If the pixel color
difference threshold is reached, then another ray is shot from the camera.
This ray will (probably) also reflect/refract from the same object, thus
sampling whatever is reflected/refracted.

  However, the problem here was that if there was such a small object/detail
that no ray hits it and thus is not detected, how could it be done so that
it would be detected anyways and rays shot at it. This might be possible
only if this small object/detail is viewed directly from the camera, but not
if it's seen only in a reflection or refraction.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <3c6ad4df@news.povray.org>,
 "Ben Chambers" <bdc### [at] yahoocom> wrote:

> Such a setting belongs in the INI file, not in the scene.

The .ini file is no place for an object-specific attribute.


> The only use I can think of would be hanging wires.

Hairs, any kind of cabling, ropes or strings, screens or gratings, chain 
link fences, stars, cracks (like in floors or walls), wood, small 
text...I could come up with more. You can usually get good results with 
with the existing adaptive method, but not always.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Ron Parker wrote:
> 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.

So because it can't be done for everything, it isn't done at all.
Gotcha.

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

In article <3c6ac710@news.povray.org>,
 "Ben Chambers" <bdc### [at] yahoocom> wrote:

> Does the current method?  I was under the impression that supersampling was
> done only on the rays shot from the view plane, and not on reflection /
> refracted rays.

The current method uses the resulting color of the pixel, so anything 
that causes a change in the color gets antialiased. The pixels are what 
get supersampled, not the rays.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <chr### [at] netplexaussieorg> , Christopher
James Huff <chr### [at] maccom>  wrote:

> So, if a pixel hit an object but an adjacent one didn't, supersample the
> surrounding ones to make sure they didn't hit it, and supersample
> outwards until you run out of pixels that hit the object?

Basically, yes.  It will always succeed given the object meets the
requirements I mentioned.  Your method could still fail, but is far simpler to
implement, of course.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3C6AE046.5D095B2C@scifi-fantasy.com>,
 "Timothy R. Cook" <tim### [at] scifi-fantasycom> wrote:

> So because it can't be done for everything, it isn't done at all.

It would be very difficult, probably requiring a rewrite, and about the 
only thing it would work for would be triangles and polygons. Even 
spheres would probably be too difficult...where's the edge of an 
unevenly scaled and rotated sphere? And then you have things like the 
different camera types, camera normals, etc, which would make it 
unuseable for any object...
It is simply not worth implementing for the few cases it would actually 
be any help.

POV is a raytracer, it only knows where the surface of an object is by 
intersections with rays, it is not aware of the "edges". The only way to 
do it for most objects is to take samples, which is exactly what is done 
now.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

On Wed, 13 Feb 2002 16:22:33 -0500, "Timothy R. Cook"
<tim### [at] scifi-fantasycom> wrote:

>But they're defined by mathematical formulae.  You know (or can find
>out) exactly where the surface is by solving for the formula.

You're always welcome to solve for the formula defining the
intersection of a complex isosurfaces with noise, and a atanh julia
fractal :)


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

One can always render at 10 times the final resolution
and then use any resampling method available in
image processing packages to produce the final image.

As I understand povray simply averages the sub-pixels.
Anyone tried cosine, cone or some other weighting
distribution? 


_____________
Kari Kivisalo

Post a reply to this message

On Wed, 13 Feb 2002 16:53:10 -0500, Timothy R. Cook wrote:
> Ron Parker wrote:
>> 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.
> 
> So because it can't be done for everything, it isn't done at all.
> Gotcha.

Want it changed?  Stop bitching and start writing code.

-- 
#local R=rgb 99;#local P=R-R;#local F=pigment{gradient x}box{0,1pigment{gradient
y pigment_map{[.5F pigment_map{[.3R][.3F color_map{[.15red 99][.15P]}rotate z*45
translate x]}]#local H=pigment{gradient y color_map{[.5P][.5R]}scale 1/3}[.5F
pigment_map{[.3R][.3H][.7H][.7R]}]}}}camera{location.5-3*z}//only my opinions

Post a reply to this message

Christopher James Huff wrote:
> Even spheres would probably be too difficult...where's the edge
> of an unevenly scaled and rotated sphere?

What's the formula for a sphere with arbitrary xyz scale and rotation?
It exists, I'm sure...

> And then you have things like the different camera types, camera
> normals, etc, which would make it unuseable for any object...

Not unusable, just impractical and masochistic.

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

Ron Parker wrote:
> Want it changed?  Stop bitching and start writing code.

So the only way to get anything done in the world is to do it
yourself, even if other people have more aptitude with what you
want changed?  I was just tossing out a suggestion, asking if
x could be done.  A response was given to the effect that
since it doesn't apply to every case (or even most cases)
that it wouldn't be done, implying that it COULD be done.

As far as writing code myself, I can't even figure out how
to ...oh wait, nevermind, just had an epiphany, raytracing-wise.
I could write a raytracer, but it'd output an ASCII-art
image O.o (since I don't know how to do graphics in C)

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

"Timothy R. Cook" wrote:
> Ron Parker wrote:
> > Want it changed?  Stop bitching and start writing code.
>
> So the only way to get anything done in the world is to
> do it yourself, even if other people have more aptitude
> with what you want changed?

Precisely.

Unless it's something extremely simple, like, say, changing the way transmit
works outside of the 0 to 1 range to a more logical behavior. It only took
me a couple of years where i repeatedly raised this issue over and over
again before it was implemeted.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Jan 20)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
> Unless it's something extremely simple, like, say, changing the
> way transmit works outside of the 0 to 1 range to a more logical
> behavior.

How exactly DOES transmit work, anyways?  Amount of light able
to pass through the object?  0 being none, 1 being all...more
than 1 being...the object adds light to that passing through it?
That would be cool.  If that's how it works, I wanna try that
out!

-- 
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 18:22:22 -0500, Timothy R. Cook wrote:
> Rune wrote:
>> Unless it's something extremely simple, like, say, changing the
>> way transmit works outside of the 0 to 1 range to a more logical
>> behavior.
> 
> How exactly DOES transmit work, anyways?  Amount of light able
> to pass through the object?  0 being none, 1 being all...more
> than 1 being...the object adds light to that passing through it?
> That would be cool.  If that's how it works, I wanna try that
> out!

Ahh, but you need to think even further outside the box: what does a
negative transmit do?

--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}

Post a reply to this message

In article <3c6af2ea@news.povray.org>,
 "Rune" <run### [at] mobilixnetdk> wrote:

> Unless it's something extremely simple, like, say, changing the way transmit
> works outside of the 0 to 1 range to a more logical behavior. It only took
> me a couple of years where i repeatedly raised this issue over and over
> again before it was implemeted.

Demand is a factor, of course...there are maybe 3 people who use 
transmit outside the [0, 1] range. ;-)
Most users and programmers were just more interested in things like the 
new patterns and isosurfaces.

However, not only is there little demand for this feature, it would be 
extremely difficult to implement (essentially a different rendering 
method, somewhat similar to scanline in that it is world-to-screen 
instead of screen-to-world) and would only very rarely be of any actual 
use, if it is useful at all (it could easily be just too slow). There 
are better things to spend time on.
And remember, the people who are working on POV are doing so in their 
free time, and are not being payed to do it.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <3C6AEBFD.4E0A0743@scifi-fantasy.com>,
 "Timothy R. Cook" <tim### [at] scifi-fantasycom> wrote:

> What's the formula for a sphere with arbitrary xyz scale and rotation?
> It exists, I'm sure...

And now you have to project it, with perspective, onto a plane, which 
can also have any transformations applied. The result: a scene with a 
single untextured sphere would probably take longer to render then the 
most complex scene today, just so you could antialias the edges of the 
sphere without taking samples.


> Not unusable, just impractical and masochistic.

Often impossible. For some things, there just isn't a solution, sampling 
is the only way.
The closest you could get would probably be to use a scanline renderer 
for the first stage. You would be limited to what you can render with 
scanlining, though, which usually means you have to reduce your shapes 
to triangles.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Timothy R. Cook <tim### [at] scifi-fantasycom> wrote:
: So the only way to get anything done in the world is to do it
: yourself

  Welcome to the real world. ;)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message