Which math library should be used?

[vvs-]

There are too many alternatives already: old vmath, Bullet and Matrix4. Also, there is GLM and who knows what else. They introduce incompatibilities and bugs. The project should decide and make a clear statement of direction.

[cochrane]

In theory I would like to use bullet's library, because we don't really have the option of not using it. It's what bullet spits out so we better get used to it.

The main problem is its lack of a true 4x4 matrix. btTransform is not suitable for graphics stuff, in particular projection matrices, as we learned a while back.

We could add our own btTransform4 for this purpose and use standard bullet for the rest.

[Lwmte]

As we already use Bullet physics, I would use it. Although the problem with bullet is it's too complicated for OpenGL matrix operations. When in old engine revisions I could do anything on matrix directly, in Bullet I have to call "extraction" method first, and also specify row or column or whatever... It is too unintuitive and just too complicated (and I also believe it's slower).

I support Cochrane here. Only thing I'm concerned about is the way to add btTransform4. Please, don't return to built-in source code! :smile:

[cochrane]

Some more notes:

• I'm against old vmath because it doesn't have operator overloading. Now, I strongly believe that operator overloading is wrong in almost all cases, including most situations where it's used in the C++ standards library, but actual mathematical operations on linear algebra datatypes is the one exception where it's not only permissible, it's a vast improvement in code readability.

  I also don't like how vmath uses void return and out pointer for absolutely everything. It requires you to allocate all sorts of temp buffers, which is always a code smell, and it's never clear whether the output can also be one of the inputs (usually not). Plus, a normalize that requires defining your own temp variable? That's just horrible.

• GLM: I've never heard of it before. Right now I've taken a look and it seems to be okay, but again the issues with bullet compatibility.

Only thing I'm concerned about is the way to add btTransform4. Please, don't return to built-in source code!

We could just add btTransform4.h to main OpenTomb. All we need is a function to create one from a btTransform, and this is actually trivial. The main difference over the current matrix4 would be to use btScalar instead of float, get rid of the own float4 (and ray4 and uint4, which aren't used here anyway), and probably get rid of the SSE code as well because in my experience that never provided any notable benefit.

[vvs-]

I feel that everyone is in favor of developing a new library on top of Bullet. That's fine as long as there is someone up to the task :eyeglasses:

[stohrendorf]

I have tried GLM a few times in my local checkout, and it seems pretty good, although it requires a major code rewrite. About bullet: As far as I can tell, this is only used for physics, isn't it? So here's my proposal: Do everything strongly related to physics with bullet, everything else with GLM, and write a few tiny conversion function between GLM and bullet. That way every library can do what it's designed for, and we only need to create that thin glue between the libs, which should ideally be limited to vectors (positional and rotational), although a few matrix operations would be convenient I think.

[Lwmte]

Then we also need to remove 'btScalar' from using anywhere where standard 'float' should be used as well.

Also, then Bullet should be absolutely removed from rendering process, which is not the case right now.

[stohrendorf]

As we have seen, bullet isn't suited for rendering, so I'd consider that an improvement.

[cochrane]

Adding a new third-party library to do stuff we can already do? Okay, if you insist, but I'm not overly enthusiastic about that idea.

[Lwmte]

And why all the neat matrix stuff was removed from vmath.cpp/h which was a second-party library after all, only to replace it with third-party one?

I just don't know to which extent we would use some extra math functions, as everything worked pretty well before with vmath.cpp/h. Only if we're planning some fun with geometry, rendering, or what? I'm not experienced in this field.