24-bit float precision in color vectors?

Has anyone tested whether color data in a prim retains the full 24-bit float precision of the floats comprising the vector? I'm looking to store some non-color data in there (using a transparent texture to hide the prim) and I'm hoping someone can save me testing whether it's all retained.

I'm pretty sure prims only store 8 bits each of R, G, and B.

I know they'll store outside the range of 0.0 to 1.0, an that data outside that range will be read as the closest limit for the purpose of color ... but I don't remember if any greater precision is retrievable... you'd have to test.

In order to accurately store the values 0-255 in a float range of 0.0-1.0, you have to consider the representation of 1.0 / 255 and all multiples of it.

Normally, if the values were 0-256, it would be a trivial and exact representation using only up to 8 bits of significance (1/256 is 0.00000001 in binary). However, since the range is 0-255, there might not be exact representations, but depending on how they turn them back into 8-bit values, it could still return correct integer values without any conversion loss.

At least, as far as standard float tests are concerned, it seems to work fine, no rounding error is observed.

I think you have that backwards, Tal. 0..255 (256 values) can be perfectly mapped to binary floating point, but 0..256 (257 values) can't.

Oh, and to answer the question, yes, the value is still retained as a full vector. The color is interpreted from the actual data, and clamped during the conversion process for display. The stored color value is not affected, unless you fiddle with it in the editor.

No, it is correct. Remember, you're mapping from 0.0 to 1.0, not 0.0 to the division just shy of 1.0. There are actually only 255 divisions and 256 points. To get 256 divisions, you have to have 257 points.

0-255:

0 -> 0.0/255.0 = 0.0
1 -> 1.0/255.0 = 0.003921568627450980392156862745098d ~= 0.00000001000000010000001b
...
254 -> 254.0/255.0 = 0.9960784313725490196078431372549d ~= 0.11111110111111101111111b
255 -> 255.0/255.0 = 1.0d = 1.0b

0-256:
0 -> 0.0/256.0 = 0.0
1 -> 1.0/256.0 = 0.00390625d = 0.00000001b
...
255 -> 255.0/256.0 = 0.99609375d = 0.11111111b
256 -> 256.0/256.0 = 1.0d = 1.0b

Doh!

/me wonders if anybody is going to just test it and see what happens.

vector colorIn = <0.000001, 0.000002, 0.000003>;

llSetColor (colorIn, 0);

if (llGetColor(0) != colorIn)
llOwnerSay ("Bah!";
else
llOwnerSay ("Yay!";

er.. can you compare vectors like that? IIRC seems busted.

edit: or whatever min/max float values you want to use.

It is in fairly common use for storing values; I also tested it to make sure LL hadn't busted it before I posted the "to answer the question" post above.

I also just tested myself; no rounding observed. Huzzah! Thanks to all who responded.

I've never heard of using color on faces for storing data. Neat idea but am annoyed I didn't think of it first.

So.. What's the conclusion? How many bits per face can we keep? Anybody tried faking up texture UUIDs to store larger values?

Storing data as color values on faces is, if anything, a novel idea, but why do so when you can store quite a bit more data as strings (127 bytes worth) in the object description? Back in the day, before LL caught on, one could store upwards of 8k of data there, but LL figured it out and plugged up that hole

The idea of storing data in a prim's colors is not new at all, as shown in this post from 11-19-2003, 09:42 AM :



/13/b5/6935/1.html

because it neatly stores an extra vector or 3*4bytes of float values beyond that field, doesn't need to be cast, and isn't immediately visible/readable to anyone editing =)

there're lots of fields that can be used this way.

Yeah, you can store data in the texture field, but it must be a valid key (even though it doesn't exist in the asset server), otherwise, you get a "texture not found" error (anything not a key is assumed to be in object inventory).