Hello

I am experimenting with new antialiasing methods for povray. Now I am 
looking for scenes where the current methods do a poor job or need too many 
samples/pixels to produce a nice result. If you have such a scene which is 
not too large (<100kB) and does not take hours to render please send it to 
me (mri### [at] gmxnet) or post it to p.*.sf. I will then test if my new 
implementations do better than the old ones.

- Micha

Post a reply to this message

Micha Riser wrote:
> If you have such a scene which is > not too large (<100kB) and
> does not take hours to render

camera{}plane{y,-10pigment{checker rgb 0 rgb 1}finish{ambient 1}rotate -30}


_____________
Kari Kivisalo

Post a reply to this message

Kari Kivisalo wrote:
> ...
> camera{}plane{y,-10pigment{checker rgb 0 rgb 1}finish{ambient 1}rotate -30}
> ...

LOL! That small enough for you? ;)

-- 
signature{
  "Grey Knight" contact{ email "gre### [at] yahoocom" }
  site_of_week{ url "http://digilander.iol.it/jrgpov" }
}

Post a reply to this message

"Kari Kivisalo" <ray### [at] engineercom> wrote in message
news:3C7451CE.B8970CD3@engineer.com...
> Micha Riser wrote:
> > If you have such a scene which is > not too large (<100kB) and
> > does not take hours to render
>
> camera{}plane{y,-10pigment{checker rgb 0 rgb 1}finish{ambient 1}rotate -30}
>
>

I think you left out the reflective sphere there ;o)

--
#local X=20*<-2,2,5>;#local K=2*z*X-X;#local R=seed(frame_number);blob{#while(K
.x>X.x)#local N=X+<rand(R)rand(R)1>/3;#local X=(vlength(N-K)<vlength(X-K)?N:2*X
-N);sphere{X,1,1rotate z*90}sphere{X,1,1}#end pigment{rgbt 1}interior{media{
emission<2,4,5>*5}}hollow scale.05}//   http://nekar_xenos.tripod.com/metanoia/
sphere_sweep{catmull_rom_spline 6<-8,-8>1<-8,-8>1<-8,8>1<8,-8>1<8,8>1<8,8>1
translate 20*z pigment{gradient z scale 3color_map{[0rgb<0,9,18>][1rgb 0]}}}


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.325 / Virus Database: 182 - Release Date: 2002/02/19

Post a reply to this message

Kari Kivisalo <ray### [at] engineercom> wrote:
: camera{}plane{y,-10pigment{checker rgb 0 rgb 1}finish{ambient 1}rotate -30}

  The problem with this kind of scene is that the farther away we go to
the "horizon", the more checkers will fit inside a single pixel. This means
that the farther away we go, the more samples we would need. When we are far
enough, no amount of samples is enough.

  For pigments there's one trick that can be used: trilinearly-filtered
mipmapping. However, this has two problems:
  1. I don't know how mipmaping could be implemented in *procedural* textures
(without taking exorbitant amounts of memory and without losing details).
  2. It works only for the texture of one object. If the checkers were
actual objects (eg. boxes or whatever), this trick won't work.

-- 
#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 <3c750536@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   For pigments there's one trick that can be used: trilinearly-filtered
> mipmapping.

No, it won't help.  Mipmapping just moves the problem to a preprocessing stage
and in general is nearly pointless for raytracing.  Still exactly the same
problem needs to be solved, but can of course use more processing intensive
algorithms for interpolation.  That is why it is used in the first place in
one application:  To allow real-time display in a reasonable quality in CAD
previews (and today games).


    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 <3c750536@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   For pigments there's one trick that can be used: trilinearly-filtered
> mipmapping. However, this has two problems:
>   1. I don't know how mipmaping could be implemented in *procedural* textures
> (without taking exorbitant amounts of memory and without losing details).
>   2. It works only for the texture of one object. If the checkers were
> actual objects (eg. boxes or whatever), this trick won't work.

Not mipmapping, but similar ideas:
Basically, you have to compute the color of an area of texture, not just 
one point.

1: Use distance-based blurring on the texture. Beyond a certain 
distance, start blurring, and blur more with more distance. Breaks if 
you zoom in too much or have an object that magnifies the scene behind 
it, and is slow.

2: Use distance-based patterns. The ordinary checker pattern closer up, 
but with distance the values get closer to 0.5, and it becomes a blend 
instead of a block pattern. Same problems as above, but faster. Also, it 
will break for more complex color maps, and requires extra work on the 
patterns.

3: Take the first object the pixel hits, and supersample it based on 
distance, distant objects getting more samples. You could leave out the 
other scene objects for speed...if they weren't the first intersection, 
it is unlikely they will have much contribution to the pixel. Probably 
the easiest to implement, though not necessarily fast.

4: Use the ray footprint. Figure out the area the pixel covers when 
projected out to the intersection point, and use one of the above two 
techniques to compute the color. One possible way to do this would be to 
fire a pair of slightly different rays (or maybe 3 rays?) and calculate 
the angle between them. The only disadvantage this would have would be 
speed.

All of these would be better if they were done on a per-object basis, 
for speed.

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

Thorsten Froehlich <tho### [at] trfde> wrote:
> No, it won't help.  Mipmapping just moves the problem to a preprocessing stage
> and in general is nearly pointless for raytracing. 

  If it works in scanline rendering, it can work in the exact same way in
raytracing.
  But I already mentioned the difficulties in this. The main difficulty is
that it can be used almost exclusively for image maps.

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

> Basically, you have to compute the color of an area of texture, not just
> one point.
>
> 1: Use distance-based blurring on the texture. Beyond a certain
[....]
> techniques to compute the color. One possible way to do this would be to
> fire a pair of slightly different rays (or maybe 3 rays?) and calculate
> the angle between them. The only disadvantage this would have would be
> speed.

You know, you can always construct scenes (intentionally), that will breake
this algo ...

I would simply try to create _VERY_ small structures...
either I will produce still moires or your algo would be simply inaccurate
...

basically you wil always have problems, with scenes that produce
moire-patterns ...

Post a reply to this message

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

>> No, it won't help.  Mipmapping just moves the problem to a preprocessing
>> stage and in general is nearly pointless for raytracing.
>
>   If it works in scanline rendering, it can work in the exact same way in
> raytracing.

I did not say it can't work, I said it is pointless.  How do you think the
mipmaps are created?  What kind of "more advanced" interpolation does a paint
program use/support that will increase quality compared to POV-Ray image map
interpolation and adaptive antialiasing?  The answer is that there is no such
interpolation algorithm...

    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