document differences to nim-glm
krux02 opened this issue · 2 comments
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.
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.
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.