User:Le Forgeron/tesselation

• Everything about HgPovray38 in User:Le_Forgeron/HgPovray38
• Not yet available

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

See also User:Le_Forgeron/UVMeshable

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

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)

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)