hex values on arrays

Hi, I am new to the forums, and to Collada, I’ve been reading about it, and I am willing to support collada in my future projects :slight_smile:

I have some experience parsing XML files, and other text file formats, and I realized how bad is to write/read floating point values from a text file.

To avoid the problem, I began to write my floating point values as hexadecimal values (actually, a float casted to a DWORD), and I was wondering, if it could be possible for collada to support this?

In practice, it would mean to add a new tag, that could be called ARRAY_HEXFLOAT or something like that, and the values would look like: 0 0 0 3f8000 3f4f344 , etc

The first advantage is that the original floating point value is stored unaltered, and without loosing precision, contrary to what happens when saving the value in decimal format. This would give the file format the same “precision quality” than a binary file format.

The second advantage is document size: based on my experience, saving an array of floats uses more characters than saving the same array using the same values, casted to DWORDs, and written in hexadecimal format.

There’s another advantage, and it is that hexadecimal values are much easier to read/parse than floating point values, because they only need a cast, in the past, I had lots of troubles reading floats from text files, specially from the old ASC file format…

Hope you can consider this suggestion, and I apologize if this has already been discussed

Vicente Penades

The only drawback of storing hex values, is that they are not portable. The hexadecimal representation of floats may differ from one platform to another.

Tom

I know this can be troublesome, and there’s also the problem of endianess… but, isn’t there an ISO standard for FLOATs?

There are many 'standard’s

Are you talking about 32 bits float, 64 bits floats ?
Or maybe half-float used by GPUs ?
but which one, the ATI or the nVidia representation ?
Or maybe you are referring to the CELL SPE float representation ?
Or maybe the float that is used in the low power mobile phone CPUs ?
What about the 10 bits Extended (float) type of C# ?

You could definitely decide to use one of those representations, and decide that will be the COLLADA representation, and then the various loaders will be in charge of converting back and forth with their internal representation. But it turns out that the XML-float standard that COLLADA is using is the best way to do this, and the easiest. Handling correctly all the differences between corner cases in all the various floating point representations is really not an easy task compared to parsing a string !

One of the myth that comes back all the time is this idea that saving the value in XML/text will loose precision. This is simply NOT TRUE. Given that enough decimal digits are used (9 for IEEE 32 bits floats), you have a perfect bijection between the COLLADA representation and the IEEE 32 bits representation. Now, if you want more precision, you can add more digits. Use 17, and now you are at the same precision of 64 bits floats.

So, you see, COLLADA representation meets all the goals, it enables to use one standard representation, easy to parse and save, cross-platform, that can guaranty the accuracy of the data in any precision required.

I would encourage you to revisit the data precision issue. How many decimals do you really need?
In the real word, precisions are not given on how many digits you have in 32 bits binary representation, but in real units. For example, +/- 1 millimeter, +/- 1 cm …
Since COLLADA is using real world units (default is m), it is really convenient to say what accuracy you want for your data in real units, thus in number of decimal places.

This being said, nothing prevent you from saving all the floating values in binary, e.g. raw format, and reference this within the COLLADA document, just like textures are currently referenced. When you think about it, this is exactly the same problem. Textures are to be represented in platform specific encoding, and therefore are not inserted in the COLLADA document, but referenced. But, wait, it is actually also possible to have the texture inside the COLLADA document using an array representation, and this is useful for embedding look-up tables for specific shader programs.

So COLLADA let you actually decide which way you want to go. Either the full accuracy cross-platform standard XML, or the binary platform specific representation. Your choice.