To put this part in perspective. When Quake III was around, level visibility was TIGHTLY controlled. It was rare to ever have anything more than 1000 meters away. So a “nearly” accurate 1/sqrt for normalization was ok.
Already in modern games, JME users worry about floating point precision for worlds 6,000 meters or more. So now that sqrt is only a few cycles… suddenly the accuracy tradeoff doesn’t seem so good.
Thank you for the heads up about bit manipulation being only in FastMath.java only, and not anywhere else in the library. This is what I guessed/hoped the case would be for JMonkey, since if any Java library at all used bit manipulation on floating point types, it would be you, but apparently FastMath.java is the only place. I can just ignore that class, or even re-write it if needed. Bit manipulation and shifting on integral Java types are no fear of mine.
No, floating point errors aren’t working out to be any good at all in Java, are they? Originally, the early days of Java 1.1, they weren’t even there. The decision was actually made to put them in. However, Java has somehow gone forward as it is, and for all those years the dependency on just how it is has grown and grown and grown… (groan).
I’m actually looking for a team of Java subsystem (beneath the hood) programming and building experts, who also know about Java root commands and C and mathematics, to help me make some large scale changes, for a special version of Java, to change these things. If I wanted to seek and advertise for such volunteers through here, what Forum area do you guys recommend that I post to?