mirror of
https://github.com/g-truc/glm.git
synced 2024-09-20 08:22:17 +00:00
13 lines
9.7 KiB
HTML
13 lines
9.7 KiB
HTML
<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
|
||
<html><head><title>OpenGL Mathematics : Issues</title><meta http-equiv="Content-Language" content="fr, be, ca, lu, ch" /><meta http-equiv="Content-Type" content="application/xhtml+xml; charset=iso-8859-1" /><meta name="copyright" content="� 2005 C-Truc Creation" /><link href="./common/style.css" rel="stylesheet" media="screen, print, embossed" type="text/css" /></head><body><div class="title">OpenGL Mathematics</div><table><tr><td class="menu"><div class="menu1"><a class="menu" href="./glm/downloads/section/download/@link">Download GLM 0.8.4.3</a></div><hr /><div class="menu2"><a class="menu" href="./index.html">News</a></div><div class="menu2"><a class="menu" href="./download.html">Downloads</a></div><div class="menu2"><a class="menu" href="./changelog.html">Changelog</a></div><div class="menu2"><a class="menu" href="./glm-manual.pdf">User manual</a></div><div class="menu2"><a class="menu" href="./html/index.html">API Documentation</a></div><div class="menu2"><a class="menu" href="http://glf.svn.sourceforge.net/viewvc/glf">SVN Browse</a></div><div class="menu2"><a class="menu" href="https://sourceforge.net/tracker/?group_id=129808&atid=901445">Bug tracker</a></div><div class="menu2"><a class="menu" href="https://sourceforge.net/tracker/?group_id=129808&atid=715891">Feature requests</a></div><div class="menu2"><a class="menu" href="./link.html">Links</a></div><hr /><div class="menu2"><a href="http://validator.w3.org/check/referer"><img class="menu-img" src="http://www.w3.org/Icons/valid-xhtml11" alt="Valid XHTML 1.1!" /></a></div><div class="menu2"><a href="http://www.opengl.org"><img class="menu-img" src="./common/opengl.jpg" alt="OpenGL" /></a></div><div class="menu2"><a href="http://www.sourceforge.net"><img class="menu-img" src="./common/sourceforge.gif" alt="SourceForge" /></a></div><div class="menu2"><a href="http://www.g-truc.net"><img class="menu-img" src="./common/g-truc.jpg" alt="G-Truc" /></a></div><hr /></td><td class="page"><div><div class="title2">Probl<EFBFBD>matiques</div><br /><div class="issue-title">10) Several useful tools are missing in GLSL, is this possible to add them ?<br /></div><div><div class="issue-content">DISCUTION: GLSL is not the ultimate mathematics library, i.e. for matrices operations, specs are very restricted. There aren't any functions to get the determinant, inverse, or a matrix transpose. Moreover, there are a few vector types and no quaternions.</div><div class="issue-content">PROPOSAL: What about completing the missing features using the extensions ? It will be developed from GLSL conventions and may add for exemple the extension GLM_GTX_quaternion, defining __quatGT type and conjugateGT function.</div><div class="issue-content">PROPOSAL: Extensions may be available through a separate file called glmext.h instead of being directly into the library core file.</div><div class="issue-content">PROPOSAL: It would be interesting to suggest GLM extensions implementations directly in GLSL to increase portability. It may hopefully end by submitting extensions to ARB.</div><br /><div class="issue-content">
|
||
STATUE : Partially resolved, 2005-03-21</div></div><br /><div class="issue-title">9) Should GLM be included into a namespace ?<br /></div><div><div class="issue-content">DISCUTION: The use of a namespace allows to prevenf from any name collision problem with other libraries like STL. GLSL uses a reserved 'namespace' keyword but does not define it. OpenGL uses a C technic for the namespaces management with the 'gl' prefix. What name should we give to this namespace ? 'gl', 'glsl', 'glm' or 'sl' ? What is the best solution ? C-like or C++-like namespaces ?</div><div class="issue-content">DISCUTION: Bug #3 says that 'not' is a C++ keyword. C-style namespaces use would resolves this bug but GLSL has been built from C upon a C++ logic.</div><br /><div class="issue-content">
|
||
STATUE : Unresolved, 2005-02-18</div></div><br /><div class="issue-title">8) Could the OpenGL API be considered ?<br /></div><div><div class="issue-content">DISCUTION: The interaction with OpenGL is not the purpose of GLM. However, GLM should be easily usable with OpenGL and some features could be welcome. i.e., using vec3 type with Vertex3fv function should simplify and optimize the program. Eventually, semantically speaking, vec3 is more accurate and stronger than addressing on a potential 3 floats table.</div><div class="issue-content">RESOLUTION: If it is possible to make easy the interoperability between GLM and OpenGL, then this work is recommended if semantic stays correct. GLM must also remain independent towards OpenGL.</div><br /><div class="issue-content">
|
||
STATUE : Resolved, 2005-03-04</div></div><br /><div class="issue-title">7) How to consider reserved keywords ?<br /></div><div><div class="issue-content">DISCUTION: GLSL specifications include unimplemented reserved keywords list. Their use must return an error. Some of them already exist in C++.</div><div class="issue-content">RESOLUTION: GLM can only allow C++ reserved keywords. The others must be undefined so the compiler returns an error.</div><br /><div class="issue-content">
|
||
STATUE : Partially resolved, 2005-01-26</div></div><br /><div class="issue-title">6) How to manage GLSL qualifiers ?<br /></div><div><div class="issue-content">DISCUTION: GLSL defines six variable qualifiers types : const, varying, uniform, attrib, in, out, inout.</div><div class="issue-content">RESOLUTION: 'const' variables are only usable in a local way into a shader. They are available for vertex and fragments shaders. GLSL's 'const' are similar to C++ 'static const', i.e. the variable only exists inside a compilation unit (.o files with GCC).</div><div class="issue-content">RESOLUTION: 'varying' variables offer a communication interface between vertex and fragment sahder. 'uniform' and 'attrib' variables are a way of communication between C/C++ program and shaders, so 'varying' are useless in the C++ program; so this qualifier is not allowed.</div><div class="issue-content">SUGGESTION: Some programmers are already using 'in', 'ou' and 'inout' qualifiers for semantic purpose. They define them as empty '#define'.</div><div class="issue-content">DISCUTION: It seems difficult to keep the same syntax than GLSL for 'uniform' and 'attrib' variables although this notion seems interesting. Why not keeping it only for their semantic properties ?</div><br /><div class="issue-content">
|
||
STATUE : Partially resolved, 2005-03-04</div></div><br /><div class="issue-title">5) Should integrated variables be considered ?<br /></div><div><div class="issue-content">SUGGESTION: All integrated variables matches with OpenGL state variables. So there are all accessible from the OpenGL API.</div><br /><div class="issue-content">
|
||
STATUE : Resolved, 2005-01-13</div></div><br /><div class="issue-title">4) Should sampler* types be considered ?<br /></div><div><div class="issue-content">DISCUTION: smapler* types come from GL_ARB_multitexure extension. Values matches with a texture unit.</div><div class="issue-content">SUGGESTION: A sampler type would offer an additionnal semantic value.</div><div class="issue-content">SUGGESTION: No, this is not the GLM objective.</div><br /><div class="issue-content">
|
||
STATUE : Resolved, 2005-03-05</div></div><br /><div class="issue-title">3) How to manage specific access to *vec* types components ?<br /></div><div><div class="issue-content">DISCUTION: GLSL allows several components to be accessed at the same time. Moreover, GLSL let the possibility to the user to order components as he wants. To implement such a possibility, 4<> * 3 * 2 = 96 fuctions should be added for vec4 type, for example (components number : 4, access types : 3, readonly access and write access : 2).</div><div class="issue-content">RESOLUTION: A solution witch reach GLSL conformance have been found. However it need lot of functions. This feature is coming in a futur release.</div><br /><div class="issue-content">
|
||
STATUE : Unresolved, 2005-01-22</div></div><br /><div class="issue-title">2) How to access to *vec* type components ?<br /></div><div><div class="issue-content">DISCUTION: GLSL allows an access to a component with many different names, that explains the component notion. i.e. the first vec3 component is accessible with .x, .r, .s.</div><div class="issue-content">PROPOSAL: A possibility would be creating three functions for each component.</div><div class="issue-content">PROPOSAL: Another would be using the keyword 'union'.</div><div class="issue-content">RESOLUTION: The first solution allows to keep components values in a private classes table, but in this case, the overloaded operator [] must be used to access values and/or functions per component that is not conform to GLSL specifications. The second respect GLSL rules but components are public. In this case, this is not a real problem so this second solution is kept.</div><br /><div class="issue-content">
|
||
STATUE : Closed, 2005-01-15</div></div><br /><div class="issue-title">1) How to consider dedicated functions to fragment shaders and ftransform function ?<br /></div><div><div class="issue-content">RESOLUTION: GLSL specifications tell that 'fragment processing functions' are only available for fragment shaders and function ftransform is only available for vertex shaders. The C/C++ program must be considered as a third program type so this functions are not available.</div><br /><div class="issue-content">
|
||
STATUE : Closed, 2005-01-12</div></div><br /></div></td></tr></table><div class="title3">Copyright <20> 2005-2008 <a href="http://www.g-truc.net">G-Truc Creation</a></div></body></html> |