Jholsenback: preserving obj import entries for later use

2016-12-13T12:29:28Z

preserving obj import entries for later use

Jholsenback: initial creation

2016-09-14T20:09:29Z

initial creation

New page

<p>Discussion / changes here ...</p>

← Older revision		Revision as of 12:29, 13 December 2016
Line 1:		Line 1:
−	<p>~~Discussion~~ / ~~changes here~~ ...</p>	+	[[Category:Objects]]
		+	[[Category:Finite Patch Primitives]]
		+	{{#indexentry:mesh, keyword}}
		+	{{#indexentry:keyword, mesh}}
		+	{{#indexentry:uv_vectors, mesh}}
		+	{{#indexentry:keyword, uv_vectors}}
		+	{{#indexentry:texture_list, mesh}}
		+	{{#indexentry:keyword, texture_list}}
		+	{{#indexentry:inside_vector, mesh}}
		+	{{#indexentry:keyword, inside_vector}}
		+	{{#indexentry:triangle, mesh}}
		+	{{#indexentry:keyword, triangle}}
		+	{{#indexentry:smooth_triangle, mesh}}
		+	{{#indexentry:keyword, smooth_triangle}}
		+	{{#indexentry:mesh, wavefront}}
		+	{{#indexentry:wavefront, mesh}}
		+	{{#indexentry:mesh, obj}}
		+	{{#indexentry:obj, mesh}}
		+	<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>
		+	MESH:
		+	mesh {
		+	MESH_TRIANGLE...
		+	[MESH_MODIFIER...]
		+	} \|
		+	mesh {
		+	obj FILENAME
		+	[OBJ_TEXTURE_LIST]
		+	[inside_vector VECTOR]
		+	}
		+
		+	MESH_TRIANGLE:
		+	triangle {
		+	<Corner_1>, <Corner_2>, <Corner_3>
		+	[uv_vectors <uv_Corner_1>, <uv_Corner_2>, <uv_Corner_3>]
		+	[MESH_TEXTURE]
		+	} \|
		+	smooth_triangle {
		+	<Corner_1>, <Normal_1>,
		+	<Corner_2>, <Normal_2>,
		+	<Corner_3>, <Normal_3>
		+	[uv_vectors <uv_Corner_1>, <uv_Corner_2>, <uv_Corner_3>]
		+	[MESH_TEXTURE]
		+	}
		+
		+	MESH_MODIFIER:
		+	inside_vector <direction> \| hierarchy [ Boolean ] \|
		+	OBJECT_MODIFIER
		+
		+	OBJ_TEXTURE_LIST:
		+	texture_list {
		+	[OBJ_TEXTURE_LIST_ITEM]
		+	}
		+
		+	OBJ_TEXTURE_LIST_ITEM:
		+	STRING texture { TEXTURE } \| STRING material { TEXTURE } \| prefix STRING \| suffix STRING
		+
		+	MESH_TEXTURE:
		+	texture { TEXTURE_IDENTIFIER }
		+	texture_list {
		+	TEXTURE_IDENTIFIER TEXTURE_IDENTIFIER TEXTURE_IDENTIFIER
		+	}
		+	</pre>
		+
		+	{{#indexentry:default values, mesh}}
		+	<p>Mesh default values:</p>
		+	<pre>
		+	hierarchy : on
		+	</pre>
		+
		+	<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>
		+	<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 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 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}}
		+	==Solid 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>
		+
		+	<p>To determine if a point is inside a triangle mesh, POV-Ray shoots a ray from the point in some arbitrary direction. If this vector intersects an odd number of triangles, the point is inside the mesh. If it intersects an even number of triangles, the point is outside of the mesh. You can specify the direction of this vector. For example, to use <code>+z</code> as the direction, you would add the following line to the triangle mesh description (following all other mesh data, but before the object modifiers).</p>
		+	<pre>
		+	inside_vector <0, 0, 1>
		+	</pre>
		+	<p>This change does not have any effect on unions of triangles, these will still be always hollow.</p>
		+	{{#indexentry:mesh, wavefront}}
		+	{{#indexentry:wavefront, mesh}}
		+	{{#indexentry:mesh, obj}}
		+	{{#indexentry:obj, mesh}}
		+	==Wavefront Import==
		+	<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>
		+	<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, 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>The following example:</p>
		+	<pre>
		+	#declare MyTexture = texture { ... }
		+	#declare MyMaterial = material { ... }
		+
		+	mesh {
		+	obj "MyMesh.obj"
		+	texture_list {
		+	"Foo" texture { MyTexture }
		+	"Bar" material { MyMaterial }
		+	prefix "Tx"
		+	suffix "_"
		+	}
		+	inside_vector y
		+	}
		+	</pre>
		+	<p>Will map the material name "Foo" in the .obj file to <em>MyTexture</em> and the material name "Bar" to <em>MyMaterial</em> while any other name e.g. <em>Fnord</em> or <em>Uqbar</em> would be mapped to <em>TxFnord_</em> and <em>TxUqbar_</em> respectively.</p>

Reference Talk:Mesh - Revision history

Jholsenback: preserving obj import entries for later use

Jholsenback: initial creation