OpenGL Mathematics (GLM) to Ogre Maths conversion functions?

[Klaim]

I'm using GLM in my non-graphic code involving spatial manipulations and obviously I often have to pass result of computations as positions and orientations to Ogre, converting from glm::vec3 to Ogre::Vector3 for example.

There have been discussions at some point about using something like GLM as a dependency of Ogre instead of the current Ogre Math libraries. However I think they don't overlap enough to be a good idea.

However, conversion functions between both libraries would be helpful I think.
So I was wondering what the team think about providing one or two headers providing:

- convertion functions for vector,quaternion and matrix functions between Ogre and glm;
- maybe add an option to add extension to Ogre constructs to take glm constructs as parameters (like Ogre::Vector3 taking a glm::vec3 implicitely at construction);

I didn't setup this kind of code yet but I want to do it starting today for my own code. I was wondering if it would be more helpful if distributed with Ogre.

What do you think?

[PhilipLB]

Would this mean to increase the size of Ogre because it then depends on GLM?

[Klaim]

Would this mean to increase the size of Ogre because it then depends on GLM?

The way I was thinking it is to provide an optional header, which is not used into Ogre, so Ogre don't have to use or provide GLM, a bit like when Ogre uses TBB or Boost.
The second point, adding constructors, would ba activated through CMake options and macros.
In both cases, Ogre wouldn't add glm as a dependency, but using the feature would require the user to have glm available ( and accessible using #include <glm/...> )
As I was saying it is not differnt than using teh boost option for exemple (actually it's simpler)

[phobossion]

You could include global conversion operators in that header file and you'd even be fine without injecting constructurs

[Klaim]

You could include global conversion operators in that header file and you'd even be fine without injecting constructurs

Unfortunately, AFAIK, (implicit) conversion fonctions have to be non-static members in C++. It's true for both constructor and conversion.
Or do you know a way to bypass this?


To clarify: the first point would be to add explicit conversion functions, while the second point would be to add implicit conversion functions. The second point therefore requires adding functions into one of the libraries and I think Ogre would be the right one.

That being said, just having explicit conversions would be nice already. I'm working on that first in my project and will post it here or in the wiki later.
The question is basically if it's worth providing it with Ogre, and if it is, would it be worth then adding the option to activate implicit conversion.
It would be worth in my current code, but I don't know for others.

[Kojack]

That being said, just having explicit conversions would be nice already. I'm working on that first in my project and will post it here or in the wiki later.

Here's a simple one:

Code: Select all

template <typename T1, typename T2>
T1 convertVector3(const T2 &v)
{
   return T1(v.x, v.y, v.z);
}

That can convert any vector3 to any other vector3, as long as the source exposes x,y,z members and the destination has a constructor that takes 3 numbers.
Not tested with GLM, but this should work:

Code: Select all

Ogre::Vector3 a(1,2,3);
glm::vec3 b;
b = convertVector3<glm::vec3>(a);
a = convertVector3<Ogre::Vector3>(b);

[phobossion]

You could include global conversion operators in that header file and you'd even be fine without injecting constructurs

Unfortunately, AFAIK, (implicit) conversion fonctions have to be non-static members in C++. It's true for both constructor and conversion.
Or do you know a way to bypass this?

Yeah, sorry, implicit conversion is not possible on global level, as far as I'm aware, I meant explicit functions as Kojack shown.

[Klaim]

That being said, just having explicit conversions would be nice already. I'm working on that first in my project and will post it here or in the wiki later.

Here's a simple one:

Code: Select all

template <typename T1, typename T2>
T1 convertVector3(const T2 &v)
{
   return T1(v.x, v.y, v.z);
}

That can convert any vector3 to any other vector3, as long as the source exposes x,y,z members and the destination has a constructor that takes 3 numbers.
Not tested with GLM, but this should work:

Code: Select all

Ogre::Vector3 a(1,2,3);
glm::vec3 b;
b = convertVector3<glm::vec3>(a);
a = convertVector3<Ogre::Vector3>(b);

I don't think it's a good idea because of several reasons. The first is the definition of Real which can change, so you need to provide the Real you use in the glm code. The other is that you can't generalize that to glm::quat as it don't have the same sequence of members.
I think we can't avoid specializations here.

That said, a general version with specializations on the side could be ok.

[Kojack]

The other is that you can't generalize that to glm::quat as it don't have the same sequence of members.

That's why it's called convertVector3, it's for 3d vectors.
I use convertQuaternion for quaternions (any ordering of w,x,y,z handled, as long as the members are exposed, I copy members individually).
Been using them for years for many different physics libraries, ogre, my own math classes and others.
Matrices are a bit trickier, but I convert matrices from one class to another so rarely that I never bothered writing a conversion template, I just do it directly when needed.

Of course it doesn't work for math classes like in Havok, which are heavily SSE based.

[Klaim]

I see, I'll go with generalization then specialization, it should work nicely as you suggests. Thanks!

I had to fix something else before doing the conversion header so I'll submit something here in the weekend after I fix my code.

[Klaim]

As a first step I went with only specialization to get things simple. Here is what I use so far in my project:

Code: Select all

#ifndef HGUARD_NETRUSH_SYSTEM_VIEW_MATHSCONVERSION_HPP__  // obviously, this is specific to my code
#define HGUARD_NETRUSH_SYSTEM_VIEW_MATHSCONVERSION_HPP__

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

#include <OgreVector2.h>
#include <OgreVector3.h>
#include <OgreVector4.h>
#include <OgreQuaternion.h>
#include <OgreColourValue.h>

namespace glm
{
	namespace ogre_compat
	{
		typedef detail::tvec2<Ogre::Real> vec2;
		typedef detail::tvec3<Ogre::Real> vec3;
		typedef detail::tvec4<Ogre::Real> vec4;
		typedef detail::tquat<Ogre::Real> quat;
	}
	
	inline Ogre::Vector2 to_ogre( const ogre_compat::vec2& vec )
	{
		return Ogre::Vector2( vec.x, vec.y );
	}

	inline Ogre::Vector3 to_ogre( const ogre_compat::vec3& vec )
	{
		return Ogre::Vector3( vec.x, vec.y, vec.z );
	}

	inline Ogre::Vector4 to_ogre( const ogre_compat::vec4& vec )
	{
		return Ogre::Vector4( vec.x, vec.y, vec.z, vec.w );
	}

	inline Ogre::Quaternion to_ogre( const ogre_compat::quat& q )
	{
		return Ogre::Quaternion( q.w, q.x, q.y, q.z );
	}

	inline Ogre::ColourValue to_ogre_color( const ogre_compat::vec3& vec )
	{
		return Ogre::ColourValue( vec.r, vec.g, vec.b );
	}

	inline Ogre::ColourValue to_ogre_color( const ogre_compat::vec4& vec )
	{
		return Ogre::ColourValue( vec.r, vec.g, vec.b, vec.a );
	}


}

namespace Ogre
{
	inline glm::ogre_compat::vec2 to_glm( const Ogre::Vector2& vec )
	{
		return glm::ogre_compat::vec2( vec.x, vec.y );
	}
	
	inline glm::ogre_compat::vec3 to_glm( const Ogre::Vector3& vec )
	{
		return glm::ogre_compat::vec3( vec.x, vec.y, vec.z );
	}

	inline glm::ogre_compat::vec4 to_glm( const Ogre::Vector4& vec )
	{
		return glm::ogre_compat::vec4( vec.x, vec.y, vec.z, vec.w );
	}

	inline glm::ogre_compat::vec4 to_glm( const Ogre::ColourValue& vec )
	{
		return glm::ogre_compat::vec4( vec.r, vec.g, vec.b, vec.a );
	}

	inline glm::ogre_compat::quat to_glm( const Ogre::Quaternion& q )
	{
		return glm::ogre_compat::quat( q.w, q.x, q.y, q.z );
	}

}


#endif

I think there is a possibility of having a general conversion header with code similar to what Kojack suggested, then having specialization in another header for glm, in particular for colors. To simplify the naming and avoid duplication of concept name, I think that a super function convert<Ogre::Vector3>(some_vector3) could be written, calling Kojack's code.
So next step is to try the generalized approach. (I'm doing this only sometime as I'm a bit in a rush right now)