Reference:Mesh - Revision history

Jholsenback: indexentries fixes

2016-12-16T18:49:45Z

indexentries fixes

Jholsenback: removed wavefront entries

2016-12-13T12:39:37Z

removed wavefront entries

Jholsenback: punctuation

2016-09-14T21:35:48Z

punctuation

Jholsenback: clarification

2016-09-14T21:20:49Z

clarification

Jholsenback: awkward edits

2016-09-14T21:11:54Z

awkward edits

Jholsenback: update

2016-09-14T20:23:55Z

update

Jholsenback: 3.7.1 updates

2016-09-14T19:52:09Z

3.7.1 updates

Jholsenback: 1 revision: underscore link repair

2012-07-17T18:09:18Z

1 revision: underscore link repair

Jholsenback: still testing that theory

2012-07-16T12:18:49Z

still testing that theory

Jholsenback: 1 revision: Reference Migration Initial Load

2012-03-15T19:07:30Z

1 revision: Reference Migration Initial Load

@@ Line 62: / Line 62: @@
 <p>Copies of a mesh object refer to the same triangle data and thus consume very little memory. You can easily trace a hundred copies of a 10000 triangle mesh without running out of memory (assuming the first mesh fits into memory). The mesh object has two advantages over a union of triangles: it needs less memory and it is transformed faster. The memory requirements are reduced by efficiently storing the triangles vertices and normals. The parsing time for transformed meshes is reduced because only the mesh object has to be transformed and not every single triangle as it is necessary for unions.</p>
 {{#indexentry:inside_vector}}
 {{#indexentry:solid triangle mesh}}
 <p>The triangle mesh objects <code>mesh</code> (and <code>mesh2</code>) can be used in CSG objects such as difference and intersect. Adding the <code>inside_vector</code> they do have a defined <em>inside</em>. This will only work for well-behaved meshes, which are completely closed volumes. If meshes have any holes in them, this might work, but the results are not guaranteed.</p>

@@ Line 13: / Line 13: @@
 {{#indexentry:smooth_triangle, mesh}}
 {{#indexentry:keyword, smooth_triangle}}
-{{#indexentry:mesh, wavefront}}
+<p>The <code>mesh</code> object can be used to efficiently store large numbers of triangles.</p>
 <p>The syntax is:</p>
 <pre>
@@ Line 24: / Line 20: @@
      MESH_TRIANGLE...
      [MESH_MODIFIER...]
+     }
@@ Line 48: / Line 39: @@
    inside_vector &lt;direction&gt; | hierarchy [ Boolean ] |
    OBJECT_MODIFIER
 MESH_TEXTURE:
@@ Line 89: / Line 72: @@
 </pre>
 <p>This change does not have any effect on unions of triangles, these will still be always hollow.</p>

@@ Line 96: / Line 96: @@
 <p>{{New}} to version 3.7.1 support has been added to allow importing Wavefront (OBJ) files.</p>
 <p>Wavefront (OBJ) import provides rudimentary support for non-triangular polygons, but currently just blindly cuts up such polygons into triangles, relying on the polygons to be nicely planar and convex. This may also affect the apparent curvature of such polygons.</p>
-<p>At present, associated material (MTL) files will <em>NOT</em> be evaluated instead, textures must be defined using one of the following means:</p>
+<p>At present associated material (MTL) files will <em>NOT</em> be evaluated instead textures must be defined using one of the following means:</p>
 <ol>
    <li>in the <code>texture_list</code> as a list of the individual material names as used in the .obj file and the respective texture definition to use</li>

@@ Line 96: / Line 96: @@
 <p>{{New}} to version 3.7.1 support has been added to allow importing Wavefront (OBJ) files.</p>
 <p>Wavefront (OBJ) import provides rudimentary support for non-triangular polygons, but currently just blindly cuts up such polygons into triangles, relying on the polygons to be nicely planar and convex. This may also affect the apparent curvature of such polygons.</p>
-<p>At present, associated .mtl files will <em>not</em> be evaluated instead, textures must be defined using one of the following means:</p>
+<p>At present, associated material (MTL) files will <em>NOT</em> be evaluated instead, textures must be defined using one of the following means:</p>
 <ol>
    <li>in the <code>texture_list</code> as a list of the individual material names as used in the .obj file and the respective texture definition to use</li>
    <li>before the <code>mesh</code> keyword, by defining texture variables with corresponding names. For some ease of use, a <code>prefix</code> and <code>suffix</code> can be defined that will be added to the material name as used in the .obj file</li>
 </ol>
-<p>For additional ease of use materials can be used instead of textures, however, in that case only the texture is taken from the material. The <code>interior_texture</code> and interior are ignored.</p>
+<p>For additional ease of use materials can be used instead of textures, in that case only the texture is taken from the material. The <code>interior_texture</code> and <code>interior</code> of the material are ignored.</p>
-<p>In the following example:</p>
+<p>The following example:</p>
 <pre>
 #declare MyTexture = texture { ... }

@@ Line 17: / Line 17: @@
 {{#indexentry:mesh, obj}}
 {{#indexentry:obj, mesh}}
-<p>The <code>mesh</code> object can be used to efficiently store large numbers of triangles, however, {{New}} to version 3.7.1 the <code>mesh</code> object has been extended to include support for importing Wavefront (OBJ) files.</p>
+<p>The <code>mesh</code> object can be used to efficiently store large numbers of triangles. Version 3.7.1 extended the <code>mesh</code> object by adding a {{New}} feature that supports importing Wavefront (OBJ) files.</p>
 <p>The syntax is:</p>
 <pre>

@@ Line 12: / Line 12: @@
 {{#indexentry:keyword, triangle}}
 {{#indexentry:smooth_triangle, mesh}}
 {{#indexentry:keyword, smooth_triangle}}
 <p>The <code>mesh</code> object can be used to efficiently store large
 numbers of triangles. Its syntax is:</p>
@@ Line 20: / Line 24: @@
      MESH_TRIANGLE...
      [MESH_MODIFIER...]
+     }
 MESH_TRIANGLE:
    triangle {
@@ Line 27: / Line 37: @@
      [MESH_TEXTURE]
      } |
    smooth_triangle {
      &lt;Corner_1&gt;, &lt;Normal_1&gt;,
@@ Line 35: / Line 44: @@
      [MESH_TEXTURE]
+     }
 MESH_TEXTURE:
    texture { TEXTURE_IDENTIFIER }
@@ Line 40: / Line 62: @@
      TEXTURE_IDENTIFIER TEXTURE_IDENTIFIER TEXTURE_IDENTIFIER
+     }
 </pre>
@@ Line 52: / Line 70: @@
 </pre>
-<p>Any number of <code>triangle</code> and/or <code>smooth_triangle</code>
+<p>Any number of <code>triangle</code> and/or <code>smooth_triangle</code> statements can be used and each of those triangles can be individually textured by assigning a texture identifier to it. The texture has to be declared before the mesh is parsed. It is not possible to use texture definitions inside the triangle or smooth triangle statements. This is a restriction that is necessary for an efficient storage of the assigned textures. See [[Reference:Triangle Texture Interpolation|Triangle and Smooth Triangle]] for more information on triangles.</p>
-statements can be used and each of those triangles can be individually
+<p>The <code>mesh</code> object can support <code>uv_mapping</code>. For this, per triangle the keyword <code>uv_vectors</code> has to be given, together with three 2D uv-vectors. Each vector specifies a location in the xy-plane from which the texture has to be mapped to the matching points of the triangle. Also see the section [[Reference:UV Mapping|:uv_mapping|uv_mapping]].</p>
 {{#indexentry:hierarchy, mesh}}
 {{#indexentry:keyword, hierarchy}}
-<p>The mesh's components are internally bounded by a bounding box hierarchy
+<p>The mesh's components are internally bounded by a bounding box hierarchy to speed up intersection testing. The bounding hierarchy can be turned off with the <code>hierarchy off</code> keyword. This should only be done if memory is short or the mesh consists of only a few triangles. The default is <code>hierarchy on</code>.</p>
-<p>Copies of a mesh object refer to the same triangle data and thus consume
+<p>Copies of a mesh object refer to the same triangle data and thus consume very little memory. You can easily trace a hundred copies of a 10000 triangle mesh without running out of memory (assuming the first mesh fits into memory). The mesh object has two advantages over a union of triangles: it needs less memory and it is transformed faster. The memory requirements are reduced by efficiently storing the triangles vertices and normals. The parsing time for transformed meshes is reduced because only the mesh object has to be transformed and not every single triangle as it is necessary for unions.</p>
 {{#indexentry:inside_vector}}
 {{#indexentry:solid triangle mesh}}
@@ Line 95: / Line 89: @@
 </pre>
 <p>This change does not have any effect on unions of triangles, these will still be always hollow.</p>

← Older revision	Revision as of 18:09, 17 July 2012
(No difference)

← Older revision	Revision as of 19:07, 15 March 2012
(No difference)