Units changes break velocity addition demo

[capnrefsmmat]

bc6f7c55d7b646 has broken the velocity addition demo. The first step of the demo doesn't even show the center object anymore, and the second step shows the center object overtaking the right, which essentially stops moving. Similarly, the Doppler shift demo doesn't show the center object at all.

Looks like something calculating XView might be broken. I'll try to Firebug it later.

[capnrefsmmat]

The first issue is the center object not displaying. That's a result of the demo system telling it to change to a frame it's already in, so boostMagSq == 0 and half of the matrix ends up being NaNs. In the case where boostMagSq == 0, what matrix should cBoostMat return?

[Schroedingers-Hat]

The identity matrix. We could have a test to see if the velocities are below a certain threshold, this would avoid (but not fix) the catastrophic cancellation issue too A good test would be if gamma - 1 is near or less than 1/10^6 for 32 bit, or 1/10^15 for 64 bit. (I noticed there were some 32 bit numbers still floating around. Probably because it's set in scene.js.

[capnrefsmmat]

Hm. Just tried that and it doesn't seem to work. I'll have to try again when I have more time to Firebug it.

Ideally I'd like to remove this from scene.js:

    // If the new frame is basically the same as the old frame, don't bother.
    if (Math.sqrt(quat4.spaceDot(XShift, XShift)) < 0.0001 &&
        Math.sqrt(quat4.spaceDot(obj.COM.V, obj.COM.V)) < 0.0001) {
            return;
    }

and let cBoostMat and changeFrame be smart enough to not choke on small boosts.

[Schroedingers-Hat]

Fixed. You can remove that now, too.

[capnrefsmmat]

The second issue I mentioned:

and the second step shows the center object overtaking the right, which essentially stops moving

still isn't fixed. I should've filed two bugs, sorry. I've just removed the redundant code in 7e86150.

[Schroedingers-Hat]

Ah, that's definitely something funky with drawPast. Will look into it.

[Schroedingers-Hat]

Think it's fixed. I got a little over-zealous with putting in the normalization factor that I'd missed and put it somewhere it didn't belong ^_^

[capnrefsmmat]

Looks like it, although the light delay is still rather dramatic. We'll just have to do some rigorous testing later.

[Schroedingers-Hat]

Looks like it, although the light delay is still rather dramatic. We'll just have to do some rigorous testing later. Part of what you are seeing is that the shape of those objects is entirely non-physical. Nothing points to the right time and as such I don't really know how it should behave. Some of the rest is that one should expect light delay to be quite dramatic when things are moving at 0.91c Also bear in mind that until recently there was a bug in the radialV calculations which meant light delay was not as strong as it should have been. In addition to that, I may have missed some V[0] to V[3] changes or a c, so testing ahoy.