PDA

View Full Version : GLMath 'could not deduce template' problem



jbacon
11-05-2009, 01:38 PM
hi all,

I just got word we can post GLM questions here, so here goes :)
I have a hard time compiling the following method:

class SomeClass{
...
Vector3 center(){ return( ( m_lo + m_hi ) / 2.0 ); }
...
};
where Vector3 is a vec3 typedef and m_lo and m_hi are Vector3's. I keep getting errors similar to this:

'glm::detail::tquat<valType> glm::detail::operator /(const glm::detail::tquat<valType> &amp;,const valType &amp;)' :
could not deduce template argument for 'const glm::detail::tquat<valType>&amp;' from 'glm::detail::tvec3<valType>'

whereas I obviously need the template for (const glm::detail::vec3<valType> &amp;,const valType &amp;),
which I believe is defined in type_vec3.inl(491) by inline tvec3<T> operator/ (const tvec3<T>&amp; v, T const & s)

anyone have an idea what's going on ?

J

Groovounet
11-05-2009, 04:42 PM
Hi,

GLM is really strict on types: there is no automatic cast at all.
'2.0' is a double but you are using it with a vec3 which is based on single-precision floating-point numbers.

To make your code build replace it with:



Vector3 center(){ return( ( m_lo + m_hi ) / 2.0f ); }


GLM is strict based on GLSL API, sementics and conventions so that based on GLSL knowledge, you know how to use GLM. In GLSL conversions are explicits so GLM conversions are.

Alternative:


Vector3 center(){ return( ( m_lo + m_hi ) / float(2.0) ); }

jbacon
11-09-2009, 01:42 PM
hi, thanks for your answer.

I figured as much and I tried that before.
However, when I explicitly cast to float, or use a qualifier (2.0f), I get the following error:

1>e:\development\glm-0.8.4.0\glm\core\type_half.inl(249) : error C2440: '<function-style-cast>' : cannot convert from 'const RenderTools::Vector3' to 'float'
1> No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
1> e:\development\rendertools-1.0\src\types.h(187) : see reference to function template instantiation 'glm::detail::half::half<RenderTools::Vector3>(const U &amp;)' being compiled
1> with
1> [
1> U=RenderTools::Vector3
1> ]

which I understand even less.
I compile with the following:

#define GLM_SWIZZLE GLM_SWIZZLE_FULL
#define GLM_MESSAGE GLM_MESSAGE_ALL
#define GLM_PRECISION GLM_PRECISION_MEDIUMP_FLOAT | GLM_PRECISION_MEDIUMP_INT | GLM_PRECISION_MEDIUMP_UINT

#include <glm/setup.hpp>
#include <glm/glm.hpp>
#include <glm/ext.hpp>
#include <glm/virtrev.hpp>


Oviously, I'm missing something, but I don't see it.
Do you ?

Jonathan

ps sorry for the slow response, I expected an automatic mail on your response, but I didnt get any. I'll check in more regularly.

jbacon
11-09-2009, 02:01 PM
hm, i get the same eror elsewhere, and changing the following line



Vector3 center = m_center + b.m_center;

to:


Vector3 center = m_center;
center += b.m_center;

resolves the issue. I (still) don't see what's going on.
any insights ?

thanks,

Jonathan

jbacon
11-09-2009, 03:08 PM
on the same token: I keep having problems with the following:

Quaternion q1( toQuat( m_current ) );
Quaternion q2( toQuat( m_current ) );
q1 += q2;

where m_current is a mat4.
the response is:

1>e:\development\rendertools-1.0\src\node.cpp(57) : error C2676: binary '+=' : 'RenderTools::Quaternion' does not define this operator or a conversion to a type acceptable to the predefined operator

changing the code to


q1 = q1 + q2


gives me:
1>e:\development\rendertools-1.0\src\node.cpp(57) : error C2679: binary '=' : no operator found which takes a right-hand operand of type 'glm::detail::half' (or there is no acceptable conversion)
1> e:\development\glm-0.8.4.0\glm\gtc\quaternion.hpp(54): could be 'glm::detail::tquat<valType> &amp;glm::detail::tquat<valType>::operator =(const glm::detail::tquat<valType> &amp;)'
1> with
1> [
1> valType=float
1> ]
1> while trying to match the argument list '(RenderTools::Quaternion, glm::detail::half)'

I'm a bit at a loss here. hope someone can help.

TIA,

jonathan

Groovounet
11-10-2009, 04:27 AM
The error message is weard ... you can't cast a vec3 to a float.

This is even wearder:
Vector3 center = m_center + b.m_center;

to:
Vector3 center = m_center;
center += b.m_center;

If m_center and center are vec3 is should worked (I tried to be sure!)
If m_center is a float is should worked as well.

That's the only cases where it should work.

Change this (That I don't see how it could build):


#define GLM_SWIZZLE GLM_SWIZZLE_FULL
#define GLM_MESSAGE GLM_MESSAGE_ALL
#define GLM_PRECISION GLM_PRECISION_MEDIUMP_FLOAT | GLM_PRECISION_MEDIUMP_INT | GLM_PRECISION_MEDIUMP_UINT

#include <glm/setup.hpp>
#include <glm/glm.hpp>
#include <glm/ext.hpp>
#include <glm/virtrev.hpp>


With just:


#include <glm/glm.hpp>

Groovounet
11-10-2009, 04:28 AM
By the way you are not using the last release:
https://sourceforge.net/projects/glf/files/glm/glm-0.8.4.2/glm-0.8.4.2.zip/download

jbacon
11-13-2009, 05:44 PM
weird it is. since

Vector3 center = m_center + b.m_center;

are absolutely sure both vec3's (typedef'd to Vector3 for
compatibilty reasons)

changing

#define GLM_SWIZZLE GLM_SWIZZLE_FULL
#define GLM_MESSAGE GLM_MESSAGE_ALL
#define GLM_PRECISION GLM_PRECISION_MEDIUMP_FLOAT | GLM_PRECISION_MEDIUMP_INT | GLM_PRECISION_MEDIUMP_UINT

#include <glm/setup.hpp>
#include <glm/glm.hpp>
#include <glm/ext.hpp>
#include <glm/virtrev.hpp>

to just

#include <glm/glm.hpp>

actually doesn't make a difference. (both build though)

J

Groovounet
11-16-2009, 03:24 AM
Would it be possible to have a code sample (a file?) where you have the issue so that I can reproduce it?

Thanks!

jbacon
11-26-2009, 06:24 PM
thats a bit difficult right now, as things are spread out over
several files and in order to reproduce the problem, you'd have to build the whole system. I'll try to make a simple pathological example, as soon as my deadline of 4 december has passed..

J

jbacon
01-10-2010, 07:26 AM
hm. I don't know what happened, but revisiting this issue I can't reproduce it. Must have been a clash with some other lib's Im using, or my lack of understanding of templates. Anyway, I'll leave this topic as a 'dangling pointer'.. Thanks for the support, though.