More about the math.

After being asked about it a few times I thought I should expound a bit more about Ardor3D's math library here.

As I mentioned, our math package currently uses double precision. This includes our Vector, Quaternion and Matrix classes. Actual mesh data is of course not part of this, nor is ColorRGBA. The reason for our move to use double is simple: current customers of Ardor Labs want higher accuracy. (Yes, we want to make money from our work and we want others to as well.)

Having double precision camera matrices and transforms helps a lot when dealing with coordinate systems needing more than 8 places (for example, if you want to model a section of the earth or conversely, something happening at the micro-scale.) This is particularly true about the camera control matrix math where even small inaccuracies cause noticeable camera wobble.

Using double precision means a little more memory but since this is only transforms (15 values in the current Transform object), we're talking about 60 more bytes or so per Transform in your scene graph -- probably not a deal breaker.

The other perhaps more legitimate question is performance. As I understand it, floating point calculations on a modern CPU (Pentium or higher) are done at 80bits or more regardless of using Java's 64bit double or 32 bit float. Where speed enters the picture then is how many math primitives you can fit into cache or RAM. The question is whether that matters much with today's current cache and RAM sizes? Will you have tens of thousands of different matrices you are needing to multiply out in fast succession? Sure it is possible.

So all of that said, we are interested in a single primitive type for now largely because we'd like to avoid duplicating our efforts across multiple versions of each math class - we just don't have time for premature optimization. Adding support for less precise math is something that is largely an exercise in copying and search and replace.

On the subject of immutability, we've taken a rather simplistic approach that "works". Basically we're using a final boolean mutable field and hiding other member fields behind accessor methods that check for immutability. Nothing fancy, and a new better way may come as a collaborative community starts participating.