document differences to nim-glm

[krux02]

I am just curious about the motivation behind this project since there is already nim-glm. There might be more people than just me who wonder why there are multiple vector math libraries.

[treeform]

When I first started with nim-glm it was creating strange errors, so I just started writing my own. At first I really wanted to not use macros/templates/generics and just have a very plain library. VMath started out very light but just became more and more like nim-glm as I needed to add features. Currently they are pretty similar.

Vmath is faster, speed is very important to us:

name ............................... min time      avg time    std dv   runs
GLM raytracer .................... 112.511 ms    113.910 ms    ±3.140   x100 
vmath raytracer ................... 73.786 ms     74.387 ms    ±0.904   x100

https://gist.github.com/treeform/843e83c670d403bc74daefea974178bc
https://github.com/treeform/vmath/blob/master/tests/bench_raytracer.nim

The nim-glm is missing some of the angular routines which I noticed when I made vmath tests run on nim-glm.

The speed of the 3 different vector representations is very baffling to me: https://github.com/treeform/vmath#vector-and-matrix-representation-and-benchmarks but it looks like both nim-glm and vmath use the fastest obj-array representation. So its the same in this regard.

VMath also works with javascript and shady (GLSL) backends which use the obj representation which nim-glm does not have.

VMath uses IVec3, UVec3, Vec3, DVec3 similar to GLSL rather then GLM that uses Vec3f/vec3f so its easier to transition to it.

I think VMath's readme and documentation is better, CI is better as its run on every commit. VMath has an API reference site: https://nimdocs.com/treeform/vmath and has a bunch of benchmarks.

If you want me to put a section in vmath docs on how its different from glm, I don't think I want to do that, there could be too many libraries to compare too.

I hope that answers your question.

[krux02]

When I first started with nim-glm it was creating strange errors, so I just started writing my own. At first I really wanted to not use macros/templates/generics and just have a very plain library. VMath started out very light but just became more and more like nim-glm as I needed to add features. Currently they are pretty similar.

Vmath is faster, speed is very important to us:

name ............................... min time      avg time    std dv   runs
GLM raytracer .................... 112.511 ms    113.910 ms    ±3.140   x100 
vmath raytracer ................... 73.786 ms     74.387 ms    ±0.904   x100

Well, I never benchmarked my library a lot. I did some minor benchmarking but most is simply implemented by feel. I think some optimizations can still be made with loop unrolling and forced inlining. But that requires tedios testing.

The nim-glm is missing some of the angular routines which I noticed when I made vmath tests run on nim-glm.

nim-glm is built functionality wise strictly very similar to glsl. It is designed to be compiled to glsl. I don't know which angular routines you were missing, are they part of c++ glm? If yes, opening a single issue would have motivated me enough to implement them to nim-glm.

VMath also works with javascript

not sure about that in nim-glm, never tested.

and shady (GLSL) backends which use the obj representation which nim-glm does not have.

What do you mean by that? nim-glm uses objects with arrays. Do you mean objects with a lot of members (unrolled array)? And did I mention nim-glm can be compiled to glsl. In fact it can be used in the vertex shader as well, here is an example:

https://github.com/krux02/opengl-sandbox/blob/master/experiment/main_shapes.nim#L273

It really seems like your project and my project have a lot of similarites.

VMath uses IVec3, UVec3, Vec3, DVec3 similar to GLSL rather then GLM that uses Vec3f/vec3f so its easier to transition to it.

This is clearly subjective, but I wanted names that all have the same length and I like to have my size and type definition in a single suffix, like 3f, exactly like all the fixed function opengl features. I don't like it when this part surrounds the type somehow.

I think VMath's readme and documentation is better, CI is better as its run on every commit. VMath has an API reference site: https://nimdocs.com/treeform/vmath and has a bunch of benchmarks.

Yes. I am not very motivated to write in depth documentation about boring, ported libraries.

If you want me to put a section in vmath docs on how its different from glm, I don't think I want to do that, there could be too many libraries to compare too.

Would be nice yes. But I can accept if you don't want to.

I hope that answers your question.

Yes thank you for your in depth answer.