mirror of
https://github.com/g-truc/glm.git
synced 2024-11-15 22:34:35 +00:00
121 lines
8.2 KiB
HTML
121 lines
8.2 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>Advanced Usage</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">Advanced Usage </div> </div>
|
||
|
|
</div>
|
||
|
|
<div class="contents">
|
||
|
|
<div class="textblock"><h2><a class="anchor" id="advanced_swizzle"></a>
|
||
|
|
Swizzle Operators</h2>
|
||
|
|
<p>A common feature of shader languages like GLSL is components swizzling. This involves being able to select which components of a vector are used and in what order. For example, "variable.x", "variable.xxy", "variable.zxyy" are examples of swizzling.</p>
|
||
|
|
<div class="fragment"><pre class="fragment"><a class="code" href="a00235.html#ga8fad5ffc01ba6dea689f2a38bf30bda4" title="4 components vector of floating-point numbers.">vec4</a> A;
|
||
|
|
<a class="code" href="a00235.html#gae0d1080e37fc58255cac2d521704ec60" title="2 components vector of floating-point numbers.">vec2</a> B;
|
||
|
|
...
|
||
|
|
B.yx = A.wy;
|
||
|
|
B = A.xx;
|
||
|
|
</pre></div><p>This functionally turns out to be really complicated to implement in C++ using the exact GLSL conventions. GLM provides 2 implementions this feature.</p>
|
||
|
|
<h3><a class="anchor" id="advanced_swizzle_macro"></a>
|
||
|
|
Macro implementation</h3>
|
||
|
|
<p>The first implementation follows the GLSL convensions accurately. It uses macros to achieve this, which might generates name conflicts with system headers or third party libraries. Therefore, it is disabled by default. To enable this implementation, GLM_SWIZZLE must be defined before any inclusion of <<a class="el" href="a00052_source.html">glm/glm.hpp</a>>.</p>
|
||
|
|
<div class="fragment"><pre class="fragment"><span class="preprocessor">#define GLM_SWIZZLE </span>
|
||
|
|
<span class="preprocessor">#include <glm/glm.hpp></span>
|
||
|
|
</pre></div><p>This implementation can be partially enabled by defining GLM_SWIZZLE_XYZW, GLM_SWIZZLE_RGBA or GLM_SWIZZLE_STQP. Each macro only enable a set of swizzling operators. For example we can only enable x,y,z,w and s,t,q,p operators using:</p>
|
||
|
|
<div class="fragment"><pre class="fragment"><span class="preprocessor">#define GLM_SWIZZLE_XYZW </span>
|
||
|
|
<span class="preprocessor"></span><span class="preprocessor">#define GLM_SWIZZLE_STQP</span>
|
||
|
|
<span class="preprocessor">#include <glm/glm.hpp></span>
|
||
|
|
</pre></div><h3><a class="anchor" id="advanced_swizzle_ext"></a>
|
||
|
|
Extension implementation</h3>
|
||
|
|
<p>A safer way to do swizzling is to use the <<a class="el" href="a00107_source.html">glm/gtc/swizzle.hpp</a>> extension. This extension provides the GLSL functionality, but uses a different syntax for it. Moreover, the swizzle extension also provides dynamic swizzling.</p>
|
||
|
|
<p>Static swizzling is resovled at compile-time. The swizzle mask ".xzyy" is as fixed as the type of a particular variable. Dynamic swizzling is resolved at runtime via function calls. Dynamic swizzling is more flexible, since one can choose the swizzle mask at runtime, but it runs slower. This performance issue is enhanced when <a class="el" href="a00002.html#advanced_simd">SIMD instructions</a> are used.</p>
|
||
|
|
<div class="fragment"><pre class="fragment"><span class="preprocessor">#include <glm/glm.hpp></span>
|
||
|
|
<span class="preprocessor">#include <glm/gtc/swizzle.hpp></span>
|
||
|
|
|
||
|
|
<span class="keywordtype">void</span> foo()
|
||
|
|
{
|
||
|
|
<a class="code" href="a00022.html" title="Basic 4D vector type.">glm::vec4</a> ColorRGBA(1.0f, 0.5f, 0.0f, 1.0f);
|
||
|
|
...
|
||
|
|
<span class="comment">// Dynamic swizzling (at run time, more flexible)</span>
|
||
|
|
<span class="comment">// l-value:</span>
|
||
|
|
<a class="code" href="a00022.html" title="Basic 4D vector type.">glm::vec4</a> ColorBGRA1 =
|
||
|
|
glm::swizzle(ColorRGBA, glm::B, glm::G, glm::R, glm::A);
|
||
|
|
<span class="comment">// r-value:</span>
|
||
|
|
glm::swizzle(ColorRGBA, glm::B, glm::G, glm::R, glm::A) = ColorRGBA;
|
||
|
|
|
||
|
|
<span class="comment">// Static swizzling (at build time, faster)</span>
|
||
|
|
<span class="comment">// l-value:</span>
|
||
|
|
<a class="code" href="a00022.html" title="Basic 4D vector type.">glm::vec4</a> ColorBGRA2 =
|
||
|
|
glm::swizzle<glm::B, glm::G, glm::R, glm::A>(ColorRGBA);
|
||
|
|
<span class="comment">// r-value:</span>
|
||
|
|
glm::swizzle<glm::B, glm::G, glm::R, glm::A>(ColorRGBA) = ColorRGBA;
|
||
|
|
}
|
||
|
|
</pre></div><h2><a class="anchor" id="advanced_notify"></a>
|
||
|
|
Notification System</h2>
|
||
|
|
<p>GLM includes a notification system which can display some information at build time: </p>
|
||
|
|
<ul>
|
||
|
|
<li>Compiler </li>
|
||
|
|
<li>Build model: 32bits or 64 bits </li>
|
||
|
|
<li>C++ version </li>
|
||
|
|
<li>Architecture: x86, SSE, AVX, etc. </li>
|
||
|
|
<li>Included extensions </li>
|
||
|
|
<li>etc.</li>
|
||
|
|
</ul>
|
||
|
|
<p>This system is disable by default. To enable this system, define GLM_MESSAGES before any inclusion of <<a class="el" href="a00052_source.html">glm/glm.hpp</a>>.</p>
|
||
|
|
<div class="fragment"><pre class="fragment"><span class="preprocessor">#define GLM_MESSAGES</span>
|
||
|
|
<span class="preprocessor">#include <glm/glm.hpp></span>
|
||
|
|
</pre></div><h2><a class="anchor" id="advanced_inline"></a>
|
||
|
|
Force Inline</h2>
|
||
|
|
<p>GLM's functions are defined in headers, so they are defined with C++'s "inline" delcaration. This does not require the compiler to inline them, however. To force the compiler to inline the function, using whatever capabilities that the compiler provides to do so, GLM_FORCE_INLINE can be defined before any inclusion of <<a class="el" href="a00052_source.html">glm/glm.hpp</a>>.</p>
|
||
|
|
<div class="fragment"><pre class="fragment"><span class="preprocessor">#define GLM_FORCE_INLINE </span>
|
||
|
|
<span class="preprocessor">#include <glm/glm.hpp></span>
|
||
|
|
</pre></div><h2><a class="anchor" id="advanced_simd"></a>
|
||
|
|
SIMD support</h2>
|
||
|
|
<p>GLM provides some SIMD optimizations based on compiler intrinsics. These optimizations will be automatically utilized based on the build environment. These optimizations are mainly available through the extensions <a class="el" href="a00292.html">GLM_GTX_simd_vec4: SIMD vec4 type and functions</a> and <a class="el" href="a00291.html">GLM_GTX_simd_mat4: SIMD mat4 type and functions</a>.</p>
|
||
|
|
<p>A programmer can restrict or force instruction sets used for these optimizations using GLM_FORCE_SSE2 or GLM_FORCE_AVX.</p>
|
||
|
|
<p>A programmer can discard the use of intrinsics by defining GLM_FORCE_PURE before any inclusion of <<a class="el" href="a00052_source.html">glm/glm.hpp</a>>. If GLM_FORCE_PURE is defined, then including a SIMD extension will generate a build error.</p>
|
||
|
|
<div class="fragment"><pre class="fragment"><span class="preprocessor">#define GLM_FORCE_PURE</span>
|
||
|
|
<span class="preprocessor">#include <glm/glm.hpp></span>
|
||
|
|
</pre></div><h2><a class="anchor" id="advanced_compatibility"></a>
|
||
|
|
Compatibility</h2>
|
||
|
|
<p>Compilers have some language extensions that GLM will automatically take advantage of them when they are enabled. GLM_FORCE_CXX98 can switch off these extensions, forcing GLM to operate on pure C++98.</p>
|
||
|
|
<div class="fragment"><pre class="fragment"><span class="preprocessor">#define GLM_FORCE_CXX98 </span>
|
||
|
|
<span class="preprocessor">#include <glm/glm.hpp></span>
|
||
|
|
</pre></div> </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>
|