Google's MathFu: a x-platform geometry math library for C++ | Hacker News Reader

Google's MathFu: a x-platform geometry math library for C++

google.github.io

60 pointsdsr1224 comments

Fascinating! They happen to depend on my vectorial[0] lib. Got a pull request earlier from google, so I had an inkling that something was up.

[0] https://github.com/scoopr/vectorial

From their github page: https://github.com/google/mathfu

What is the implication of this? I am not an Android developer; is this tracking common?

For applications on Google Play that integrate this tool, usage is tracked. This tracking is done automatically using the embedded version string (kMathFuFunVersionString), and helps us continue to optimize it. Aside from consuming a few extra bytes in your application binary, it shouldn't affect your application at all. We use this information to let us know if MathFu is useful and if we should continue to invest in it. Since this is open source, you are free to remove the version string but we would appreciate if you would leave it in.

It means that by compiling their code into your binary, your binary will contain a string that shows which version of the library you used. Anyone will be able to find it by searching your binary file for the raw bytes.

Since the code is open-source, you can always remove the string yourself.

This isn't scary. It's not phoning home to a web server or anything. If the library was dynamically linked as a .so/DLL instead of header-only, you'd be able to find the same information by looking at the ELF/EXE file header.

Would be great to offer some performance benchmarks to see if this outperforms similar linear algebra packages like eigen [1] which looks to have all the features they are offering and is headers only c++ library.

[1] http://eigen.tuxfamily.org

Also, Blaze [1], although I recall a bit of consternation on the Eigen mailing list due to some bogus benchmarks the Blaze folks were reporting (intentionally selecting poor options for Eigen in their comparisons) [2].

(edited to link to Eigen discussion -- Blaze was reporting MKL's performance as their own, despite Eigen supporting the same option to fall through to MKL)

[1] https://code.google.com/p/blaze-lib/ [2] http://comments.gmane.org/gmane.comp.lib.eigen/3423

Thanks for the link, haven't tried Blaze yet. Their benchmarks do look a little suspicious, especially as Armadillo will auto detect and link to MKL if installed.

Taking a course on OpenGL Graphics programming in university right now. We use GLM. It seems pretty good. If I'm not mistaken this is a (potential) replacement for GLM? If anyone knows GLM well could they discuss the differences between the two libraries? Is this worth investing time into?

GLM is extremely full featured compared to this. It's also very stable and portable. From GLM home page:

-------------

This library provides classes and functions designed and implemented following as strictly as possible the GLSL conventions and functionalities so that when a programmer knows GLSL, he knows GLM as well, making it really easy to use.

This project isn't limited to GLSL features. An extension system provides extended capabilities: matrix transformations, quaternions, half-based types, random number generation, procedural noise functions, etc.

GLM ensures interoperability with third party libraries, SDKs and OpenGL; replacing advantageously the deprecated matrix functions. It is a good candidate for software rendering (Raytracing / Rasterisation), image processing, physic simulations and any context that requires a simple and convenient mathematics library.

It is a platform independent library with no dependence to external libraries even OpenGL. GLM is written in C++98 but can take advantage of C++11 when available.

Only downside I found with GLM is it is dog slow when built without optimisations, making debugging painful, and as it is a header only library you can't compile an optimised version for debugging purposes. I'm not aware of any libraries that solve this problem though, while still remaining as fast when fully optimised. I did consider trying to create a custom recompiled header built with full optimisations but I never got around to investigating it as an option...

Try this [1]:

    #pragma GCC push_options
    #pragma GCC optimize("O2")
    #include <something>
    #pragma GCC pop_options

[1] https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-...

I'm working with Visual Studio :) But this would have been awesome, as I think it compiled with MinGW.

Is there a particular reason everything is implemented as member functions? I feel like typing things like

    mathfu::Vector <float, 3>::CrossProduct (u, v)

instead of

    cross_product (u, v)

would get really old really fast.

Awesome, this looks really handy for game development. Love that it's cross platform with Intel and ARM SIMD extensions too! Has anyone used it and have feedback on how well it works?

For some simpler vector stuff that's only C (and basically mostly SSE), I tend to use a personal fork of this for my toy games: https://github.com/rikusalminen/threedee-simd

The simplicity is what gets to me:

vcross(v1, v2) * v3 (with gcc/clangs vector extensions)

Great codegen too.

good, simple, basically identical to the code I've written myself when messing around with 3d stuff. nice to see a library that solves one problem well and doesn't carry around a lot of extra baggage.

Pretty nice, although the library is a bit small for my tastes. No planes, no intersections... interesting, but I'd like to see a more complete feature set.

Interesting project, but - and I hate to be that jerk - what possible reason was there to write it as "x-platform"?

I think it might be cultural. In the USA they write 'crossing' as 'Xing' (and use way too much text in traffic signals, with "PED XING" as one of the weirdest examples)

While at the same time the x in x-mas means the greek letter Chi that represents the ch-sound. just to get ahead of any confusion and to bring this thread around full O.

No C++11 features? Especially move constructor and assignment operator.

I'm pretty sure these are all POD value types. There are no internal pointers, nothing for a move constructor to shortcut and nothing special that an assignment operator needs to do besides the default.

That makes sense. Thanks.

Reply on news.ycombinator.com