3DFaces
/
libigl_Martin


			
				
					
						
						
							1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889
							<!DOCTYPE HTML>
<html>
  <head>
    <link rel='stylesheet' type='text/css' href='../style.css' >
    <title>libigl file formats</title>
  </head>
  <body class=article_outer>
  <div  class=article_inner>
    <a href=..><img src=../libigl-logo.jpg alt="igl logo" class=center></a>
  <h1>libigl file formats</h1>
  <ul>
    <li><a href="./bf.html">.bf</a> ASCII files for representing skeletal bone "forests"</li>
    <li><a href="./dmat.html">.dmat</a> uncompressed ASCII/binary files for dense matrices</li>
    <li><i>.ele</i> Element (triangle or tet) list. This format comes in similar flavors: <a
    href=http://tetgen.berlios.de/fformats.ele.html>tetgen's</a>, <a
    href=http://www.cs.berkeley.edu/~jrs/stellar/#fileformats>stellar's</a>,
    and <a href=https://www.cs.cmu.edu/~quake/triangle.ele.html>triangle's</a>.
    The formats of TetGen and stellar are identical upto conventions on index
    ordering and number of allowed attributes (unverified).</li>
    <li><a href=http://tetgen.berlios.de/fformats.face.html
    class=missing>.face</a> TetGen's file format for simplicial facets.</li>
    <li><a href="http://www.ann.jussieu.fr/frey/publications/RT-0253.pdf#page=33">.mesh</a> Medit's triangle surface mesh + tetrahedral volume mesh file format, see page 33, section 7.2.1</li>
    <li><i>.node</i> List of points (vertices). Described indentically (upto
        accepted dimensions, use of attributes and boundary markers) by <a
    href="https://www.cs.cmu.edu/~quake/triangle.node.html">Triangle</a>, <a
    href=http://tetgen.berlios.de/fformats.node.html>TetGen</a>, and <a
    href=http://www.cs.berkeley.edu/~jrs/stellar/#fileformats>Stellar</a>.
    </li>
    <li><a href="http://tetgen.berlios.de/fformats.off.html">.off</a> Geomview's polyhedral file format</li>
    <li><a href="http://en.wikipedia.org/wiki/Wavefront_.obj_file#File_format">.obj</a> Wavefront object file format. Usually unsafe to assume anything more than vertex positions and triangle indices are supported</li>
    <li><a
    href=https://en.wikipedia.org/wiki/Portable_Network_Graphics>.png</a>
    Portable Network Graphics image file. IGLLIB (in the libiglpng extra)
  supports png image files via the <a href=https://github.com/yig/yimg>yimg</a>
  library. Alpha channels and compression are suppported.</li>
    <li><i>.poly</i> Piecewise-linear complex. This format comes in many similar but importantly different flavors: 
      <a href="https://www.cs.cmu.edu/~quake/triangle.poly.html">triangle's</a>, <a href="http://tetgen.berlios.de/fformats.poly.html">tetgen's</a>, <a href="http://sparse-meshing.com/svr/0.2.1/format-poly.html">pyramid/SVR's</a></li>
    <li><a href=./rbr.html>.rbr</a> ASCII files for saving state of ReAntTweakBar</li>
    <li><a href=http://en.wikipedia.org/wiki/Truevision_TGA>.tga</a> Truevision TGA or TARGA image file format. IGLLIB supports only very basic reading and writing RGB/RGBA files without colormaps and (unverified) run-length compression.</li>
    <li><a href="./tgf.html">.tgf</a> ASCII files for representing control handle graphs</li>
	<li><a href="./xml.html">.xml</a> XMLSerializer's file format containing the serialization of object data structures.</li>
  </ul>
  <h3>Triangle mesh file format performance</h3>
  <p>
  <a
  href="http://en.wikipedia.org/wiki/Wavefront_.obj_file#File_format">.obj</a>
  and <a href="http://tetgen.berlios.de/fformats.off.html">.off</a> file
  formats support meshes with arbitrary polygon degrees. However, often we are
  only working with triangle meshes. Further, .obj files do not have useful
  headers revealing the number of elements. For triangle meshes, .off and .obj
  are inferior file formats to the <a
  href="http://www.ann.jussieu.fr/frey/publications/RT-0253.pdf#page=33">.mesh</a>
  file format. The current (version 0.1.6) IO functions for these file formats perform as follows for reading and writing a 300,000 triangle mesh:
  </p>
  <pre><code>
writeOBJ:  1.33742 secs
writeOFF:  0.510111 secs
writeMESH: 0.218139 secs

readOBJ:   1.3782 secs
readOFF:   0.691496 secs
readMESH:  0.242315 secs
  </code></pre>
  <p>
  This reveals that .mesh is 6.5x faster than .obj and about 2.5x faster than .off.
  </p>
  <p>
  While .obj files support normals, it is typically much faster to (re)compute
  normals from the geometry using <code>per_face_normals</code>,
  <code>per_vertex_normals</code>, <code>per_corner_normals</code> than to read
  and write them to files.</p>
  <p>It gets even better if you're willing to use a nonstandard format. If your
  triangle mesh is in (<code>V</code>,<code>F</code>) then you can read and
  write those variables as dense matrices of doubles to 
  <a href="./dmat.html">.dmat</a> uncompressed <strong>binary</strong> files.
  This not only ensures perfect precision but also big speed ups. On that same
  300,000 triangle mesh, .dmat achieves:</p>
  <pre><code>
writeDMAT: 0.0384338 secs

readDMAT:  0.0117921 secs
  </code></pre>
  <p>This reveals that binary .dmat files are 34x/116x faster at writing and
  reading than .obj and a hefty 5x/20x over .mesh. In this case it may pay to
  compute normals once into <code>N</code> and also read and write it to a
  .dmat file.</p>
  </div>
  </body>
</html>