Using Shorts for spacial Coordinates

The teleimmersion project generates huge point-cloud datasets,
with approximately 100,000 points per frame, each point having XYZ and RGB data.

In the interest of increasing the performance of (future) streaming of this data from the source machines into a target machine running croquet, i've been working on simply reducing the precision of the data.

I assume a maximum streaming thruput of 18MB per second, based on tests streaming within my own computer.

Originally, XYZ and RGB were each represented as triples of four-byte floats.
So, 3 * 4 + 3 * 4 = 24 bytes per point * 100,000 = 2.4MB per frame -> up to 7.5Hz.

RGB is an obvious target, since rendering cards at their base level can only handle colors with single-byte components.

So i made an option to represent the RGB values as triples of single-byte components.
So, 3 * 4 + 3 * 1 = 15 bytes per point * 100,000 = 1.5MB per frame -> up to 12.0Hz

I'm nearly finished with an option to represent the XYZ values as triples of two-byte signed shorts.
So, 3 * 2 + 3 * 1 = 9 bytes per point * 100,000 = 0.9MB per frame -> up to 20.0Hz


Here is a screenshot showing three different types of representations.
Random-point placement aside, they look pretty much identical.




Implementation Issues
---------------------

Changing to single-byte color components was relatively straight-forward.

Changing to two-byte spacial components has been a bit trickier.
OpenGL is perfectly happy being passed GLShorts for spacial data;
the card must be converting them to floats before running them thru the graphics pipeline. I haven't yet tested for performance issues here, but i don't expect any.
More complicated however is that Croquet of course works with B3DVector3, which is based on B3DFloatArray,which is based on FloatArray, which is of course, Floats.
Furthermore, Squeak doesn't even have a ShortArray!
What Squeak does have is ByteArray, which has convenience methods for accessing pairs of elements as shorts. (and longs, if you're in to that sort of thing)
So the data can be accessed for purposes such as finding bounding boxes and doing calculations.

Dealing with Scaling is so far definitely the trickiest issue.
Croquet does not use the usual scale feature of transformation matrices; rather it requires the actual vertices to be actually changed. David Smith once explained to me that this is to enable/simplify picking thru portals, if i recall correctly. In any event, i felt that reimplementing scale as a per-point conversion, multiplication, and unconversion would be prohibitively slow. So i'm trying out just putting scale right in the matrix. The sphere on the far right has been scaled this way. So far it's working well altho there must be some remaining issues with bounding box, as a TEditBox no longer works with the byte-spatial-components pointclouds. I'm about to look at this.