With the new clang in Xcode 4.6, and -Wdocumentation enabled, a few warnings:

I'm not familiar with doxygen to even know whether the warnings are correct :/

In file included from glm/glm/glm.hpp:98:
In file included from glm/glm/./core/type.hpp:43:
In file included from glm/glm/core/type_mat2x2.hpp:32:
glm/glm/core/type_mat.hpp:38:2: error: not a Doxygen trailing comment [-Werror,-Wdocumentation]
        //<
        ^~~
        ///<
glm/glm/core/type_mat.hpp:55:2: error: not a Doxygen trailing comment [-Werror,-Wdocumentation]
        //<
        ^~~
        ///<
glm/glm/core/type_mat.hpp:64:2: error: not a Doxygen trailing comment [-Werror,-Wdocumentation]
        //<
        ^~~
        ///<
In file included from glm/glm/glm.hpp:101:
glm/glm/./core/func_exponential.hpp:47:13: error: empty paragraph passed to '\param' command [-Werror,-Wdocumentation]
        /// @param y 
            ~~~~~~~^
In file included from In file included from glm/glm/glm.hpp:102:
glm/glm/./core/func_common.hpp:221:7: error: duplicated command '\return' [-Werror,-Wdocumentation]
        //! @return If genTypeU is a boolean scalar or vector: 
            ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
glm/glm/./core/func_common.hpp:216:7: note: previous command '\return' here
        //! @return If genTypeU is a floating scalar or vector: 
            ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5 errors generated.

http://www.opengl.org/discussion_boards/showthread.php/178484-Extracting-camera-position-from-a-ModelView-Matrix?p=1240457#post1240457

Hi,

I'm just moving my code base to glm and the documentation for glm::perspective says:

fovy Expressed in radians if GLM_FORCE_RADIANS is defined or degrees otherwise.

I found that a define is missing line 239 in glm/matrix_transform.inl

there should be some thing like

#ifdef GLM_FORCE_RADIANS
        valType range = tan(fovy / valType(2)) * zNear;
#else
        valType range = tan(radians(fovy / valType(2))) * zNear;
#endif

Hope it helps,
Happy new year

Adding "restrict (amp,cpu)" to the end of most all functions should be enough. Put it in a macro that's defined to nothing on non-AMP platforms. Use VS2012 (express edition is free) to test.

This way you could seamlessly use it for GPGPU using AMP.

hello,
trying to use GLM with Borland compiler, C++ X3 version 6.5, I am getting the following errors when I compile my project:

[bcc32 Error] func_packing.inl(154): E2090 Qualifier 'detail' is not a class or namespace name
Full parser context
glfw-test1.cpp(12): #include D:\Development\Projects\glm-0.9.4.1\glm\glm.hpp
glm.hpp(103): #include D:\Development\Projects\glm-0.9.4.1\glm./core/func_packing.hpp
func_packing.hpp(190): #include D:\Development\Projects\glm-0.9.4.1\glm./core/func_packing.inl
func_packing.inl(30): namespace glm
func_packing.inl(161): decision to instantiate: unsigned int glm::packHalf2x16(const glm::mediump_vec2 &)
--- Resetting parser context for instantiation...
func_packing.inl(148): parsing: unsigned int glm::packHalf2x16(const glm::mediump_vec2 &)
func_packing.inl(150): class helper
func_packing.inl(153): class helper::
[bcc32 Error] func_packing.inl(154): E2040 Declaration terminated incorrectly
Full parser context
glfw-test1.cpp(12): #include D:\Development\Projects\glm-0.9.4.1\glm\glm.hpp
glm.hpp(103): #include D:\Development\Projects\glm-0.9.4.1\glm./core/func_packing.hpp
func_packing.hpp(190): #include D:\Development\Projects\glm-0.9.4.1\glm./core/func_packing.inl
func_packing.inl(30): namespace glm
func_packing.inl(161): decision to instantiate: unsigned int glm::packHalf2x16(const glm::mediump_vec2 &)
--- Resetting parser context for instantiation...
func_packing.inl(148): parsing: unsigned int glm::packHalf2x16(const glm::mediump_vec2 &)
func_packing.inl(150): class helper
func_packing.inl(153): class helper::
[bcc32 Error] func_packing.inl(158): E2316 'a' is not a member of 'struct'
Full parser context
glfw-test1.cpp(12): #include D:\Development\Projects\glm-0.9.4.1\glm\glm.hpp
glm.hpp(103): #include D:\Development\Projects\glm-0.9.4.1\glm./core/func_packing.hpp
func_packing.hpp(190): #include D:\Development\Projects\glm-0.9.4.1\glm./core/func_packing.inl
func_packing.inl(30): namespace glm
func_packing.inl(161): decision to instantiate: unsigned int packHalf2x16(const mediump_vec2 &)
--- Resetting parser context for instantiation...
func_packing.inl(148): parsing: unsigned int packHalf2x16(const mediump_vec2 &)
[bcc32 Error] func_packing.inl(159): E2316 'b' is not a member of 'struct'
Full parser context
glfw-test1.cpp(12): #include D:\Development\Projects\glm-0.9.4.1\glm\glm.hpp
glm.hpp(103): #include D:\Development\Projects\glm-0.9.4.1\glm./core/func_packing.hpp
func_packing.hpp(190): #include D:\Development\Projects\glm-0.9.4.1\glm./core/func_packing.inl
func_packing.inl(30): namespace glm
func_packing.inl(161): decision to instantiate: unsigned int packHalf2x16(const mediump_vec2 &)
--- Resetting parser context for instantiation...
func_packing.inl(148): parsing: unsigned int packHalf2x16(const mediump_vec2 &)
[bcc32 Error] func_packing.inl(170): E2090 Qualifier 'detail' is not a class or namespace name
Full parser context
glfw-test1.cpp(12): #include D:\Development\Projects\glm-0.9.4.1\glm\glm.hpp
glm.hpp(103): #include D:\Development\Projects\glm-0.9.4.1\glm./core/func_packing.hpp
func_packing.hpp(190): #include D:\Development\Projects\glm-0.9.4.1\glm./core/func_packing.inl
func_packing.inl(30): namespace glm
func_packing.inl(176): decision to instantiate: glm::mediump_vec2 glm::unpackHalf2x16(const unsigned int &)
--- Resetting parser context for instantiation...
func_packing.inl(164): parsing: glm::mediump_vec2 glm::unpackHalf2x16(const unsigned int &)
func_packing.inl(166): class helper
func_packing.inl(169): class helper::
[bcc32 Error] func_packing.inl(170): E2040 Declaration terminated incorrectly
Full parser context
glfw-test1.cpp(12): #include D:\Development\Projects\glm-0.9.4.1\glm\glm.hpp
glm.hpp(103): #include D:\Development\Projects\glm-0.9.4.1\glm./core/func_packing.hpp
func_packing.hpp(190): #include D:\Development\Projects\glm-0.9.4.1\glm./core/func_packing.inl
func_packing.inl(30): namespace glm
func_packing.inl(176): decision to instantiate: glm::mediump_vec2 glm::unpackHalf2x16(const unsigned int &)
--- Resetting parser context for instantiation...
func_packing.inl(164): parsing: glm::mediump_vec2 glm::unpackHalf2x16(const unsigned int &)
func_packing.inl(166): class helper
func_packing.inl(169): class helper::
[bcc32 Error] func_packing.inl(175): E2316 'a' is not a member of 'struct'
Full parser context
glfw-test1.cpp(12): #include D:\Development\Projects\glm-0.9.4.1\glm\glm.hpp
glm.hpp(103): #include D:\Development\Projects\glm-0.9.4.1\glm./core/func_packing.hpp
func_packing.hpp(190): #include D:\Development\Projects\glm-0.9.4.1\glm./core/func_packing.inl
func_packing.inl(30): namespace glm
func_packing.inl(176): decision to instantiate: mediump_vec2 unpackHalf2x16(const unsigned int &)
--- Resetting parser context for instantiation...
func_packing.inl(164): parsing: mediump_vec2 unpackHalf2x16(const unsigned int &)
Failed

It seems that GLM is missing some versions of glm::equalEpsilon and glm::notEqualEpsilon for glm:quat:

#include "glm/glm.hpp"
#include "glm/gtx/epsilon.hpp"

int main(int argc, char* argv[])
{
  glm::equalEpsilon(glm::vec2(), glm::vec2(), glm::vec2());
  glm::equalEpsilon(glm::vec3(), glm::vec3(), glm::vec3());
  glm::equalEpsilon(glm::vec4(), glm::vec4(), glm::vec4());
  glm::equalEpsilon(glm::quat(), glm::quat(), glm::quat()); // Works fine.

  glm::notEqualEpsilon(glm::vec2(), glm::vec2(), glm::vec2());
  glm::notEqualEpsilon(glm::vec3(), glm::vec3(), glm::vec3());
  glm::notEqualEpsilon(glm::vec4(), glm::vec4(), glm::vec4());
  glm::notEqualEpsilon(glm::quat(), glm::quat(), glm::quat()); // Works fine.


  glm::equalEpsilon(glm::vec2(), glm::vec2(), 0.0f);
  glm::equalEpsilon(glm::vec3(), glm::vec3(), 0.0f);
  glm::equalEpsilon(glm::vec4(), glm::vec4(), 0.0f);
  glm::equalEpsilon(glm::quat(), glm::quat(), 0.0f); // Linker error!

  glm::notEqualEpsilon(glm::vec2(), glm::vec2(), 0.0f);
  glm::notEqualEpsilon(glm::vec3(), glm::vec3(), 0.0f);
  glm::notEqualEpsilon(glm::vec4(), glm::vec4(), 0.0f);
  glm::notEqualEpsilon(glm::quat(), glm::quat(), 0.0f); // Linker error!

  return 0;
}

I made a patch that fixes the issue: https://gist.github.com/4078772

At gtx/component_wise.inl:15 result uses genType::size_type instead of genType::value_type.

In matrix_interpolation.hpp function "interpolate" dltRotation "rotation" part is not necessarily orthonormalized, if m1 and m2 contain translation. Using just the rotational portion of m1 seem to fix the issue. Plus there is no additional cost for this fix, due to the fact that we need rotational portion of m1 later in the function.

So the code should be this instead

template <typename T>
GLM_FUNC_QUALIFIER detail::tmat4x4<T> interpolate
(
    detail::tmat4x4<T> const & m1,
    detail::tmat4x4<T> const & m2,
    T const delta
)
{
    detail::tmat4x4<T> m1rot = extractMatrixRotation(m1);
    detail::tmat4x4<T> dltRotation = m2 * transpose(m1rot);
    detail::tvec3<T> dltAxis;
    T dltAngle;
    axisAngle(dltRotation, dltAxis, dltAngle);
    detail::tmat4x4<T> out = axisAngleMatrix(dltAxis, dltAngle * delta) * m1rot;
    out[3][0] = m1[3][0] + delta * (m2[3][0] - m1[3][0]);
    out[3][1] = m1[3][1] + delta * (m2[3][1] - m1[3][1]);
    out[3][2] = m1[3][2] + delta * (m2[3][2] - m1[3][2]);
    return out;
}

Hi,

I found a bug in glm.

mix(vecn(x), vecn(y), bvecn(a))
returns 0.0f in the correct components everything else will be 1.0f,

There is a bug-free version in the func_common.inl, but it is hidden by the generic version.

Regards,
Jens

I couldn't find in glm a function to rotate a direction into another one.
Here's one :

quat RotationBetweenVectors(vec3 start, vec3 dest){
    start = normalize(start);
    dest = normalize(dest);

    float cosTheta = dot(start, dest);
    vec3 rotationAxis;

    if (cosTheta < -1 + 0.001f){
        // special case when vectors in opposite directions :
        // there is no "ideal" rotation axis
        // So guess one; any will do as long as it's perpendicular to start
        // This implementation favors a rotation around the Up axis (Y),
        // since it's often what you want to do.
        rotationAxis = cross(vec3(0.0f, 0.0f, 1.0f), start);
        if (gtx::norm::length2(rotationAxis) < 0.01 ) // bad luck, they were parallel, try again!
            rotationAxis = cross(vec3(1.0f, 0.0f, 0.0f), start);

        rotationAxis = normalize(rotationAxis);
        return gtx::quaternion::angleAxis(180.0f, rotationAxis);
    }

    // Implementation from Stan Melax's Game Programming Gems 1 article
    rotationAxis = cross(start, dest);

    float s = sqrt( (1+cosTheta)*2 );
    float invs = 1 / s;

    return quat(
        s * 0.5f, 
        rotationAxis.x * invs,
        rotationAxis.y * invs,
        rotationAxis.z * invs
    );


}

Ogre's version enables the user to choose the fallback axis instead of forcing the Y one; but when not provided, it favours the Z axis, which I find weird : https://bitbucket.org/sinbad/ogre/src/3cbd67467fab3fef44d1b32bc42ccf4fb1ccfdd0/OgreMain/include/OgreVector3.h?at=default#cl-651

Unless I'm mistaken, each time you want to create an "up" vector, you have to write glm::vec(0.0f, 1.0f, 0.0f);

Ogre provides static vectors : https://bitbucket.org/sinbad/ogre/src/3cbd67467fab/OgreMain/src/OgreVector3.cpp?at=default

Unity too : http://docs.unity3d.com/Documentation/ScriptReference/Vector3-up.html (but the "forward" and "right" words are a bit confusing)

Can GLM provide similar functionality ?

I had a look at euler_angles.inl and am a bit confused. Seems to me, for the "usual" right-handed frame, eulerAngleX() and eulerAngleZ() should have the sin terms inverted (the '-' placed differently than in eulerAngleY()).

Also, I am not sure how e.g. "eulerAngleXY" is to be interpreted. Is it supposed to be the same as

eulerAngleX() * eulerAngleY(),

or "rotation about X, followed by rotation about Y", i.e., when using column vectors multiplied from the right

eulerAngleY() * eulerAngleX()

... I would just like that clarified in the documentation.

As a feature request, I would love to have eulerAngleXYZ(), too. (Meaning, rotate about X first.)

Oh, I am using glm-0.9.3.4.

may be i'm wrong but:
glm::mat4 proj = glm::perspective(45.0f, 1.0f, 0.1f, 3.0f);
glm::mat4 proj = glm::perspectiveFov(45.0f, 128.0f, 128.0f, 0.1f, 3.0f);

result in (image)

Recently, during profiling of my game's code, I have noticed lots of sqrt calls in glm::rotate functions:

template <typename T> GLM_FUNC_QUALIFIER detail::tquat<T> rotate ( detail::tquat<T> const & q, typename detail::tquat<T>::value_type const & angle, detail::tvec3<T> const & v )

template <typename T> GLM_FUNC_QUALIFIER detail::tmat4x4<T> rotate ( detail::tmat4x4<T> const & m, T const & angle, detail::tvec3<T> const & v )

In both cases v vector is normalized inside those functions. I believe I understand logic behind this - it's foolproof and acts in the same way as glRotatef (which normalizes rotation axis if I remember correctly). However, vector normalization sometimes can have a huge impact on performance so I would like to propose additional versions of those functions that assume that the rotation axis is already normalized.

In my code I always make sure that all game objects keep their axes normalized and I believe that it is a common practice. That's why additional normalizations are just a waste of CPU time. It might be a good idea to take it under consideration in GLM. Thanks.

In gtx :

quaternion.inl:44 in squad : ext is indefined, instead of exp I guess
quaternion.inl:55 in intermediate : h is not a function -> operator* miss
quaternuion.inl:62 in exp : exponent parameter never used.

From the latest release:

#define GLM_VERSION                                     94
#define GLM_VERSION_MAJOR                       0
#define GLM_VERSION_MINOR                       9
#define GLM_VERSION_PATCH                       4
#define GLM_VERSION_REVISION            0

REVISION is still set to 0.

Considering that the API changed between revision 0 and revision 1 is it really important to be able to distinguish between the versions. (but also note that for an API change at least update minor)

We tried to use glm::reflect in our CUDA kernel, but it complained that we were trying to call it from a device.

Putting GLM_FUNC_QUALIFIER in front of it (func_geometric.inl:274), like the rest of the functions, made it work.

when fed with
ray origin glm::vec3(0,0,0);
ray direction glm::vec3(0,0,-1);

and 3 vertices (already transformed to world coordinates):
v0 = glm::vec3(0.5,0.5,-4.5);
v1 = glm::vec3(-0.5,-0.5,-4.5);
v2 = glm::vec3(0.5,-0.5,-4.5);

It returns barycentric coordinates a = 0, b = 0.5 , c = 4.5
If I understand correctly, a+b+c should equal to 1.

They don't seem to be barycentric coordinates, they seem like.. normal cartesian coordinates of the intersection point.

The clamp function seems to handle NaN's in a bad manner. Result of

glm::clamp(std::numeric_limits<float>::quite_NaN(), a, b)

is b while it should be a NaN.

This can be fixed by modifying the clamp function. Now its

return max(min(x, maxVal), minVal)

It should be

return min(maxVal, max(minVal, x));

It seems that conversion from float to half in case of small numbers (-0.0f included) forgets about the sign.

Example:
For glm::detail::toFloat16(0.0f) _data() returns 0 which is correct, but for glm::detail::toFloat16(-0.0f) call to _data() also returns 0 while it should be -32768.

To fix this replace line 158 in type_half.inl which reads return 0; with return hdata(s);. This will respect the sign.

When using GLM with NACL in Google Chrome, on line 571 in core/setup.hpp there is an extra "/" at the end of the line. This is interpreted as a multi-line comment in the NACL compiler and causes GLM to not be imported as a header library correctly. This would just be convenient to fix as it caused a bit of confusion for me when first trying to get GLM to work.

Hi I got the following error while trying to compile a project using MinGW (it compiles under linux, Mac and visual studio 10 & 11).

....\include/glm/gtc/../gtc/quaternion.inl:513:52: error: 'pitch' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]

....\include/glm/gtc/../gtc/quaternion.inl:513:52: error: 'yaw' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]

....\include/glm/gtc/../gtc/quaternion.inl:513:52: error: 'roll' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]

My code where the error is triggered looks like this:

glm::dvec3 tmpVal;

tmpVal = glm::eulerAngles( glm::quat_cast(mWorldTransform[i]) );

Where world transform is declared like this: glm::dmat4 mWorldTransform[2];

//Miro

When including glm/ext.hpp compilation error arises.
(Using GLM_FORCE_AVX define)
........
1> icl /Folibskywave\src\gpu_resources.obj /c libskywave\src\gpu_resources.cpp /TP /nologo /MD /O2 /Qrestrict /debug:all /Qopt-jump-tables:large /Qstd=c++11 /QaxAVX /Qvc11 /Quse-intel-optimized-headers /Qdiag-disable:2586 /EHa /GT /W3 /Z7 /Oi /D_WIN32_WINNT=0x0600 /D_BIND_TO_CURRENT_CRT_VERSION=1 /D_BIND_TO_CURRENT_ATL_VERSION=1 /D_BIND_TO_CURRENT_MFC_VERSION=1 /D_BIND_TO_CURRENT_OPENMP_VERSION=1 /D_SCL_SECURE_NO_WARNINGS=1 /D_VARIADIC_MAX=10 /DGLM_FORCE_AVX /DNDEBUG /D__OS_WINDOWS /D_CRT_SECURE_NO_WARNINGS /DWIN32 /D__WIN32 /DSKYWAVE_FULL_CONTEXT_DEBUG /DLIBSWGL_USE_IMMUTABLE_TEXTURES /D_WINDLL /DBOOST_ALL_NO_LIB /DGLEW_MX /DZLIB_WINAPI /DGEOBASE_API_IMPORT /DLIBGS_API_IMPORT "/IC:\Program Files (x86)\Intel\Composer XE 2013\compiler\include" /I. /Ilibskywave\src /Ilibskywave\src\generated /Ilibskywave\src\ct_tasks /Ilibskywave\src\rf_tasks /Ilibskywave\src\rb_tasks /IG:\dev\boost-1.52.0 /IG:\dev\glew-1.9.0\include /IG:\dev\glm-0.9.4.1 /IG:\dev\tinyxml-2.6.2\include /Ilibswgl\include /Iinclude /IG:\dev\zeromq-2.2.0\include /IG:\dev\libpng-1.5.1 /IG:\dev\zlib-1.2.7\include /IG:\dev\tbb-4.1.20121003.oss\include /Iinclude /Iinclude /Z7
1>G:\dev\glm-0.9.4.1\glm/./gtx/simd_vec4.hpp(70): error #77: this declaration has no storage class or type specifier
1> GLM_ALIGNED_STRUCT(16) fvec4SIMD
1> ^
1>
1>G:\dev\glm-0.9.4.1\glm/./gtx/simd_vec4.hpp(72): error : type name is not allowed
1> enum ctor{null};
1> ^
1>
1>G:\dev\glm-0.9.4.1\glm/./gtx/simd_vec4.hpp(72): error : expected a "}"
1> enum ctor{null};
1> ^
1>
........

This could be trivially fixed in glm/core/_detail.hpp by adding few lines for ICPP case.

Patch:
Left file: C:\Users\someone\Desktop\glm-0.9.4.1.vanilla\glm\core_detail.hpp
Right file: G:\dev\glm-0.9.4.1\glm\core_detail.hpp
465a466,472

elif (GLM_COMPILER & GLM_COMPILER_INTEL)

define GLM_DEPRECATED

define GLM_ALIGN(x) __declspec(align(x))

define GLM_ALIGNED_STRUCT(x) __declspec(align(x)) struct

define GLM_RESTRICT

define GLM_RESTRICT_VAR __restrict

define GLM_CONSTEXPR

P.S. Haven't checked this fix under linux, but on windows works.
Thanks

In glm 0.9.4.1 in func_common.inl there are compiler errors in isnan(x) and isinf(x) when build with the CUDA compiler nvcc with GLM_FORCE_CUDA defined.

The problem is, that there is no special case for GLM_FORCE_CUDA and the functions std::isnan(x) and std::isinf(x) are unknown to nvcc.

My suggestion to fix this error is to add a special case for when GLM_FORCE_CUDA is defined:

    template <typename genType> 
    GLM_FUNC_QUALIFIER bool isnan(genType const & x)
    {
        GLM_STATIC_ASSERT(detail::type<genType>::is_float, "'isnan' only accept floating-point inputs");

#       if(GLM_COMPILER & (GLM_COMPILER_VC | GLM_COMPILER_INTEL))
            return _isnan(x) != 0;
#       elif(GLM_COMPILER & GLM_COMPILER_GCC)
#           if(GLM_PLATFORM & GLM_PLATFORM_ANDROID)
                return _isnan(x) != 0;
#           else
                return std::isnan(x);
#           endif
#       else
#           ifdef GLM_FORCE_CUDA
                return isnan(x) != 0;
#           else
                return std::isnan(x) != 0;
#           endif
#       endif
    }

and

    template <typename genType> 
    GLM_FUNC_QUALIFIER bool isinf(
        genType const & x)
    {
        GLM_STATIC_ASSERT(detail::type<genType>::is_float, "'isinf' only accept floating-point inputs");

#       if(GLM_COMPILER & (GLM_COMPILER_INTEL | GLM_COMPILER_VC))
            return _fpclass(x) == _FPCLASS_NINF || _fpclass(x) == _FPCLASS_PINF;
#       elif(GLM_COMPILER & GLM_COMPILER_GCC)
#           if(GLM_PLATFORM & GLM_PLATFORM_ANDROID)
                return _isinf(x) != 0;
#           else
                return std::isinf(x);
#           endif
#       else
#           ifdef GLM_FORCE_CUDA
                return isinf(x) != 0;
#           else
                return std::isinf(x) != 0;
#           endif
#       endif
}

If I understood correctly the purpose of the intersectRay function, it contains a few errors.

Edit: The intersectLineSphere function is also incorrect.

1.) The function has a sphere center parameter, but ignores it and assumes that the sphere is in the origo.
2.) It calculates the length of the ray direction vector, but later on uses this vector as a unit vector.
3.) The position calculation is simply wrong. It multiplies the direction vector with the radius of the sphere instead of the calculated intersection distance.

Here is a corrected implementation with "floating-point safeguards" on the quadratic equation solving too.
The quadratic equation implementation is based on this pdf: http://www.scilab.org/content/download/1106/10848/file/scilabisnotnaive.pdf

template <typename genType>
    GLM_FUNC_QUALIFIER bool intersectRaySphere
    (
        genType const & rayStarting, genType const & rayDirection,
        genType const & sphereCenter, typename genType::value_type sphereRadius,
        genType & position, genType & normal
    )
    {
        genType unitRayDirection = normalize(rayDirection);
        genType diff = rayStarting - sphereCenter;
        typename genType::value_type Epsilon = std::numeric_limits<typename genType::value_type>::epsilon();
        typename genType::value_type b = dot(diff, unitRayDirection);
        typename genType::value_type c = dot(diff, diff) - sphereRadius * sphereRadius;
        typename genType::value_type d = b * b - c;
        if( d < 0 )
        {
            return false;
        }
        typename genType::value_type q = -(b + sign(b) * sqrt(d));
        if( q <= Epslion)
        {
            return false;
        }
        typename genType::value_type x = c / q;
        if(x <= Epsilon)
        {
            x = q;
        }
        position = rayStarting + rayDirection * x;
        normal = (position - sphereCenter) / sphereRadius;
        return true;
    }

And I would also like to add, that for most of the applications of this function simply returning (or assigning) the intersection distance (x) would be more useful. The rest can be calculated by the user if necessary.

I am new with this library.. but I think that there is a missing file in the last release archive.

If the option is left OFF, as it is by default, it seems to override the GLM_TEST_ENABLE_CXX_11 option that is also provided in the CMakeLists.txt file. This could quite easily cause someone to accidentally run the test suite with a C++98 compiler even if it was intended to run it with C++11.

Wouldn't it make sense for this option to not do anything for GCC users? Alternatively, it might make sense to leave the -pedantic option there but still not change the C++ standard version in that CMakeLists.txt section.

Provide functions to build both left-handed and right-handed projection matrices (both orthographic and perspective projections).

Provide functions for building view matrices using LookAt for both left-handed and right-handed coordinate systems.

This would make this library useful for both OpenGL and DirectX applications (or OpenGL applications with a left-handed coordinate system!).

There is no quaternion-based LookAt function. Ideally, this function would take a view direction, and an up vector. Here is one possible implementation, whi²ch assumes that the "front" of the object is towards +Z (should probably be an optional argument) :

vec3 right = cross(direction, desiredUp);
desiredUp = cross(right, direction); // re-orthogonalize

quat rot1 = RotationBetweenVectors(vec3(0.0f, 0.0f, 1.0f), direction);
vec3 newUp = rot1 * vec3(0.0f, 1.0f, 0.0f);
quat rot2 = RotationBetweenVectors(newUp, desiredUp);

return rot2 * rot1;

I just wanted to note, that on page 8, for C++ 11 it's the same paragraph as before, what doesn't really make sense. I'd think it should say the "second implementation", or something similar pointing out what are the differences.

C++98 implementation
The first implementation follows the GLSL conventions accurately however it uses macros which might generates name conflicts with system headers or third party libraries so that it is disabled by default. To enable this implementation, GLM_SWIZZLE has to be defined before any inclusion of <glm/glm.hpp>.

C++11 implementation
The first implementation follows the GLSL conventions accurately however it uses macros which might generates name conflicts with system headers or third party libraries so that it is disabled by default. To enable this implementation, GLM_SWIZZLE has to be defined before any inclusion of <glm/glm.hpp>.

Is there any chance to see this feature in future releases?
Or does dual quaternion feets glm paradigm as separate object in extensions? If it is, can i provide pull request with existing implementation based on glm::quat for review, when i`ll finish converting it to glm code conventions?
Thanks for attention

core/func_common.inl contains several times the following line :

GLM_STATIC_ASSERT(detail::type::is_float, "'mix' only accept floating-point inputs");

in functions named isnan, step, smoothstep. Look like copy-paste errors.

I got some compilation error using MinGW:

In file included from ....\include/glm/gtc/constants.hpp:184:0,
from D:\src\sgct\src\sgct\Engine.cpp:26:
....\include/glm/gtc/constants.inl: In function 'constexpr T glm::epsilon() [with T = glm::detail::half]':
....\include/glm/gtc/constants.inl:38:40: error: invalid return type 'glm::half {aka glm::detail::half}' of constexpr function 'constexpr T glm::epsilon() [with T = glm::detail::half]'

....\include/glm/./core/type_half.hpp:42:8: note: 'glm::detail::half' is not literal because:
....\include/glm/./core/type_half.hpp:42:8: note: 'glm::detail::half' is not an aggregate, does not have a trivial default constructor, and has no constexpr constructor that is not a copy or move constructor

Best Regards,

Miro

This can be achieved by testing for __cplusplus macro in setup.hpp.

from http://gcc.gnu.org/gcc-4.7/changes.html :
"G++ now sets the predefined macro __cplusplus to the correct value, 199711L for C++98/03, and 201103L for C++11"

The workaround is to define GLM_FORCE_CXX11

Hello.
I tried to compile my project with Intel compiler under Linux. I got this error message:

glm-0.9.4.0/glm/./gtc/ulp.inl(227): error: identifier "_nextafter" is undefined
return GLM_NEXT_AFTER_DBL(x, std::numeric_limits::min());

I think, that the problem is in the file glm/gtc/ulp.inl, line 191:

if(GLM_COMPILER & GLM_COMPILER_VC || GLM_COMPILER & GLM_COMPILER_INTEL)

The test for gtx::higherMultiple indicates a failure for me, with GCC 4.8 and Clang 3.2.

It is not entirely clear how the function should perform when the Source parameter is negative. Should it give the closest multiple that is in the positive direction, or the one with the highest absolute value?

Requiring
glm::higherMultiple(-5, 4) == -4 seems to indicate the former, while
glm::higherMultiple(-3, 4) == -4 would be true if the latter option was chosen.

Just as an aside, in my opinion, these kind of test functions would be easier to debug if the test data was in a separate array and the test function just iterated through it. The intermediate steps of applying a function template to some data are not very visible in debuggers.

Rearranging the test like this https://gist.github.com/muep/5009424 helped me in debugging this, because it usually results in computed values being stored somewhere where the debugger can find them. I am no sure if an anonymous struct type like in that example is portable to all compilers, but the data array could easily be placed elsewhere and in named type.

Everytime I try to include #include glm/gtc/quaternion.hpp I get alot of errors:

Error 1 error C2059: syntax error : 'constant' glm\gtc\quaternion.hpp 59 1

Error 2 error C2143: syntax error : missing ';' before '}' glm\gtc\quaternion.hpp 59 1

Error 3 error C2238: unexpected token(s) preceding ';' glm\gtc\quaternion.hpp 59 1

Error 4 error C2039: 'length' : is not a member of 'glm::detail::tquat' glm\gtc\quaternion.inl 38 1

Error 5 error C2039: '{ctor}' : is not a member of 'glm::detail::tquat' glm\gtc\quaternion.inl 46 1

Warning 6 warning C4346: '{ctor}' : dependent name is not a type glm\gtc\quaternion.inl 51 1

Error 7 error C2061: syntax error : identifier 'value_type' glm\gtc\quaternion.inl 51 1

Error 8 error C2039: '{ctor}' : is not a member of 'glm::detail::tquat' glm\gtc\quaternion.inl 58 1

Warning 9 warning C4346: '{ctor}' : dependent name is not a type glm\gtc\quaternion.inl 63 1

Error 10 error C2061: syntax error : identifier 'value_type' glm\gtc\quaternion.inl 63 1

Error 11 error C2039: '{ctor}' : is not a member of 'glm::detail::tquat' glm\gtc\quaternion.inl 72 1

Error 12 error C2039: '{ctor}' : is not a member of 'glm::detail::tquat'glm\gtc\quaternion.inl 108 1

Error 13 error C2039: '{ctor}' : is not a member of 'glm::detail::tquat' glm\gtc\quaternion.inl 117 1

Error 14 error C2039: '{ctor}' : is not a member of 'glm::detail::tquat' glm\gtc\quaternion.inl 126 1

Error 15 error C2039: '[]' : is not a member of 'glm::detail::tquat' glm\gtc\quaternion.inl 135 1

Error 16 error C2039: '[]' : is not a member of 'glm::detail::tquat' glm\gtc\quaternion.inl 141 1

Error 17 error C2065: 'value_type' : undeclared identifier glm\gtc\quaternion.inl 149 1

Warning 18 warning C4346: 'glm::detail::tquat::*=' : dependent name is not a type glm\gtc\quaternion.inl 149 1

Error 19 error C2143: syntax error : missing ')' before 'const' glm\gtc\quaternion.inl 149 1

Error 20 error C2039: '*=' : is not a member of 'glm::detail::tquat' glm\gtc\quaternion.inl 149 1

I don't know if I'm missing something or not but generally I just included the header files and included #include glm/gtc/type_ptr.hpp since I need the glm::value_ptr to get the pointer to the matrices.

I get another error in the rotate functionality which uses detail::tmat4x4 Rotate(detail::tmat4x4::null);

but it seems that it cant find detail::tmat4x4::null ... I'm new to C++.

This can be avoided externally by not normalizing a 0 magnitude vector, but it can also be solved in glm by adding std::numeric_limits::min() to the length before normalizing.

Admittedly I am not very familiar with numeric_limits, so I might be overlooking something. Is excluding this an intentional design decision?

In some of the comments the ascii minus character(0x2D) is replaced with the Unicode Em-Dash character(0x2013) . This causes the following problems in Visual Studio when the system local is set to Japanese:

1. On compile, warning C4819 is given:

"/glm/core/func_integer.hpp : warning C4819: The file contains a character that cannot be represented in the current code page (932). Save the file in Unicode format to prevent data loss."

2. If I open the offending file, I get the following error dialog message:

"File Load

Some bytes have been replaced with the Unicode substitution character while loading file [...]\glm\core\func_integer.hpp with Japanese (Shift-JIS) encoding. Saving the file will not preserve the original file contents."

3. Typing "glm::rot" and attempting auto-complete will cause the dialog from (2) to pop-up for func_common.hpp, and func_common.inl, followed by Visual Studio crashing.

The first two problems are at worst minor annoyances, but the last issue has been causing me a bit of trouble. I understand that this is mostly a Visual Studio problem; it shouldn't crash just because it gets some bad input. However I also think you probably don't want random Unicode characters in your comments, so I'm bringing this to your attention. I'm not 100% sure that the em-dash is the only Unicode character causing the problem, but it's the only one I've found.

Hello,

I get errors about undefined isnan() and isinf() functions when compiling some code using GLM (I used latest version from Git 0.9.4 branch).

My compilation environment is Cygwin + Android NDK r8d + (that's the most important part) Clang 3.1 toolchain.

In order to reproduce that just compile some GLM code with Android NDK r8d (the latest version) and make sure that you have the following line in your Application.mk file:

NDK_TOOLCHAIN_VERSION := clang3.1

I believe that this patch solves the issue:
https://gist.github.com/jimvonmoon/5047833

While this sounds a bit pedantic, it would help a bit with packaging glm for Fedora if there were no empty .inl files included in glm. Shipping an empty file in packaging is sometimes interpreted as a potential error.

The specific files are here:
glm/gtx/vec1.inl
glm/gtx/ocl_type.inl

If there is no planned use for these files, they could be considered for removal. Alternatively, just a comment that states that the files are intentionally blanc would be equally helpful.

the mix implementation in gtx/simd_vec4.inl contains errors

GLM_FUNC_QUALIFIER detail::fvec4SIMD mix
(
detail::fvec4SIMD const & x,
detail::fvec4SIMD const & y,
detail::fvec4SIMD const & a
)
{
__m128 Sub0 = _mm_sub_ps(y.Data, x.Data);
__m128 Mul0 = _mm_mul_ps(a.Data, Sub0);
return _mm_mul_ps(x.Data, Mul0);
}

the last instruction in the current implementation is a multiplication when it should be an addition

This is the correct implementation:

GLM_FUNC_QUALIFIER detail::fvec4SIMD mix
(
detail::fvec4SIMD const & x,
detail::fvec4SIMD const & y,
detail::fvec4SIMD const & a
)
{
__m128 Sub0 = _mm_sub_ps(y.Data, x.Data);
__m128 Mul0 = _mm_mul_ps(a.Data, Sub0);
return _mm_add_ps(x.Data, Mul0);
}

also overloads for floats would be nice

Hi,

thanks for your amazing glm library. I was wondering whether it would
make sense to provide forwarded declarations in order to speed up
compilation. For example:

File: glmfwd.hpp

namespace glm {
namespace detail {
template struct tvec3;
template struct tvec4;
};
typedef float mediump_float_t;
typedef mediump_float_t mediump_float;
typedef detail::tvec3<mediump_float> mediump_vec3;
typedef detail::tvec4<mediump_float> mediump_vec4;
typedef mediump_vec3 vec3;
typedef mediump_vec4 vec4;
};

All headers in my project include glmfwd.hpp and all source files
include glm/glm.hpp. Have you considered to provide such forwarded
declarations for the most common data types of glm?

Thanks for your help.

Best regards,

Alex

See https://en.wikipedia.org/wiki/Tar_%28computing%29#Tarbomb

Preferably it should extract to a directory like "glm-0.9.4.1". Older versions like 0.9.3.2 was properly packaged.

I am trying to use glm as math library for my OpenGL based engine. The following code snippet works perfectly file when compiled with MSVC but throws weird compilation errors,

glm::mat4 m1(1.0f);
glm::mat4 m2(1.0f);
glm::mat4 m3(1.0f);

m3 = m1*m2;

The error that I get is as follows,

C:\Users\XXXXXXXXXX\AppData\Local\Temp\ccN8REJf.s: Assembler messages:
C:\Users\XXXXXXXXXX\AppData\Local\Temp\ccN8REJf.s:5944: Error: invalid offset, va
ue too big (0x00000400)
d:/android-ndk-r8c/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/..
lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/as.exe:
BFD (GNU Binutils) 2.21 assertion fail /usr/local/google/home/andrewhsieh/ndk-a
drewhsieh/src/build/../binutils/binutils-2.21/bfd/elf.c:2795
/cygdrive/d/android-ndk-r8c/build/core/build-binary.mk:263: recipe for target `
cygdrive/d/Project-src/TESTPROJECT/build/android/obj/local/armeabi/objs-debug
TESTPROJECT///__/engine/src/TESTFILE.o' failed

It worked fine when I compiled providing a overloaded * operator for matrix4 as follows,

if defined(ANDROID)

inline glm::mat4 operator* ( glm::mat4 const & m1, glm::mat4 const & m2 )
{
    glm::mat4 m3(1.0f);
    int i=0;

    for (i=0; i<4; i++)
    {
                            m3[i][0] =                                    (m2[i][0] * m1[0][0]) +
                                                                                                                            (m2[i][1] * m1[1][0]) +
                                                                                                                           (m2[i][2] * m1[2][0]) +
                                                                                                                            (m2[i][3] * m1[3][0]) ;

                            m3[i][1] =                                    (m2[i][0] * m1[0][1]) + 
                                                                                                                            (m2[i][1] * m1[1][1]) +
                                                                                                                            (m2[i][2] * m1[2][1]) +
                                                                                                                            (m2[i][3] * m1[3][1]) ;

                            m3[i][2] =                                    (m2[i][0] * m1[0][2]) + 
                                                                                                                            (m2[i][1] * m1[1][2]) +
                                                                                                                            (m2[i][2] * m1[2][2]) +
                                                                                                                            (m2[i][3] * m1[3][2]) ;

                            m3[i][3] =                                    (m2[i][0] * m1[0][3]) + 
                                                                                                                            (m2[i][1] * m1[1][3]) +
                                                                                                                            (m2[i][2] * m1[2][3]) +
                                                                                                                            (m2[i][3] * m1[3][3]) ;
    }

    return m3;
}

endif

Is there anything I need to do for Android to fix it?
Also I do not see any SIMD optimizations for Neon instructions, can you pls confirm if it is supported?

http://imdoingitwrong.wordpress.com/2011/01/31/light-attenuation/

I noticed in the documentation you recommend using:

glVertex3fv(glm::value_ptr(v));
glVertex3fv(&v[0]);
// etc.

You don't want implicit casting because of obvious issues, however how about something like this (untested):

namespace glm
{
    template <typename T> static inline void glVertex(const T& v);
    template <> static inline void glVertex(const tvec3<GLfloat >& v) {glVertex3fv(&v[0]);}
    template <> static inline void glVertex(const tvec3<GLdouble>& v) {glVertex3dv(&v[0]);}
// etc.
}

core_func_integer.cpp has a little number of tests... add test for findMSB and findLSB to ensure running issue on GCC are fixed.