Currently the FastMath class mostly uses methods from the java class Math to do the calculations. Searching in the internet, I came accross this FastMath class which claims to have methods less accurate but much faster than those used in java’s Math. Also you might want to check this implementation of pow which is significantly faster but is very inaccurate.
It is no secret that trigonometry functions are rather slow in java on x86 machines, due to the IEEE floating point accuracy java demands and the CPU can't deliver. But i think I have read an article that made some very good points why there are no good ways to work around that (even lookup tables ended up with bad marks there). It's a shame I can't remember anymore where I found that article…
Java's implementation of the math methods operates on double values, while jME operates with float values. Mathematical accuracy is not a requirement in video games, speed is a requirement.
The double (of Java Math) VS float issue is a problem that I already raised in a older post: http://www.jmonkeyengine.com/jmeforum/index.php?topic=2597.msg31761#msg31761. The answer have been enough for my poor knowledge of the problem but… the fact that you raised once more this problem… make me think that it could be changed.
Moreover, in that case, my suggestion was to base the new FastMath on a different native library. Java Math, infact, is invokes a native library.
I like the idea to provide two versions for slow functions, an accurate and a quick one. There are cases where you need all precision you can get, but in most cases the quick version is sufficient. The problem is how to "convince" JME to take the accurate version in one case and the quick version in another case. Should all math classes (Vectors, Matrices) get an "accuracy switch" :?
Very rarely (but, as usual, your mileage may vary) will Math or FastMath or the calculations in Vector3f be what slows your typical jME game down. If you are making a ray tracer, the situation is different of course.
I rolled my own physics and eventually switched from floats to doubles for accuracy, but I never saw that the implementation of math functions was anywhere close to being the bottleneck in terms of speed.
I suggest you:
- Simply use the regular high-accuracy math functions everywhere
- Profile to identify bottlenecks
- Where needed, assess your accuracy requirement and implement a math function of that accuracy
I don't think general math libraries of different accuracies is the way to go.