Add description for CFrame rotational data

[Pyseph]

CFrames' rotational components are normalized when sent through remotes, as confirmed by sending a sample CFrame through a remote like so:

-- server
RemoteEvent:FireAllClients(CFrame.fromMatrix(Vector3.zero, Vector3.new(2, 0, 0), Vector3.new(0, 3, 0)))

-- client
RemoteEvent.OnClientEvent:Connect(function(cf)
        -- false, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0, 1 (same as OriginalCF:Orthonormalize())
	print(CFrame.fromMatrix(Vector3.zero, Vector3.new(2, 0, 0), Vector3.new(0, 3, 0)) == cf, cf)
end)

Since CFrames are orthnormalized, there end up only being three degrees of freedom instead of four; which means the fourth quaternion can be calculated through w = sqrt(1 - x^2 - y^2 - z^2).

This information was mainly based off of http://physicsforgames.blogspot.com/2010/03/quaternion-tricks.html, and is highly likely to be the implementation Roblox uses thanks to confirming the cframes' enforced orthogonality when passed through remotes.

[arcturus-prime]

The issue with this is that some of those supposed half-floats are occasionally outside the required range of [-1, 1] for a unit quaternion. For example, sending CFrame.Angles(math.pi / 4, math.pi / 3, 0), we get the following elements over the wire: 1D FF, D4 E7, and 91 51. One of these is far less than negative one regardless of what endianness you choose.

Thus, there are two possibilities:
A. This is the correct format, but these three elements are not IEEE 754 half-floats.
B. They are sending rotation in a different format, regardless of whether or not they are half-floats

We would need to figure out how these numbers are actually encoded if we wanted to validate this theory. My instinct tells me that you are correct in that this is the format, but that these numbers are fixed point fractional parts and not float16s.

[Pyseph]

this github comment section may be of interest: https://gist.github.com/StagPoint/bb7edf61c2e97ce54e3e4561627f6582
It supports values outside the [-1, 1] domain whilst being able to go down all the way to 5(!) bytes:

At 5 bytes the rounding errors are small enough I can even use the resulting quaternion for weapon fire.

[Pyseph]

I think I'm getting some more insight - similar to the above github code, the largest index is stored as the first number. Examples:

1. Original (5, -1, 9) -> Hex 0×54009391a6cc -> decimal 92361452529356 (first number is 9, aka largest index)
2. Original (-1, 2, 3) -> Hex 0×1c1d16b1de9e -> decimal 30911260384926 (first number is 3, aka largest index)

This showcases that Roblox likely compresses floats to integers, with more or less precision being shifted for the floats based on the first index's size.

[SolarScuffle-Bot]

I think I'm getting some more insight - similar to the above github code, the largest index is stored as the first number. Examples:

1. Original (5, -1, 9) -> Hex 0×54009391a6cc -> decimal 92361452529356 (first number is 9, aka largest index)
2. Original (-1, 2, 3) -> Hex 0×1c1d16b1de9e -> decimal 30911260384926 (first number is 3, aka largest index)

This showcases that Roblox likely compresses floats to integers, with more or less precision being shifted for the floats based on the first index's size.

What is this hex data of? Is this consistent among all samples?

[Pyseph]

The hex data was taken from the Squash CFrame docs; I haven't gotten around to testing it across more samples due to personal issues.