Here is a small .pov script to fill the landscape
with boxes whose heights are random.  It resembles the
effect of using the megapov "cells" pattern in a height field
or isosurface, except it uses features of the Official
povray 3.1.
        The trick is to use a mesh to generate a block
of "cells", and then tile that to give the appearance of
an infinite field of boxes.

--
/* that cells pigment in megapov looks cool, especially
   when used as an isosurface or high field.  Here we fake
   a cells pigment heightfield by placing a lot of boxes */


global_settings {
  number_of_waves 9
  assumed_gamma 2.4
}


#declare ntsc = false;
#declare rseed = seed(17987092);


#macro rnd_rotate()
  rotate <360 * rand(rseed), 360 * rand(rseed), 360 * rand(rseed)>
#end


#macro rnd_translate()
  translate <4 - 8 * rand(rseed), 4 - 8 * rand(rseed), 4 - 8 * rand(rseed)>
#end


#macro perturb()
  rnd_translate()
  rnd_rotate()
#end


background { color rgb <0, 0.2, 1> * 0.3 }


sky_sphere {
  pigment {
    granite
    perturb()
    scale 1/2
    color_map {
      [ 0.0 color rgbt 1 ]
      [ 0.9 color rgbt 1 ]
      [ 0.9 color rgbt <1, 1, 1, 0> ]
      [ 1.0 color rgbt <1, 1, 1, 0> ]
    }
  }
}


camera {
  location 0
  direction <0, 0, 1> // zoom factor
  up  <0, 1, 0>
  #if (ntsc = true)
    right <(320 / 200) * (10 / 11), 0, 0>
  #else
    right <(640 / 480), 0, 0>
  #end
  rotate x*12
  rotate y*-18
  translate <2, 4, -10>
}


#macro do_box(c1, c2) // same parameter format as for a box object
  // back wall
  triangle { c1, <c2.x, c1.y, c1.z>, <c2.x, c2.y, c1.z> }
  triangle { c1, <c2.x, c2.y, c1.z>, <c1.x, c2.y, c1.z> }
  // left wall
  triangle { c1, <c1.x, c1.y, c2.z>, <c1.x, c2.y, c2.z> }
  triangle { c1, <c1.x, c2.y, c2.z>, <c1.x, c2.y, c1.z> }
  // right wall
  triangle { <c2.x, c1.y, c2.z>, <c2.x, c1.y, c1.z>, c2 }
  triangle { <c2.x, c1.y, c1.z>, c2, <c2.x, c2.y, c1.z> }
  // bottom
  triangle { <c1.x, c2.y, c2.z>, <c1.x, c2.y, c1.z>, <c2.x, c2.y, c1.z> }
  triangle { <c1.x, c2.y, c2.z>, <c2.x, c2.y, c1.z>, c2 }
  // top
  triangle { <c1.x, c1.y, c2.z>, c1, <c2.x, c1.y, c1.z> }
  triangle { <c1.x, c1.y, c2.z>, <c2.x, c1.y, c1.z>, <c2.x, c1.y, c2.z> }
  // front
  triangle { <c1.x, c1.y, c2.z>, <c2.x, c1.y, c2.z>, c2 }
  triangle { <c1.x, c1.y, c2.z>, c2, <c1.x, c2.y, c2.z> }
#end


#declare csize = 48;


/* place csize x csize boxes */
/* first make a random csize x csize "tile" of boxes as one mesh */
#render "\n"
#declare tile1 = mesh {
  #declare xx = 0;
  #while (xx < csize)
    #render concat(str(xx, 0, 0), " of ", str(csize, 0, 0), "\n")
    #declare zz = 0;
    #while (zz < csize)
      #local boxheight = rand(rseed);
      do_box( <xx, 0, zz>, <xx + 1, boxheight * boxheight, zz + 1> )
      #declare zz = zz + 1;
    #end
    #declare xx = xx + 1;
  #end
}


#render "\nMesh built - now placing copies of it\n"


/* now place randomly rotated copies of the mesh */
#declare hcsize = csize / -2;
#declare msize = 15;
union {
  #declare xx = 1 - msize;
  #while (xx < msize)
    #declare zz = 1 - msize;
    #while (zz < msize)
      #declare zz = zz + 1;
      object {
        tile1
        translate <hcsize, 0, hcsize>
        rotate y*90*int(4 * rand(rseed))
        translate <xx * csize, 0, zz * csize>
      }
    #end
    #declare xx = xx + 1;
  #end
  pigment {
    color rgb 1
  }
  finish { ambient 0.5 diffuse 0.5 }
}


light_source {
  <-1000.0, 1200.0, -900.0>
  color red 0.6 green 0.5 blue 0.4
}
light_source {
  <1060.0, 1100.0, -700.0>
  color red 0.4 green 0.5 blue 0.6
}


//end of this file

Post a reply to this message

Isn't it incredible how fast this renders?

  There are more than 23 millions of triangles (exactly 23251968) in the
scene and it took 40 seconds to render at 640x480.

  I suppose that if you had used cubes instead of triangles (so there
would have been almost 2 million cubes in the scene) it would have taken
hours to render.

  I actually tried using boxes instead of triangles and run out of memory,
so I couldn't test how much time it would have taken.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote:


>  Isn't it incredible how fast this renders?

        Yup.

>  There are more than 23 millions of triangles (exactly 23251968) in the
>scene and it took 40 seconds to render at 640x480.

        I'm glad I didn't do that calculation, or I would have been
afraid to render it!

>  I suppose that if you had used cubes instead of triangles (so there
>would have been almost 2 million cubes in the scene) it would have taken
>hours to render.

        My machine would have keeled over.

>  I actually tried using boxes instead of triangles and run out of memory,
>so I couldn't test how much time it would have taken.

>--
>main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
>):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

        Something about how pov handles meshes is realy efficient
time-wise as well as memory-wise.  I guess that's why Gilles'
grass macro can make a prarie so fast, it is all meshes.

        Since posting that .pov file, I have been playing around with
variations on the mesh-to infinity process.  :-).
        Here is a .pov script that tiles larger more complex
shapes.  Enjoy.

--

global_settings {
  assumed_gamma 2.4
  number_of_waves 9
}


#declare ntsc = false;
#declare rseed = seed(39275360);


camera {
  location 0
  direction <0, 0, 1> //
  up < 0, 1, 0 >
  #if (ntsc = true)
    right <(640 / 400) * (10/11), 0, 0 >
  #else
    right <(640/480), 0, 0>
  #end
  rotate x*20  // positive to tilt down
  rotate y*30  // positive to turn to the right
  translate <8.05, 10, -3.0>
}


#macro rnd_rotate()
  rotate <360 * rand(rseed), 360 * rand(rseed), 360 * rand(rseed)>
#end


#macro perturb()
  translate <4 - 8 * rand(rseed), 4 - 8 * rand(rseed), 4 - 8 * rand(rseed)>
  rnd_rotate()
#end


sky_sphere { // stars
  pigment {
    bozo
    turbulence 2.21
    perturb()
    color_map {
      [ 0.0 color red 0 green 0 blue 0 ]
      [ 1/2 color red 0 green 0 blue 0 ]
      [ 3/4 color rgb <0, 0.1, 1> * 0.25 ]
      [ 1.0 color rgb <0.5, 0, 1> * 0.5 ]
    }
  }
  pigment {
    granite
    scale 1/100
    color_map {
      [ 0.0 color rgbt <1, 1, 1, 1> ]
      [ 0.75 color rgbt <1, 1, 1, 1> ]
      [ 0.75 color rgb 1 ]
      [ 1.0 color rgb 1 ]
    }
  }
}


#macro do_box(c1, c2) // same parameter format as for a box object
  // back wall
  triangle { c1, <c2.x, c1.y, c1.z>, <c2.x, c2.y, c1.z> }
  triangle { c1, <c2.x, c2.y, c1.z>, <c1.x, c2.y, c1.z> }
  // left wall
  triangle { c1, <c1.x, c1.y, c2.z>, <c1.x, c2.y, c2.z> }
  triangle { c1, <c1.x, c2.y, c2.z>, <c1.x, c2.y, c1.z> }
  // right wall
  triangle { <c2.x, c1.y, c2.z>, <c2.x, c1.y, c1.z>, c2 }
  triangle { <c2.x, c1.y, c1.z>, c2, <c2.x, c2.y, c1.z> }
  // bottom
  triangle { <c1.x, c2.y, c2.z>, <c1.x, c2.y, c1.z>, <c2.x, c2.y, c1.z> }
  triangle { <c1.x, c2.y, c2.z>, <c2.x, c2.y, c1.z>, c2 }
  // top
  triangle { <c1.x, c1.y, c2.z>, c1, <c2.x, c1.y, c1.z> }
  triangle { <c1.x, c1.y, c2.z>, <c2.x, c1.y, c1.z>, <c2.x, c1.y, c2.z> }
  // front
  triangle { <c1.x, c1.y, c2.z>, <c2.x, c1.y, c2.z>, c2 }
  triangle { <c1.x, c1.y, c2.z>, c2, <c1.x, c2.y, c2.z> }
#end


#macro do_quad(c1, c2, c3, c4) // clockwise or counterclockwise order, not
col-row order
  triangle { c1, c2, c3 }
  triangle { c1, c3, c4 }
#end


#macro do_poly(numpts, pts)  // pts is an array of points in clockwise or
counterclockwise
// order.  Also: the polygon had better be convex (as in Opticks)
// it can nadle noncoplaner although the results might be a bit wrinkly
  #local cc = 1;
  #while (cc < (numpts - 1))
    triangle {
      pts[0],
      pts[cc],
      pts[mod(cc + 1, numpts)]
    }
    #local cc = cc + 1;
  #end
#end


#macro rotate_vector_y(invect, roty)
  #local rady = radians(roty);
  <
   cos(rady) * invect.x - sin(rady) * invect.z,
   invect.y,
   sin(rady) * invect.x + cos(rady) * invect.z
  >
#end


#macro rotate_vector_x(invect, rotx)
  #local radx = radians(rotx);
  <
   invect.x,
   cos(radx) * invect.y - sin(radx) * invect.z,
   sin(radx) * invect.y + cos(radx) * invect.z
  >
#end


#macro rotate_vector_z(invect, rotz)
  #local radz = radians(rotz);
  <
   cos(radz) * invect.x - sin(radz) * invect.y,
   sin(radz) * invect.x + cos(radz) * invect.y,
   invect.z
  >
#end


// the do_cylinder_x macro fakes a cyilnder using many triangles.
// Normally, this is a silly thing to do in povray as povray
// will make mathematically perfect cylinders.  The only sane
// reason for making a cylinder out of triangles is for inclusion
// into a larger mesh object that will be repeated *many* times.
// A mesh saves memory when repeated *many* times.
#macro do_cylinder_x( x1, x2, yy, zz, c_radius, num_pts)
  #local pts1 = array[num_pts]
  #local pts2 = array[num_pts]
  #local rotx = 0;
  #while (rotx < num_pts)
    #local pts1[rotx] = <
      0,
      c_radius * cos(radians(rotx * (360 / num_pts))),
      c_radius * sin(radians(rotx * (360 / num_pts)))
    >;
    #local pts2[rotx] = pts1[rotx];
    #local pts1[rotx] = pts1[rotx] + <x1, yy, zz>; // translate
    #local pts2[rotx] = pts2[rotx] + <x2, yy, zz>; // translate
    #local rotx = rotx + 1;
  #end
  do_poly(num_pts, pts1)
  do_poly(num_pts, pts2)
  // Ok. endcaps are done.  Now for tubular part
  #local rotx = 0;
  #while (rotx < num_pts)
    do_quad(
      pts1[rotx],
      pts2[rotx],
      pts2[mod(rotx + 1, num_pts)],
      pts1[mod(rotx + 1, num_pts)]
    )
    #local rotx = rotx + 1;
  #end
#end


#macro do_cylinder_y( y1, y2, xx, zz, c_radius, num_pts)
  #local pts1 = array[num_pts]
  #local pts2 = array[num_pts]
  #local roty = 0;
  #while (roty < num_pts)
    #local pts1[roty] = <
      c_radius * cos(radians(roty * (360 / num_pts))),
      0,
      c_radius * sin(radians(roty * (360 / num_pts)))
    >;
    #local pts2[roty] = pts1[roty];
    #local pts1[roty] = pts1[roty] + <xx, y1, zz>; // translate
    #local pts2[roty] = pts2[roty] + <xx, y2, zz>; // translate
    #local roty = roty + 1;
  #end
  do_poly(num_pts, pts1)
  do_poly(num_pts, pts2)
  // Ok. endcaps are done.  Now for tubular part
  #local roty = 0;
  #while (roty < num_pts)
    do_quad(
      pts1[roty],
      pts2[roty],
      pts2[mod(roty + 1, num_pts)],
      pts1[mod(roty + 1, num_pts)]
    )
    #local roty = roty + 1;
  #end
#end


#macro do_cylinder_z( z1, z2, xx, yy, c_radius, num_pts)
  #local pts1 = array[num_pts]
  #local pts2 = array[num_pts]
  #local rotz = 0;
  #while (rotz < num_pts)
    #local pts1[rotz] = <
      c_radius * cos(radians(rotz * (360 / num_pts))),
      c_radius * sin(radians(rotz * (360 / num_pts))),
      0
    >;
    #local pts2[rotz] = pts1[rotz];
    #local pts1[rotz] = pts1[rotz] + <xx, yy, z1>; // translate
    #local pts2[rotz] = pts2[rotz] + <xx, yy, z2>; // translate
    #local rotz = rotz + 1;
  #end
  do_poly(num_pts, pts1)
  do_poly(num_pts, pts2)
  // Ok. endcaps are done.  Now for tubular part
  #local rotz = 0;
  #while (rotz < num_pts)
    do_quad(
      pts1[rotz],
      pts2[rotz],
      pts2[mod(rotz + 1, num_pts)],
      pts1[mod(rotz + 1, num_pts)]
    )
    #local rotz = rotz + 1;
  #end
#end


#declare t1 = mesh {
  #declare xx = -5;
  #while (xx < 5)
    do_box(<-5, 1, xx>, <5, 0.9, xx + 0.1> ) // ceiling crosspeice
    do_box(<xx, 1, -5>, <xx + 0.1, 0.9, 5> ) // ceilign crosspeice
    #declare zz = -5;
    #while (zz < 5)
      do_box(<xx, 0, zz>, <xx + 0.1, 0.91, zz + 0.1> ) // upright beam
      #declare zz = zz + 1;
    #end
    #declare xx = xx + 1;
  #end
}


#declare t2 = mesh {
  #declare xx = -5;
  #while (xx < 5)
    do_box(<-5, 1, xx>, <5, 0.9, xx + 0.1> ) // ceiling crosspeice
    do_box(<xx, 1, -5>, <xx + 0.1, 0.9, 5> ) // ceilign crosspeice
    do_box(<-5, 2, xx>, <5, 1.9, xx + 0.1> ) // ceiling crosspeice
    do_box(<xx, 2, -5>, <xx + 0.1, 1.9, 5> ) // ceilign crosspeice
    #declare zz = -5;
    #while (zz < 5)
      do_box(<xx, 0, zz>, <xx + 0.1, 1.91, zz + 0.1> ) // upright beam
      #declare zz = zz + 1;
    #end
    #declare xx = xx + 1;
  #end
}


#declare t4 = mesh {
  #declare xx = -5;
  #while (xx < 5)
    #declare yy = 0;
    #while (yy < 4)
      do_box(<-5, yy + 1, xx>, <5, yy + 0.9, xx + 0.1> ) // ceiling crosspeice
      do_box(<xx, yy + 1, -5>, <xx + 0.1, yy + 0.9, 5> ) // ceiling crosspeice
      #declare yy = yy + 1;
    #end
    #declare zz = -5;
    #while (zz < 5)
      do_box(<xx, 0, zz>, <xx + 0.1, 3.91, zz + 0.1> ) // upright beam
      #declare zz = zz + 1;
    #end
    #declare xx = xx + 1;
  #end
}


#declare t8 = mesh {
  #declare xx = -5;
  #while (xx < 5)
    #declare yy = 0;
    #while (yy < 8)
      do_box(<-5, yy + 1, xx>, <5, yy + 0.9, xx + 0.1> ) // ceiling crosspeice
      do_box(<xx, yy + 1, -5>, <xx + 0.1, yy + 0.9, 5> ) // ceiling crosspeice
      #declare yy = yy + 1;
    #end
    #declare zz = -5;
    #while (zz < 5)
      do_box(<xx, 0, zz>, <xx + 0.1, 7.91, zz + 0.1> ) // upright beam
      #declare zz = zz + 1;
    #end
    #declare xx = xx + 1;
  #end
}


# render "\ndone building meshes, now placing them\n"
#declare zz = 0;
#while (zz < 65)
  #declare xx = 0;
  #while (xx < 65)
    object {
      #declare wo = int(4 * rand(rseed));
      #switch (wo)
        #case (0)
          t1
          #break
        #case (1)
          t2
          #break
        #case (2)
          t4
          #break
        #else
          t8
      #end
      pigment { rgb <0.9, 0.4, 0.2> }
      finish { ambient 0.4 diffuse 0.6 }
      translate <xx * 10, 0, zz * 10>
    }
    #declare xx = xx + 1;
  #end
  #declare zz = zz + 1;
#end


plane { // ground
  <0, 1, 0>, 0
  pigment { color rgb 0.8 }
  finish { ambient 0.5 diffuse 0.5 }
}


light_source {
  <3000, 3000, -3000>
  color rgb 0.5
}
light_source {
  <-2000, 2900, -2200>
  color rgb 0.5
}


/* actual end of this file */

Post a reply to this message

Pete <Pet### [at] nymaliasnet> wrote:
:         Something about how pov handles meshes is realy efficient
: time-wise as well as memory-wise.

  If you are interested on how povray can do it, here is some explanation
(AFAIK):

  - Memory usage:

  Firstly, the mesh is kept in memory in a quite compact format. The structure
of this format is very similar to the mesh2 format in megapov, that is, the
vertex points and triangles are kept separately. If more than one triangle
share a vertex point, this point is stored only once. I use this technique
myself in the PCM format.
  (Of course the actual values are kept in floating point format in memory,
so each one takes about 8 bytes of memory in most systems. The triangles are
groups of 3 (normal triangle) or 6 (smooth triangle) indices, which are
probably 4 bytes each in most systems.)
  I haven't calculated any specific values, but a regular mesh in povray
format will take probably less than 1/10 or 1/20 or even less memory compared
to the file size where the mesh is in ascii format (supposing that the file
contains the entire raw mesh, not one that calculates the mesh).
  The worst case is when all triangles are separate, ie. none of them share
any point with other triangles (this may be the case with, for example, the
leaves of a tree where each leaf is one triangle).
  The more vertices a triangle shares with other triangles, the less memory
it will take.

  Another great memory optimization happens when a mesh is copied (I think
this is the most known one).
  When a mesh is declared and then several copies of this mesh identifier
are used, only one copy of the mesh is kept in memory and all those
copies just refer to it. The size of one of these references is very minimal
(something like 100 bytes or so; I don't know the exact amount).
  This means that you can have a 10 Megabytes big mesh and create 100 copies
of it an still it will take 10 Megabytes of memory (and some bytes more).

  What I don't understand why this copy optimization is not made with other
objects as well (like big CSG and so on).

  - Rendering speed:

  The rendering speed optimization of a triangle mesh in povray can be quite
marvelous.
  You can test it:
  Make an object (eg. a sphere) made with about 10 triangles and render it.
  Then make the same object (so that its size on screen is approximately the
same) with about 100 triangles, render it and compare the rendering time.
  Then make it with 1000 triangles. Then with a million triangles.

  You will be surprised how small the rendering time increase is. The sphere
made with 1 million triangles renders surprisingly fast compared to the
sphere made with 10 triangles (of course the parse time increases a lot, but
that's normal and not important here).
  I have tested this once but I don't remember the results. I think that the
sphere with 1 million triangles didn't take even twice the time the sphere
made of 10 triangles took.

  In your case rendering more than 23 millions of triangles doesn't take much
more than rendering just some thousands of them (or some hundreds). That's
why you can make so big "landscapes" with it without the rendering time going
to the roof.

  As far as I know, the trick here is using a specialized structure: An
octree.
  An octree splits the mesh boundary (which is a box) into 8 equally sized
blocks (also boxes). Then each one of them is split into 8 equally sized
blocks as well, and so on.
  When a ray hits the boundary box of the mesh, then povray looks which one
of those 8 blocks did it hit. Then it concentrates on that block and forgets
the others. This means that in the average it can forget about 87.5% of the
triangles (eg. if there are 1 million triangles in the mesh it can forget
about 875000 of them).
  After this it looks which sub-block did it hit. Again, it can forget about
87.5% of the triangles of that block when it goes to the sub-block.
  And so on. It does this until it finds a block that is empty (so that it
can just forget it and follow the ray to the next block it hits) or it only
has one triangle. Calculating the intersection of the ray with this one
triangle is easy and fast (if the ray didn't hit the triangle it just continues
as if the block was empty).

  The fact that it can forget about 87.5% of the triangles each time it goes
to a sub-block makes it extremely fast. The principle is the same as in
the binary search of tables, but faster (the binary search forgets only
50% of the values when it takes a step).
  Of course the number of blocks in the entire mesh increases when the number
of triangles increases, but the number of blocks increases very slowly
compared to the increase of triangles.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

I wonder how fast renderers like 3DStudio are when there are hundreds of
millions of triangles in the scene. Anyone knows?
  Do they slow down a lot when the number of triangles increases to hundreds
of millions or do they, as povray, render at approximately the same speed?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Thanks!

Post a reply to this message

What's with the camera settings?

When I changed them (deleted terms) and added radiosity, I get a vista buffer
error about non-perpendicular camera vectors.

Post a reply to this message

Nevermind.  I was not used to seeing the term "direction" and was trying
to use it if it were the "look_at" directive; I didn't read your code
thoroughly........

Post a reply to this message

Warp, thanks for the info!  In the mean time I have been
continuing my experiments with huge mesh tilings.  I'm just about
to post another source file of cubes tiled in 3D (down as well as
North & East, hehheh) to the horizon.
        Subject "tiling to infinity 3d".

Pete

Post a reply to this message

>Nevermind.  I was not used to seeing the term "direction" and was trying
>to use it if it were the "look_at" directive; I didn't read your code
>thoroughly........

It's old style camera syntax from back when povray was a still
DKB render.  It's harder to work with at first but gives you
more control over the camera placement/orientation/aspect-ratio.


Pete

Post a reply to this message