... but I was interested in the inner structures. Took my machine 2 days to
render at 800x600. I think I have to work on the code...

Original version (800x600) at:

http://www.b0n541.net/povray/pics/mengersponge.jpg (~ 100 KB)

Sheers,

Bonsai

Post a reply to this message

Attachments:
Download 'mengersponge.jpg' (33 KB)

Preview of image 'mengersponge.jpg'

Bonsai wrote:

>  [Image]

Needs a mouse :)
--
Bye,
Pabs

Post a reply to this message

In article <3aa897cd@news.povray.org>, "Bonsai" <bon### [at] b0n541net> 
wrote:

> ... but I was interested in the inner structures. Took my machine 2 days 
> to render at 800x600. I think I have to work on the code...

It's too yellow for swiss cheese...
Hmm, I wonder what a semitransparent Menger sponge would look 
like...it'd probably take a couple years to render with a decent 
recursion level, though. And to get the transparency right, you would 
need to use a completely transparent texture and attenuation (fade_color 
would be useful).

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" <chr### [at] maccom> schrieb im Newsbeitrag
news:chrishuff-913808.06504209032001@news.povray.org...
> In article <3aa897cd@news.povray.org>, "Bonsai" <bon### [at] b0n541net>
> wrote:
>
> It's too yellow for swiss cheese...

I never wanted to let it look like cheese. I use the yellow color only for
modelling and testing a new object or shape, because for me it´s good
visible and not too painfull to look at.

> Hmm, I wonder what a semitransparent Menger sponge would look
> like...it'd probably take a couple years to render with a decent
> recursion level, though. And to get the transparency right, you would
> need to use a completely transparent texture and attenuation (fade_color
> would be useful).

And I want it rendered at 80000x60000 pixels!

Hmmm, let´s wait ´till the 30 GHz processors are available. Then I´ll buy my
own atomic plant and build a big render farm ;-)

Maybe this is a good scene to test the distribute render techniques
currently discussed in povray.general in the large-render-thread. Parsing
time is very short compared to render time (parsing time about 30 seconds,
render time 2 days)

So long,

Bonsai

Post a reply to this message

Chris Huff wrote:

>
> It's too yellow for swiss cheese...
> Hmm, I wonder what a semitransparent Menger sponge would look
> like...it'd probably take a couple years to render with a decent
> recursion level, though. And to get the transparency right, you would
> need to use a completely transparent texture and attenuation (fade_color
> would be useful).
>

Consider rendering a compact subset of R^3 (that is closed and bounded) which
has zero volume but infinite surface area. Thus, it will require infinitely
many recursion levels to trace one single ray accurately through it. And it
would definetely not be transparent, or even semitransparent.

Thus, better and better approximations would tend to a more and more opaque
object which take longer and longer to render. I'd say; skip the
transparency. :)

BTW, the cutaway seems to produce the sierpinsky triangle in the intersection
surface. This might actually be the case!

The menger sponge is actually a generalization of the sierpinsky triangle,
and the s.t. is actually a generalization of the Cantor set. Intuitively, I
think I can see the Cantor set as an intersection between the sponge and some
straight line through it.

Enough rambling, but it _is_ interesting.

~simenkv ( smartass/exessive wiseacre with newly aquired math skills )

Post a reply to this message

"Simen Kvaal" <sim### [at] stressuiono> schrieb im Newsbeitrag
news:3AA8E44A.6218AF06@stress.uio.no...
> Intuitively, I
> think I can see the Cantor set as an intersection between the sponge and
some
> straight line through it.

You´re right. But I think there are only a few lines on the surface (like
the red one in the picture below) that represent the Cantor set. Only a
thought...

Post a reply to this message

Attachments:
Download 'cantorset.jpg' (8 KB)

Preview of image 'cantorset.jpg'

Bonsai wrote:

> ... but I was interested in the inner structures. Took my machine 2 days to
> render at 800x600. I think I have to work on the code...

There was a thread about this some time (years ?) ago. If I remember well, a
solution for optimising the sponge was to run only a small part of it (a 1/8 or
1/81, for instance), and then to replicate the part as needed. The decrease in
parsing and render time was dramatic.
Hope this helps.

G.

--

**********************
http://www.oyonale.com
**********************
Graphic experiments
Pov-ray gallery

Post a reply to this message

Bonsai wrote:
> Maybe this is a good scene to test the distribute render techniques
> currently discussed in povray.general in the large-render-thread. Parsing
> time is very short compared to render time (parsing time about 30 seconds,
> render time 2 days)

What computer (how fast) was used to render such picture? Which
algorithm was used? I managed to render menger with same recursion level
and 800x600 (AA0.3) just little over 12 minutes when isosurface was used
(this was when shader was used for calculation, for as it seems, shader
will outperform user's iso functions).

Post a reply to this message

"Gilles Tran" <tra### [at] inapginrafr> schrieb im Newsbeitrag
news:3AA8FD35.60727F15@inapg.inra.fr...
> Bonsai wrote:
>
> > ... but I was interested in the inner structures. Took my machine 2 days
to
> > render at 800x600. I think I have to work on the code...
>
> There was a thread about this some time (years ?) ago. If I remember well,
a
> solution for optimising the sponge was to run only a small part of it (a
1/8 or
> 1/81, for instance), and then to replicate the part as needed. The
decrease in
> parsing and render time was dramatic.
> Hope this helps.

Yes it did in parts. For the creation of a mengersponge that does not
interact with any other object it is a big increase (now it takes some
minutes to render one at 800x600 with the same complexicity...)

But when I want to do the cut away with a sphere it goes back to the 1 or 2
PPS. From now I can´t say if there is still an increase in rendering speed,
´cause I´m still at work on my 'old and lame' PIII 450 MHz. Can´t wait to
come home and feed my little Athlon with new stuff...

so long and thanks allot,

Bonsai

Post a reply to this message

"Vahur Krouverk" <vah### [at] aetecee> schrieb im Newsbeitrag
news:3AA90733.A7C66D85@aetec.ee...
> Bonsai wrote:
> > Maybe this is a good scene to test the distribute render techniques
> > currently discussed in povray.general in the large-render-thread.
Parsing
> > time is very short compared to render time (parsing time about 30
seconds,
> > render time 2 days)
>
> What computer (how fast) was used to render such picture? Which
> algorithm was used? I managed to render menger with same recursion level
> and 800x600 (AA0.3) just little over 12 minutes when isosurface was used
> (this was when shader was used for calculation, for as it seems, shader
> will outperform user's iso functions).

I wanted to do the sponge in pure csg. So I did a lot of differences, that
resulted in this long rendertime.

Gilles gave me a tricky hint on doing the mengersponge very easy and fast.
My old code is just wasting of electric power and time.   :-(
I don´t want to speak about it anymore.

But now I know that my new Athlon works stable even for days...

Bonsai

Post a reply to this message

Bonsai wrote:

> But when I want to do the cut away with a sphere it goes back to the 1 or 2
> PPS. From now I can´t say if there is still an increase in rendering speed,

What about cutting away the (correctly positioned) individual parts first ? It
should render faster than making the union first and cutting the union after.

One fun thing would be to make the sponge out of triangles... I would render
very quickly I guess.

G.

--

**********************
http://www.oyonale.com
**********************
Graphic experiments
Pov-ray gallery

Post a reply to this message

Gilles Tran schrieb:
> 
> What about cutting away the (correctly positioned) individual parts first ? It
> should render faster than making the union first and cutting the union after.

I´ll give it a try this weekend.

> One fun thing would be to make the sponge out of triangles... I would render
> very quickly I guess.

But what I know from triangles and meshes is that you can´t do CSG operations
with them. But I want to do some csg-ing with this little sponge thing after I
can create it fast enough.

Thanks for the hints again,

Bonsai

Post a reply to this message

Bonsai wrote:
> 
> I wanted to do the sponge in pure csg. So I did a lot of differences, that
> resulted in this long rendertime.
> 

Why differences? You should get *much* faster rendering if you created the
sponge as an union, i.e. stack a lot of little blocks to make up the sponge
structure, instead of progressively cutting holes out of one big block.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Home page http://www.hot.ee/margusrt

Post a reply to this message

In article <3aa8d2db@news.povray.org>, "Bonsai" <bon### [at] b0n541net> 
wrote:

> I never wanted to let it look like cheese. I use the yellow color 
> only for modelling and testing a new object or shape, because for me 
> it´s good visible and not too painfull to look at.

It was supposed to be a joke...I just forgot the smiley. But I do think 
the smaller piece would look at home on a mouse trap...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <3AA8E44A.6218AF06@stress.uio.no>, Simen Kvaal 
<sim### [at] stressuiono> wrote:

> Consider rendering a compact subset of R^3 (that is closed and 
> bounded) which has zero volume but infinite surface area. Thus, it 
> will require infinitely many recursion levels to trace one single ray 
> accurately through it.

Of course, I meant an *approximation* of a Menger sponge...rendering a 
real one would literally take forever, and probably not be that 
interesting.


> And it would definetely not be transparent, or even semitransparent.
> 
> Thus, better and better approximations would tend to a more and more 
> opaque object which take longer and longer to render. I'd say; skip 
> the transparency. :)

Um, with better approximations, the volume the ray passes through will 
decrease, and the sponge will become more and more *transparent*. You 
will get a fainter and fainter image of the sponge, until it is 
invisible. But as I said above, I'm only interested in an approximation, 
maybe 3-5 levels...a real sponge would be impossible.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

>
> Um, with better approximations, the volume the ray passes through will
> decrease, and the sponge will become more and more *transparent*. You
> will get a fainter and fainter image of the sponge, until it is
> invisible. But as I said above, I'm only interested in an approximation,
> maybe 3-5 levels...a real sponge would be impossible.
>

Interesting thought!

I think you're right; it should be invisible.

:)

~simenkv.

Post a reply to this message

Bonsai wrote in message <3AA91E79.770A2F54@b0n541.net>...
> Gilles Tran schrieb:
> > One fun thing would be to make the sponge out of triangles... I would render
> > very quickly I guess.
>
> But what I know from triangles and meshes is that you can´t do CSG operations
> with them. But I want to do some csg-ing with this little sponge thing after I
> can create it fast enough.


such object as mesh should be extremly fast
and you don't need CSG - just clippped_by
remember that copy of mesh not waste memory !
and you can balance between memory and speed by spliting object to smaller cubes
(you must find level) and below size create triangles and above size create
copies of meshes with clipping only some of them

ABX

Post a reply to this message

Simen Kvaal wrote:
> 
> >
> > Um, with better approximations, the volume the ray passes through will
> > decrease, and the sponge will become more and more *transparent*. You
> > will get a fainter and fainter image of the sponge, until it is
> > invisible. But as I said above, I'm only interested in an approximation,
> > maybe 3-5 levels...a real sponge would be impossible.
> >
> 
> Interesting thought!
> 
> I think you're right; it should be invisible.
> 

I tried menger with different level of recursion. Iso-surface
calculation precision may affect results, so they are not definite, but
using recursion level of 40 made sponge disappear completely, level 30
showed only some very faint parts of it. Sponge with level 20 looks like
this:
(sorry about incomplete sponge: I left it on table for overnight and
mice thought that it was cheese and eat some of it. Next time I'll put
in place, where they can not access it! ;o)
Seems like sponge with levels up to 6-8 is acceptable, after this sponge
gets too blurry and loses its beauty.

Post a reply to this message

Attachments:
Download 'menger20.jpg' (20 KB)

Preview of image 'menger20.jpg'

"Vahur Krouverk" <vah### [at] aetecee> wrote :
>
> I tried menger with different level of recursion. Iso-surface
> calculation precision may affect results, so they are not definite, but
> using recursion level of 40 made sponge disappear completely, level 30
> showed only some very faint parts of it.

    Are you saying that this is an isosurface? I have been expecting to see
a fractal isosurface soon but I didn't know one had been made.

Post a reply to this message

Bill DeWitt wrote:
> 
>     Are you saying that this is an isosurface? I have been expecting to see
> a fractal isosurface soon but I didn't know one had been made.

No, I wrote that! :-) Yes, it is isosurface, like this (POVMan 0.7 is
required for running it, more complete example comes with
documentation):

#declare xyf=function{
    shader{
        shader_file "menger.slp"
        "rec_depth" 20
    }
}
isosurface {
    function { 
        xyf
    }
    contained_by { box { -1.0,1.0 } }
    all_intersections
    max_gradient 100
    accuracy 0.001
    texture {
      ...
    } 
    scale 2
}


shader file is as follows:
iso_function menge(float rec_depth = 8){

    float testfirst(output float mx, mn){

        float rv = -1;
        mx *= 3;
        mn *= 3;
        float i;
        extern float rec_depth;
        for (i=0; i<rec_depth;i+=1){
            if(mx<=1 && mn <= 1){
                rv = 1;
                break;
            }
            else{
                mx = abs(mod(mx*3+1, 6) -1);
                mn = abs(mod(mn*3+1, 6) -1);
            }
        }
        return rv;
    }

    float retv = -1;
    if (testfirst(abs(xcomp(P)),abs(ycomp(P))) == 1 ||
        testfirst(abs(xcomp(P)),abs(zcomp(P))) == 1 ||
         testfirst(abs(zcomp(P)),abs(ycomp(P))) == 1)
      retv = 1;

    return retv;
}

Post a reply to this message

"Vahur Krouverk" <vah### [at] aetecee> wrote :L
>
> No, I wrote that! :-) Yes, it is isosurface, like this (POVMan 0.7 is
> required for running it, more complete example comes with
> documentation):
>
> #declare xyf=function{
>     shader{
>         shader_file "menger.slp"
>         "rec_depth" 20
>     }
> }
> isosurface {
>     function {
>         xyf
>     }
>     contained_by { box { -1.0,1.0 } }


    But is it a fractal isosurface or a fractal shader? Seems like a shader
to me, not knowing anything about shaders.

Post a reply to this message

Bill DeWitt wrote:
> 
>     But is it a fractal isosurface or a fractal shader? Seems like a shader
> to me, not knowing anything about shaders.
Shader is probably not the best word for describing this. In version 0.7
I add feature, which allows to use shading language constructs and
virtual machine (which was created for shader byte-code execution) for
computing potential values for isosurfaces. So basically one can write
iso functions in C-like syntax, byte-compile them and use in iso-surface
calculation. As it appears, this works generally faster (2-5 times,
depending from complexity), than functions, which are written directly
in POV-Ray "language". And one can use more advanced features, such as
loops, temporary variables, etc.
Of course shader functions are slower, than built-in (i.e. hard-coded in
source code) iso-functions, about the same margin (2-5 times).
More about this is again in POVMan documentation.

Post a reply to this message

> > Thus, better and better approximations would tend to a more and more 
> > opaque object which take longer and longer to render. I'd say; skip 
> > the transparency. :)
> 
> Um, with better approximations, the volume the ray passes through will 
> decrease, and the sponge will become more and more *transparent*. You 
> will get a fainter and fainter image of the sponge, until it is 
> invisible. But as I said above, I'm only interested in an approximation, 
> maybe 3-5 levels...a real sponge would be impossible.

I'd have thought that would depend on the material being used to make 
said sponge?  With a transparent but reflective material, surely internal 
reflections would build up to the point where they would overpower and 
obscure any view through the sponge?

I could be wrong though...

Bye for now,
     Jamie.

Post a reply to this message

"Vahur Krouverk" <vah### [at] aetecee> wrote :
>
> So basically one can write
> iso functions in C-like syntax, byte-compile them and use in iso-surface
> calculation.

    Ah, now I see. Thanks

Post a reply to this message

In article <MPG.1517399eed9bd1a989897@news.povray.org>, 
jam### [at] ntlworldcom (Jamie Davison) wrote:

> I'd have thought that would depend on the material being used to make 
> said sponge?  With a transparent but reflective material, surely internal 
> reflections would build up to the point where they would overpower and 
> obscure any view through the sponge?

Well, I was specifically talking about transparent sponges, but I think 
that the cross-section area of the sponge will tend toward 0 as the 
surface area tends toward infinity, so a ray (or in the real world, a 
photon) wouldn't be able to hit a perfect sponge, and would just pass 
through it.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <3aad1a13@news.povray.org>, "Bill DeWitt" 
<bde### [at] cflrrcom> wrote:

>     But is it a fractal isosurface or a fractal shader? Seems like a 
> shader to me, not knowing anything about shaders.

It's a fractal isosurface using a fractal shader as a function. It's no 
more a shader than an isosurface that uses a pigment function is a 
pigment. The object is an isosurface, defined as all points where a 
function is equal to a threshold value...the way the function is 
generated doesn't matter.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-012D20.18015012032001@news.povray.org...
> In article <3aad1a13@news.povray.org>, "Bill DeWitt"
> <bde### [at] cflrrcom> wrote:
>
> >     But is it a fractal isosurface or a fractal shader? Seems like a
> > shader to me, not knowing anything about shaders.
>
> It's a fractal isosurface using a fractal shader as a function. It's no
> more a shader than an isosurface that uses a pigment function is a
> pigment. The object is an isosurface, defined as all points where a
> function is equal to a threshold value...the way the function is
> generated doesn't matter.

    Right. I got that, thanks.

    But I am still hoping that someone will make a fractal or pseudo-fractal
isosurface... as well as a good isosurface tree.

Post a reply to this message

In article <3aad6b4e$1@news.povray.org>, "Bill DeWitt" 
<bde### [at] cflrrcom> wrote:

>     But I am still hoping that someone will make a fractal or 
>     pseudo-fractal isosurface...

What's wrong with the Menger sponge isosurface?


> as well as a good isosurface tree.

This would probably be unuseably slow and unwieldly at a complexity high 
enough for it to look like a tree. You might be able to do it with the 
blob pattern in a pigment function, though...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-947071.22170012032001@news.povray.org...
> In article <3aad6b4e$1@news.povray.org>, "Bill DeWitt"
> <bde### [at] cflrrcom> wrote:
>
> >     But I am still hoping that someone will make a fractal or
> >     pseudo-fractal isosurface...
>
> What's wrong with the Menger sponge isosurface?

    Doesn't it need the PovMan version to run? I just barely am willing to
go with the MegaPov.

> > as well as a good isosurface tree.
>
> This would probably be unuseably slow and unwieldly at a complexity high
> enough for it to look like a tree. You might be able to do it with the
> blob pattern in a pigment function, though...

    It's the principal of the thing.

Post a reply to this message

On 2001-03-10 12:23, Chris Huff <chr### [at] maccom> wrote:
>In article <3AA8E44A.6218AF06@stress.uio.no>, Simen Kvaal 
><sim### [at] stressuiono> wrote:
>
>> Thus, better and better approximations would tend to a more and more 
>> opaque object which take longer and longer to render. I'd say; skip 
>> the transparency. :)
>
>Um, with better approximations, the volume the ray passes through will 
>decrease, and the sponge will become more and more *transparent*. You 
>will get a fainter and fainter image of the sponge, until it is 
>invisible. But as I said above, I'm only interested in an approximation, 
>maybe 3-5 levels...a real sponge would be impossible.

I have started one at 4 levels (CSG, no isosurface), but it seems that
this will take a few days (or weeks) to render. At two levels, the
transparent sponge looks rather boring, but the histogram has a mildly
interesting, space-ship-like look, so I'm posting that instead:

Post a reply to this message

Attachments:
Download 'menger-2-t5-h.jpg' (52 KB)

Preview of image 'menger-2-t5-h.jpg'

Margus Ramst wrote:
> 
> Bonsai wrote:
> >
> > I wanted to do the sponge in pure csg. So I did a lot of differences, that
> > resulted in this long rendertime.
> >
> 
> Why differences? You should get *much* faster rendering if you created the
> sponge as an union, i.e. stack a lot of little blocks to make up the sponge
> structure, instead of progressively cutting holes out of one big block.

I did it that way once and while it was faster it wasn't signifigantly
faster. With that many edges you lose a lot of time doing anti-aliasing.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Gilles Tran wrote:
> 
> Bonsai wrote:
> 
> > But when I want to do the cut away with a sphere it goes back to the 1 or 2
> > PPS. From now I can´t say if there is still an increase in rendering speed,
> 
> What about cutting away the (correctly positioned) individual parts first ? It
> should render faster than making the union first and cutting the union after.
> 
> One fun thing would be to make the sponge out of triangles... I would render
> very quickly I guess.

Been there. Done that. Didn't help render times much. Memory use did decrease
however.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Bonsai wrote:

> ... but I was interested in the inner structures. Took my machine 2 days to
> render at 800x600. I think I have to work on the code...

The inner structure is very interesting. :)

There are normally a few ways to speed things up. 1) Make meshes, but you can't
because you 're cutting away a chunk. 2) Use unions instead of real CSG, but
that way you'd get artifacts between edges of adjacent cubes. So you're stuck
with a long render. Unless you have megapov and want to try an isosurface. I
have code for an iso-menger-sponge at my website you can use.

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

Did you try hierarchal bounding for the CSG?

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

"David Fontaine" <dav### [at] faricynet> schrieb im Newsbeitrag
news:3AB### [at] faricynet...
> Did you try hierarchal bounding for the CSG?

Not yet. Do you mean that I should bound smaller parts of the sponge per
hand. Would this really decrease render time when I do the cut away?

Until now I was trying to get my new sponge macro to work. Now I can give
the recursion level, the length of the sponge and where it´s located. The
sponge is now made of many little mengersponges with recursion level 1.

My next idea is to do only differences with the little sponges that
intersect with the sphere and forget the sponges that are inside the sphere.
This should be easy for the sphere. Other objects might be very hard to cut
away with this approach...

Let´s see,

Bonsai

Post a reply to this message

Bonsai wrote:

> Not yet. Do you mean that I should bound smaller parts of the sponge per
> hand. Would this really decrease render time when I do the cut away?

Hmm, I'm not sure exactly how that worked. You split the CSG components into
however many groups, then those into however many smaller groups, etc, and bound
all the groups, with zero or minimal overlap of any two groups at the same
nesting level. Something like:

difference {
   box {}
   merge {
      merge {
         ...
         bounded_by {}
      }
      bounded_by {}
   }
   merge {
      merge {
         ...
         bounded_by {}
      }
      bounded_by {}
   }
   bounded_by {}
}

You could split it into 27 parts (3x3x3), each of the 20 edge parts splits
again... maybe it would be more efficient to split the x axis into three, then
the y, then the z, then start the next recursion level... Essentially you make a
bunch of nested bounding that serves to partition the space into smaller and
smaller pieces. It's very efficient because the intersection algorithim is
essentially "walking the tree". It might be tricky to get it arranged so that
you don't have coincident surfaces or anything.

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message