Antialiasing a pigment does not help in any way antialiasing object
borders, lighting, shadows, etc.

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

war### [at] tagpovrayorg news:3f4cc551@news.povray.org

>   Antialiasing a pigment does not help in any way antialiasing object
> borders, lighting, shadows, etc.
> 

Ofcourse, but render simple plane { y,0 pigment { checker } } ant try to 
get rid of aliasing. It's alomost impossible.

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

In article <web.3f4cb0bf4d31ed7fd63a77300@news.povray.org> , 
"gramirosimancas" <nomail@nomail> wrote:

> I'm almost sure povray can't do antialiasing using full pixel squares
> instead of simple rays that cause aliasing, can it?

It is called a _ray_ tracer, isn't it?

    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

Thorsten Froehlich wrote:
>It is called a _ray_ tracer, isn't it?
Of course, but if pyramid tracing is possible as an option it would get true
antialiasing.

Post a reply to this message

Rafal 'Raf256' Maj wrote:
>Of course, but render simple plane { y,0 pigment { checker } } ant try to
>get rid of aliasing. It's almost impossible.

That's what pyramid tracing would solve. No aliasing in this case at any
distance.

Post a reply to this message

I was also thinking about doing the integral over time to have _True Motion
Blur_, but let's first have pyramid raytracing and then move to integrating
over time, as I think this would be an easy mathematical step once we have
pyramid raytracing foundations.

Post a reply to this message

In article <web.3f4cd0ad8f004971d63a77300@news.povray.org> , 
"gramirosimancas" <nomail@nomail> wrote:

>>It is called a _ray_ tracer, isn't it?
>
> Of course, but if pyramid tracing is possible as an option it would get true
> antialiasing.

There is no "true antialiasing".  The definition of anti-aliasing is exactly
that, any method that works against the aliasing effect of a pixel based
image.  Thus, any method that removes this effect is called anti-aliasing.

Actually, I don't think you will get any improvement using pyramid tracing.
To the contrary, you only end up with extremely difficult intersection
algorithms and still have to use some kind of averaging over the surfaces
you find as they have textures.  You only get a whole lot of really
difficult to solve problems using anything but rays, hence all other
approaches have more or less been abandoned for image generation - they
simply offer no benefit whatsoever as far as realism or quality of an image
is concerned.

    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

gramirosimancas <nomail@nomail> wrote:
> I was also thinking about doing the integral over time to have _True Motion
> Blur_, but let's first have pyramid raytracing and then move to integrating
> over time, as I think this would be an easy mathematical step once we have
> pyramid raytracing foundations.

  You make it sound like pyramid tracing could be possible in the first
place.
  There are several problems in getting the exact average of the intersection
of a (4-sided) pyramid and the scene:

  - Take a surface with a pigment and project a square onto it. The projection
of the square can have virtually any shape at free (because the surface can
have any shape). How do you calculate the exact average of the pigment
inside this freely-shaped area? Note that there's no limit on how
complex a pigment can be (it can be a fractal, a user-defined function...).

  - Getting the average pigment is only one small step. After that we need
the average lighting of the surface over the freely-shaped area. Now we
have a real problem. How do you calculate this average lighting? (The only
way I can think of is by taking samples inside the shape, but this is
exactly what we wanted to avoid in the first place).

  - And it gets more complex: Another object might be casting a shadow
which partially covers our freely-shaped area. How much of the area does
it cover? How do you calculate that (besides taking random samples)?

  - All the above deal with the case of the square being projected
entirely on one single surface. What happens if there's an edge of
the surface there? You will need to calculate how much each separate
surface take in our freely-shaped area and calculate the average of
their visible area.

  - What about reflections and refractions? When a square is projected
onto a surface and then reflected or refracted, it can continue forward
with virtually any shape. The surface where it is reflected/refracted
from can be as convoluted and complex you like. This affects the shape
of the square in really complex ways when we want to reflect/refract it.
  For example, imagine the projected square hitting the edge of a
reflective box. Part of the square will hit one side of the box and
the rest will hit another side of the box. Their reflection will go
in completely separate directions. Thus the square has been split into
two. Now imagine that it hits a vertex of the box. Imagine that it hits
the vertex of a shape where 8 surfaces meet. Imagine that these surfaces
are not flat...
  I believe you get the picture here.

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

Thorsten Froehlich wrote:
>There is no "true antialiasing". The definition of anti-aliasing is exactly
>that, any method that works against the aliasing effect of a pixel based
>image.  Thus, any method that removes this effect is called anti-aliasing.

If you want to call it "best results antialiasing" is also OK for me.

>Actually, I don't think you will get any improvement using pyramid tracing.

Theorically you will get _full improvement_ (or _best results_).

>To the contrary, you only end up with extremely difficult intersection
>algorithms and still have to use some kind of averaging over the surfaces
>you find as they have textures.

That's the point in using pyramid tracing: "the averaging over the surfaces
even with textures". I thought you know what is was talking about.

>You only get a whole lot of really
>difficult to solve problems using anything but rays, hence all other
>approaches have more or less been abandoned for image generation - they
>simply offer no benefit whatsoever as far as realism or quality of an image
>is concerned.

I think you are wrong.

In the 2d case where "pyramid raytracing" is used successfully in many
vector drawing programs and render libs there is an alias removal bost
while compared to bad libraries that do simple pixel sampling (equivalent
to 3d raytracing).
An example library that does this kind of antialiasing in the 2d world is
http://www.levien.com/libart/

No current antialias method in povray can cope with a simple checker surface
at any distance while using pyramid raytracing have always best results at
any distance. If you use a checker structure with a program that uses
libart you'll see there's no energy lost at any distance (i.e. the picture
is neither completely black nor completely white.

Post a reply to this message

Warp wrote:
>gramirosimancas <nomail[at]nomail> wrote:
>> I was also thinking about doing the integral over time to have _True Motion
>> Blur_, but let's first have pyramid raytracing and then move to integrating
>> over time, as I think this would be an easy mathematical step once we have
>> pyramid raytracing foundations.
>
>  You make it sound like pyramid tracing could be possible in the first
>place.

I have not found any real impediment. It may be just hard.

>  There are several problems in getting the exact average of the intersection
>of a (4-sided) pyramid and the scene:
>
>  - Take a surface with a pigment and project a square onto it. The projection
>of the square can have virtually any shape at free (because the surface can
>have any shape). How do you calculate the exact average of the pigment
>inside this freely-shaped area? Note that there's no limit on how
>complex a pigment can be (it can be a fractal, a user-defined function...).

If would have to be subdivided in simple regions that can be averaged
together. If the user-defined function doesn't have an analytical surface
integral it wouldn't be possible to use it (just like in the 2d case where
libart (http://www.levien.com/libart/) can only render filled lines and
splines). You can always try to approximate an arbitrary function to a
spline.

>  - Getting the average pigment is only one small step. After that we need
>the average lighting of the surface over the freely-shaped area. Now we
>have a real problem. How do you calculate this average lighting? (The only
>way I can think of is by taking samples inside the shape, but this is
>exactly what we wanted to avoid in the first place).

What's the problem?
Just think this way:
Instead of using a single ray, think the integral over the square pixel.
Like instead sampling the value of a 1d function you take the integral
between two sampling points.

>  - And it gets more complex: Another object might be casting a shadow
>which partially covers our freely-shaped area. How much of the area does
>it cover? How do you calculate that (besides taking random samples)?

You may have to separate shaded part and the unshaded part and then average
both according the surface occupied.
It should be not different apart from applying a integral.
What I don't know is if these integrals are analytical in every case, as I
haven't done any mathematics except in the 2d case where it works with
lines and splines (but as you know this is much simpler)

>  - All the above deal with the case of the square being projected
>entirely on one single surface. What happens if there's an edge of
>the surface there? You will need to calculate how much each separate
>surface take in our freely-shaped area and calculate the average of
>their visible area.

As said above.

>  - What about reflections and refractions? When a square is projected
>onto a surface and then reflected or refracted, it can continue forward
>with virtually any shape. The surface where it is reflected/refracted
>from can be as convoluted and complex you like. This affects the shape
>of the square in really complex ways when we want to reflect/refract it.
>  For example, imagine the projected square hitting the edge of a
>reflective box. Part of the square will hit one side of the box and
>the rest will hit another side of the box. Their reflection will go
>in completely separate directions. Thus the square has been split into
>two. Now imagine that it hits a vertex of the box. Imagine that it hits
>the vertex of a shape where 8 surfaces meet. Imagine that these surfaces
>are not flat...

You'll have to average many non square shapes.

Yes, as said before, we may have to drop many strange surfaces or
approximate them to simpler surfaces that have analytical solutions.

>  I believe you get the picture here.

Yes it's hard and many strange functions would have to be dropped but you'll
get very good results.

You say this would be hard, but you also know this is not impossible.

Anyway, I was asking to know if there's some work done in this area so I
don't have to start from zero in the mathematical foundations.

Post a reply to this message