Tesselation

Hgpovray

---

Tesselation

Yoda: Yes, run! Yes, a Jedi\'s strength flows from the Renderer. But beware of the dark side. 
      Mesh, Heightfield, Bicubic Patch; the dark side of the Force are they. Easily they flow, 
      quick to join you in a fight. If once you start down the dark path, 
      forever will it dominate your destiny, consume you it will, as it did Isosurface\'s apprentice.
Luke: Parametric precompute... Is the dark side stronger?
Yoda: No, no, no. Quicker, easier, more seductive.
Luke: But how am I to know the good side from the bad?
Yoda: You will know... when you are calm, at peace, passive. 
      A Jedi uses the Renderer for knowledge and defense, NEVER for attack.
Luke: But tell my why I can\'t...
Yoda: No, no! There is no "why".

Mesh from 3D finite object

• it must be 3D, to have an inside test which is meaningfull
• it must be finite, because the bounding box is use to specify the volume which will be sampled

Whatever the method used (it will always end as a mesh object, or inside a mesh object). there is some common parameters:

• original is followed by the object to sample. It is really mandatory.
• accuracy is followed by a 3D vector which specify the number of slices in each direction (it defaults to 10)

When used inside a Mesh object, the created part of mesh can be painted with explicit texture:

• texture is followed by a texture identifier

Without texture, using only Inside test (fast)

These approaches use a marching cube algorithm, hence their usage were forbidden on the USA thanks to a now expired patent (17 years after December 1987).

• bourke ( inspired by Paul Bourke at http://local.wasp.uwa.edu.au/~pbourke/geometry/polygonise/ , named with explicit authorisation, moved to http://paulbourke.net/geometry/polygonise/ )

• heller ( alternate table from Bourke page made by Geoffrey Heller)

• cubicle (simplistic approach using a cube)

• cristal (same as cubicle, with inclined face)

bourke & heller allow additional options :

• precision with a float, which supersample along the interecting line (by the amount of the float, so only positive integer are of any real interest) for a better fit.
• offset is followed by a float which move outward the position of each face of the bounding box used for scanning (default to 0, so beware of very tight perfect bounding box)

mesh { ...
  (bourke|heller) {
    original finite3D_obj
    [accuracy vector] [precision float] [offset float] [texture { Tid } ]
  }
...
}

OR

(bourke|heller) {
  original finite3D_obj
  [accuracy vector] [precision float] [offset float]

[Object_Mods...]
}

mesh { ...
  (cubicle|cristal) {
    original finite3D_obj
    [accuracy vector] [texture { Tid } ]
  }
...
}

OR

(cubicle|cristal) {
  original finite3D_obj
  [accuracy vector]

[Object_Mods...]
}

Using Inside test & trace (slower)

No marching cube per itself here, the inside test is used to trigger the usage of trace to get the actual intersection.

• tesselate

 mesh { ...
  tesselate { 
    original finite3D_obj
    [accuracy vector] [albinos] [offset float] [smooth] [texture { Tid }]
  }
 ...
 }

OR

 tesselate { 
   original finite3D_obj
   [accuracy vector] [albinos] [offset float] [smooth] 

 [Object_Mods...]
 }

• tessel

 mesh { ...
  tessel { 
    original finite3D_obj
    [accuracy vector] [albinos] [offset float] [smooth] [texture { Tid }]
  }
 ...
 }

OR

 tessel { 
   original finite3D_obj
   [accuracy vector] [albinos] [offset float] [smooth] 

 [Object_Mods...]
 }

As trace is used, the texture from the intersection point is available and can be pushed on the vertex of each generated triangle. This can be prevented with the use of the albinos option.

• a possible parameter is smooth which would also use the normal reported by the intersection to make smooth_triangle instead of triangle in the resulting mesh.
• offset is followed by a float which move outward the position of each face of the bounding box used for scanning (default to 0, so beware of very tight perfect bounding box)

Mesh from and to file

Loading

A GTS file can be loaded with gts_load.

#include "colors.inc"
camera { location <3,5,-4>
	direction z
		up y
		right image_width/image_height*x
		look_at <-1/2,1/2,0>
		angle 35
}

light_source{ <-5, 20, -20>, 1}
light_source{ <0, 2, 0>, 1/2}

gts_load{ "bunny.gts"
	right
	rotate 180*y
	scale 17
	translate -2*y
	texture { pigment { color Aquamarine}}
}

Aside from the filename of the file to load, the right keyword can be used to change the default left-handed coordinate system to a right-handed one.

gts_load can be used to create a mesh of its own or to incorporate the mesh of the file into a larger mesh, in which case a texture identifier can be applied over the loaded GTS mesh.

 mesh { ...
    gts_load { filename [right] [texture { Tid }] }
  ...
 }

OR

 gts_load { filename [right] 

 [Object_Mods...]
 }

Saving

GTS

A mesh can be saved with gts_save. Beware of I/O restrictions.

gts_save { filename, mesh_object }

GTS format saves the geometry, but neither the faked normal or the textures or transformations.

STL

A mesh can be saved with stl_save. Beware of I/O restrictions.

stl_save { filename, mesh_object }

STL format saves the geometry, but neither the faked normal or the textures or transformations and so far stl_save does not save any colour information.

• The pov-unit are mapped directly as the stl-unit.
• stl is usually a right-handed coordinate system, so keep it in mind when creating the mesh to save

Transformations

bend

displace

keep

move

planet

roll

screw

smooth

warp