-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas de Groot wrote:
> Another possibility, I guess, would be to use the boxed or the cylindrical 
> patterns. Maybe cylindrical would be better than spherical in a landscape? 
> What do you think?

I just finished picking apart the code for "Picnic at Giza":
http://www.irtc.org/ftp/pub/stills/2004-08-31/em_giza.jpg

emkaah uses the following heightfield for the sand:
#declare PF0 = pigment{
  bumps
  turbulence 0.1
  color_map { [0 rgb .12] [1 rgb .1] } scale <1,.9,1>*0.1 translate x*-5
}
#declare PF1 = pigment{
  crackle
  form<.86,0,0>
  turbulence 0.4
  color_map { [0 rgb .105] [1 rgb .08] }
  scale <1,.8,10>*0.1
  translate <-2,-1,0>
}
#declare PF2 = pigment{
  bumps
  color_map { [0 rgb .11] [1 rgb .072] }
  scale .2
  translate x*-1
}
#declare PF=function {
  pigment{
    gradient z
    pigment_map{
      [0 PF0]
      [.40 PF0]
      [.50 PF1]
      [.60 PF2]
      [1 PF2]
    }
    turbulence .3
  }
}
#declare sandh1 = height_field{function 600,600 {PF(x,0,y).grey} /* lots
of extraneous parameters removed */ }

So, there's a gradient used as a pattern map, with PF0 being the pattern
in the foreground, PF1 in the midground, and PF2 in the distance.
There's some turbulence to keep the transitions from being too sharp.

PF2 is the pattern for the slope up just before the base of the
pyramids. It's a crackle pattern; that's how he got those neat little
valleys running down the slope.

I also want to fiddle with the source for "Mirage", from the same IRTC
round:
http://www.irtc.org/ftp/pub/stills/2004-08-31/mirage.jpg

What struck me about that image is that there's no doubt that the sand
in the image is *sand*. That's more than you can say for a lot of the
entries in that round. :-P

It's very stylized, but still instantly recognizable as sand.

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu


> >  - Type 0 are tesselated dynamically during render time and the
> > tesselation results are discarded immediately once the intersections
> > are found. In particular, I noticed that POV accessed the u_order
> > and v_order variables and repetitively called the DeCasteljau
> > subdivision functions during intersection computations...

I see.

    -- Warp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHSMnpKrVIcTMekC8RAmNKAJ4y7D43pY6etFSEndPRYTS9MrEo2ACgmukT
pmx/BoFOt404ZlgNF7qw8tI=
=N5xF
-----END PGP SIGNATURE-----

Post a reply to this message