Welcome to GMTL. To use this reference guide effectively, we suggest you see the Modules section first. The Modules section provides the most intuitive navigation of the reference guide because this section is structured very similar GMTL. Be sure to read the GMTL Programmer's Guide (available on the GMTL web site) to understand the philosophy behind GMTL. Understanding abstractly what GMTL is and why it is designed this way will make your life with GMTL very easy. Lastly, you should subscribe to the mailing lists so that you can ask questions, or propose extensions to the library.
Please see the GMTL FAQ for more information.
The GMTL API has two aspects you should keep in mind. The data types, and the operations on the data.
All data types and operations are defined in the gmtl namespace. Thus all types must be prefixed with the gmtl:: scope or a using gmtl; command can be used to bring all of the GMTL functionality into the local scope.
GMTL comes with many math data types: Vec, Point, Matrix, Quat, Coord, Sphere. Please read the programmer's guide for more detailed information. Or read on for a light overview on what GMTL is.
GMTL stands for (G)eneric (M)ath (T)emplate (L)ibrary. It is a math library designed to be high-performance, extensible, and generic. The design is based upon discussion with many experts in the field of computer graphics and virtual reality and is the culmination of many previous graphics math library efforts. GMTL gives the graphics programmer several core math types and a rich library of graphics/math operations on those types.
The design of GMTL allows extensibility while mantaining a stable core. Core data types are separated from operations. This allows anyone to write their own math routines to extend or replace parts of the GMTL. This feature allows a very stable core set of math primitives that seldom change due to extensions, maintainance, or programmer error.
All math primitives in GMTL use generic programming techniques to give the programmer many options to define their data. For example, matrices and vectors can be any dimension and any type. GMTL suffers no loss of performance due to these generalities because the parameter choices made are bound at compile time.
GMTL is implemented using generic programming and template metaprogramming. Generic programming allows selection by the user of size and type information for all data types in GMTL. For example, the generic Matrix type allows a programmer to select between any size (N x M) and any datatype (float, double, int...). The selection of these parameters is done through template parameters. To ease the use of these parameters, the system declares several typedefs that capture commonly used options.
Requested data types are statically bound and optimized by the compiler. The operations supplied with GMTL are implemented generically using a technique called template metaprogramming. Template metaprogramming allows things such as loops to be unrolled and conditionals to be evaluated by the compiler. Things such as loops and conditionals are evaluated statically, rather than at runtime. In addition, advanced optimizations can be performed that do this such as eliminate temporary variables and other intermediate computations. The result is compiled code that can behave as fast (or faster) then using traditional hand-coding methods such as loop unrolling, etc...
GMTL has an integrated test suite included in the source code distribution. The suite tests GMTL for correctness as well as performance degradation. The GMTL developers have put much time and effort into the test suite because we think that it will ensure that the code stays stable when changes are made, and that changes don't introduce performance hits. The bottom line is, if any behaviour changes in GMTL we want to know about it before it bites us. As a result of this philosophy, any contributions to GMTL also need to be well tested. Submissions will not be accepted without tests for correctness and performance.
1.7.1