mirror of
https://github.com/g-truc/glm.git
synced 2024-11-15 22:34:35 +00:00
78 lines
5.0 KiB
HTML
78 lines
5.0 KiB
HTML
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
|
||
|
|
<title>FAQ</title>
|
||
|
|
<link href="tabs.css" rel="stylesheet" type="text/css"/>
|
||
|
|
<link href="doxygen.css" rel="stylesheet" type="text/css"/>
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
<!-- Generated by Doxygen 1.7.4 -->
|
||
|
|
<div id="top">
|
||
|
|
<div id="titlearea">
|
||
|
|
<table cellspacing="0" cellpadding="0">
|
||
|
|
<tbody>
|
||
|
|
<tr style="height: 56px;">
|
||
|
|
<td id="projectlogo"><img alt="Logo" src="logo-mini.png"/></td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
<div id="navrow1" class="tabs">
|
||
|
|
<ul class="tablist">
|
||
|
|
<li><a href="index.html"><span>Main Page</span></a></li>
|
||
|
|
<li><a href="modules.html"><span>Modules</span></a></li>
|
||
|
|
<li><a href="namespaces.html"><span>Namespaces</span></a></li>
|
||
|
|
<li><a href="annotated.html"><span>Classes</span></a></li>
|
||
|
|
<li><a href="files.html"><span>Files</span></a></li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<div id="nav-path" class="navpath">
|
||
|
|
<ul>
|
||
|
|
<li class="navelem"><a class="el" href="index.html">OpenGL Mathematics</a> </li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="header">
|
||
|
|
<div class="headertitle">
|
||
|
|
<div class="title">FAQ </div> </div>
|
||
|
|
</div>
|
||
|
|
<div class="contents">
|
||
|
|
<div class="textblock"><h2><a class="anchor" id="faq1"></a>
|
||
|
|
Why does GLM follow GLSL specification and conventions?</h2>
|
||
|
|
<p>Following GLSL conventions is a really strict policy of GLM. GLM has been designed according to the idea that everyone writes their own math library with their own conventions. The idea is that brilliant developers (the OpenGL ARB) worked together and agreed to make GLSL. Following GLSL conventions is a way to find consensus. Moreover, basically when a developer knows GLSL, he knows GLM.</p>
|
||
|
|
<h2><a class="anchor" id="faq2"></a>
|
||
|
|
Does GLM run GLSL programs?</h2>
|
||
|
|
<p>No, GLM is a C++ implementation of a subset of GLSL.</p>
|
||
|
|
<h2><a class="anchor" id="faq3"></a>
|
||
|
|
Does a GLSL compiler build GLM codes?</h2>
|
||
|
|
<p>No, this is not what GLM intends to do!</p>
|
||
|
|
<h2><a class="anchor" id="faq4"></a>
|
||
|
|
Should I use GTX extensions?</h2>
|
||
|
|
<p><a class="el" href="a00248.html">GTX Extensions (Experimental)</a> are experimental. In GLM this means that these extensions might change from version to version without restriction. In practice, it doesn't really change except time to time. GTC extensions are stabled, tested and perfectly reliable in time. Many GTX extensions extend GTC extensions and provide a way to explore features and implementations before becoming stable by a promotion as GTC extensions. This is similar to how OpenGL extensions can be EXT or ARB extensions before becoming core functionality.</p>
|
||
|
|
<p>In short, if you use a GTX extension, the API is much more likely to change from version to version than if you don't. But you should not feel too uncomfortable about using them.</p>
|
||
|
|
<h2><a class="anchor" id="faq5"></a>
|
||
|
|
Where can I ask my questions?</h2>
|
||
|
|
<p>A good place is the OpenGL Toolkits forum on OpenGL.org: <a href="http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=postlist&Board=10&page=1">http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=postlist&Board=10&page=1</a></p>
|
||
|
|
<h2><a class="anchor" id="faq6"></a>
|
||
|
|
Where can I find the documentation of extensions?</h2>
|
||
|
|
<p>The Doxygen generated documentation includes a complete list of all extensions available. Explore this documentation to get a complete view of all GLM capabilities! <a href="http://glm.g-truc.net/html/index.html">http://glm.g-truc.net/html/index.html</a></p>
|
||
|
|
<h2><a class="anchor" id="faq7"></a>
|
||
|
|
Should I use 'using namespace glm;'?</h2>
|
||
|
|
<p>This is unwise. Chances are that if 'using namespace glm;' is called, name collisions will happen. GLSL names for functions are fairly generic, so it is entirely likely that there is another function called, for example, <a class="el" href="">sqrt </a>.</p>
|
||
|
|
<p>For frequent use of particular types, they can be brough into the global namespace with a 'using' declaration like this:</p>
|
||
|
|
<p>/code using glm::mat4;</p>
|
||
|
|
<p>mat4 someVariable(3.0f); /endcode</p>
|
||
|
|
<h2><a class="anchor" id="faq8"></a>
|
||
|
|
Is GLM fast?</h2>
|
||
|
|
<p>GLM is mainly designed to be convenient; that's why it is written against GLSL specification.</p>
|
||
|
|
<p>The <a href="http://en.wikipedia.org/wiki/Pareto_principle">80-20 rule</a> suggests that 80% of a program's performance comes from 20% of its code. Therefore, one should first identify which 20% of the code is impacting the performance.</p>
|
||
|
|
<p>In general, if one identifies certain math code to be a performance bottleneck, the only way to solve this is to write specialized code for those particular math needs. So no canned library solution would be suitable.</p>
|
||
|
|
<p>That being said, GLM can provides some descent performances alternatives based on approximations or SIMD instructions. </p>
|
||
|
|
</div></div>
|
||
|
|
<hr class="footer"/><address class="footer"><small>Generated by 
|
||
|
|
<a href="http://www.doxygen.org/index.html">
|
||
|
|
<img class="footer" src="doxygen.png" alt="doxygen"/></a> 1.7.4 </small></address>
|
||
|
|
</body>
|
||
|
|
</html>
|