<blockquote>
  <p>According to the article, a half is basically a 16 bit float and an snorm is a signed float dividied by 65535. Therefore, they are basically the same</p>
</blockquote>

<p>No, they're not, and you do the article a great disservice by suggesting that it says such a thing.</p>

<p>Yes, Half-floats are 16-bit floats. But they are <em>floating point numbers</em>, as <a href="https://en.wikipedia.org/wiki/IEEE_754" rel="nofollow noreferrer">defined in IEEE-754</a>. Which means that they can express a relatively large range of values.</p>

<p><a href="https://www.khronos.org/opengl/wiki/Normalized_Integer" rel="nofollow noreferrer">Normalized integers</a> can only directly express values in the range [0, 1] (for unsigned) and [-1, 1] (for signed). Floating-point numbers can extend beyond this range. <a href="https://www.khronos.org/opengl/wiki/Small_Float_Formats" rel="nofollow noreferrer">16-bit floats</a> can express numbers approximately on the range [-6.55*10<sup>4</sup>, 6.55*10<sup>4</sup>], and it can handle decimal values in-between them.</p>

<blockquote>
  <p>Why do they give a "good precision" and are "evenly distributed" (as opposed to the half)?</p>
</blockquote>

<p>Because that's how IEEE-754 works. After all, normalized 16-bit values and 16-bit float values have the same size. 16-bits of storage gives you 65536 different values, no matter how you interpret them. Therefore, to get the range of values outside of [-1, 1], 16-bit floats sacrifice some bits to define additional values.</p>

<p>16-bit floats give you about 3 decimal digits of precision. Normalized 16-bit values give you at most 5 (though the closer to zero you get, the fewer significant digits you get, unlike floating-point values).</p>

<blockquote>
  <p>why use the magic number 64 if I don't want to calculate it?</p>
</blockquote>

<p>No reason; it's just a made-up number.</p>

<blockquote>
  <p>Is it common to have models that don't exceed this specific value?</p>
</blockquote>

<p>Not particularly.</p>

<blockquote>
  <p>If I get good precision with half (or xnorm respectively) to save bandwidth, but in my application actually need really large position values, can I leverage the better precision of xnorm with a multiplication for "full" float and save myself from using double variables?</p>
</blockquote>

<p>No.</p>

<p>Generally speaking, model space positions do not <em>need</em> "really large position values". They're in model space, so they're generally expressed relative to a center position that's quite close to them. They don't really have to be in scale with the rest of the world either.</p>

<p>However, if your model space positions really do need "really large position values", then you have to use whatever gives you the precision you need. That's pretty much never <code>double</code>.</p>

CC BY-SA 3.0
2018-03-06T18:48:54.933Z
Nice answer but the part about 3 vs 5 digits of precision is misleading. It makes it sound as if a normalized integer is always better. Floating point has uniform relative precision while a normalized integer has uniform absolute precision. It just happens that the latter is what you want for model vertices.
Olivier
CC BY-SA 3.0
2018-03-07T06:47:02.287Z
I don't need really large position values, this was probably badly stated on my part. What I meant was models at "really large [i.e. far away from origin] positions in the world". Imagine a car simulator that spans more than 500km * 500km levels. For some reason I missinterpreted one of the articles sentence to say something about this. In any case, thanks for the answer, I'll edit the "disservice" question to mark it for future readers.
Tare
CC BY-SA 3.0
2018-03-06T16:43:26.390Z
2018-03-06T18:57:15.493Z
2018-03-06T18:57:15.493Z
Nicol Bolas
<p>I have just come across <a href="http://www.yosoygames.com.ar/wp/2018/03/vertex-formats-part-1-compression" rel="nofollow noreferrer">this article about half, snorm and unorm</a>, but I don't get some of the points (or why they work).</p>

<ol>
<li>According to the article, a <code>half</code> is basically a 16 bit float and an <code>snorm</code> is a signed <s>float</s> integer$^1$ dividied by <code>65535</code>. Therefore, they are basically the same, just that the snorm is represented in $[-1, 1]$ whereas the half is in $[-65520; 65520)$ (where did those 32 values go?) but doesn't need another multiplication to get to the "real" value.  Now the article says:</li>
</ol>

<blockquote>
  <p>Other people prefer 16-bit xNORM variants because they tend to give really good precision and it is evenly distributed.</p>
</blockquote>

<p>Why do they give a "good precision" and are "evenly distributed" (as opposed to the half)?</p>

<ol start="2">
<li><p>For <code>snorm</code> a division is suggested, by either $64$ or the maximum AABB value. I get the latter, that can be used for more or less any model then, but why use the magic number $64$ if I don't want to calculate it? Is it common to have models that don't exceed this specific value?</p></li>
<li><p>If I get good precision with <code>half</code> (or <code>xnorm</code> respectively) to save bandwidth, but in my application actually need really large position values, can I leverage the better precision of <code>xnorm</code> with a multiplication for "full" <code>float</code> and save myself from using  <code>double</code> variables?</p></li>
</ol>

<hr>

<p>$^1$ Edit for future readers. I wrongly assumed it was a float.</p>

CC BY-SA 3.0
2018-03-06T13:48:32.523Z
SNORMs and UNORMs are signed/unsigned *integers* divided by (2^M-1)
Simon F
CC BY-SA 3.0
2018-03-06T13:49:53.247Z
oh, I see. So all bits go directly into encoding the variable, rather than splitting it into exponent and mantissa, thus the (slightly) better precision?
Tare
CC BY-SA 3.0
2018-03-06T13:54:06.593Z
Well, all the bits are used in floats too :-)   Perhaps a better description is that range is more limited and that the precision throughout the range is uniform, rather than, as with floats, variable.  FWIW colour channel data, e.g,. RGB888, uses 8-bit unorms.
Simon F
<float>
How to work with half and snorm
Tare
# How to work with half and snorm

(Asked by: username_0 on 2018-03-06)

I have just come across [this article about half, snorm and unorm](http://www.yosoygames.com.ar/wp/2018/03/vertex-formats-part-1-compression), but I don't get some of the points (or why they work).

1. According to the article, a `half` is basically a 16 bit float and an `snorm` is a signed ~~float~~ integer$^1$ dividied by `65535`. Therefore, they are basically the same, just that the snorm is represented in $[-1, 1]$ whereas the half is in $[-65520; 65520)$ (where did those 32 values go?) but doesn't need another multiplication to get to the "real" value. Now the article says:

> Other people prefer 16-bit xNORM variants because they tend to give really good precision and it is evenly distributed.

Why do they give a "good precision" and are "evenly distributed" (as opposed to the half)?

2. For `snorm` a division is suggested, by either $64$ or the maximum AABB value. I get the latter, that can be used for more or less any model then, but why use the magic number $64$ if I don't want to calculate it? Is it common to have models that don't exceed this specific value?
3. If I get good precision with `half` (or `xnorm` respectively) to save bandwidth, but in my application actually need really large position values, can I leverage the better precision of `xnorm` with a multiplication for "full" `float` and save myself from using `double` variables?

---

$^1$ Edit for future readers. I wrongly assumed it was a float.

**Tags:** float

> **Comments:**
> **username_1**: SNORMs and UNORMs are signed/unsigned *integers* divided by (2^M-1)  
> **username_0**: oh, I see. So all bits go directly into encoding the variable, rather than splitting it into exponent and mantissa, thus the (slightly) better precision?  
> **username_1**: Well, all the bits are used in floats too :-)   Perhaps a better description is that range is more limited and that the precision throughout the range is uniform, rather than, as with floats, variable.  FWIW colour channel data, e.g,. RGB888, uses 8-bit unorms.  

---

## 1 answers

### Answer by username_2 on 2018-03-06. Score: 4 | Accepted answer

> According to the article, a half is basically a 16 bit float and an snorm is a signed float dividied by 65535. Therefore, they are basically the same

No, they're not, and you do the article a great disservice by suggesting that it says such a thing.

Yes, Half-floats are 16-bit floats. But they are *floating point numbers*, as [defined in IEEE-754](https://en.wikipedia.org/wiki/IEEE_754). Which means that they can express a relatively large range of values.

[Normalized integers](https://www.khronos.org/opengl/wiki/Normalized_Integer) can only directly express values in the range [0, 1] (for unsigned) and [-1, 1] (for signed). Floating-point numbers can extend beyond this range. [16-bit floats](https://www.khronos.org/opengl/wiki/Small_Float_Formats) can express numbers approximately on the range [-6.55\*104, 6.55\*104], and it can handle decimal values in-between them.

> Why do they give a "good precision" and are "evenly distributed" (as opposed to the half)?

Because that's how IEEE-754 works. After all, normalized 16-bit values and 16-bit float values have the same size. 16-bits of storage gives you 65536 different values, no matter how you interpret them. Therefore, to get the range of values outside of [-1, 1], 16-bit floats sacrifice some bits to define additional values.

16-bit floats give you about 3 decimal digits of precision. Normalized 16-bit values give you at most 5 (though the closer to zero you get, the fewer significant digits you get, unlike floating-point values).

> why use the magic number 64 if I don't want to calculate it?

No reason; it's just a made-up number.

> Is it common to have models that don't exceed this specific value?

Not particularly.

> If I get good precision with half (or xnorm respectively) to save bandwidth, but in my application actually need really large position values, can I leverage the better precision of xnorm with a multiplication for "full" float and save myself from using double variables?

No.

Generally speaking, model space positions do not *need* "really large position values". They're in model space, so they're generally expressed relative to a center position that's quite close to them. They don't really have to be in scale with the rest of the world either.

However, if your model space positions really do need "really large position values", then you have to use whatever gives you the precision you need. That's pretty much never `double`.

> **Comments:**
> **username_3**: Nice answer but the part about 3 vs 5 digits of precision is misleading. It makes it sound as if a normalized integer is always better. Floating point has uniform relative precision while a normalized integer has uniform absolute precision. It just happens that the latter is what you want for model vertices.  
> **username_0**: I don't need really large position values, this was probably badly stated on my part. What I meant was models at "really large [i.e. far away from origin] positions in the world". Imagine a car simulator that spans more than 500km * 500km levels. For some reason I missinterpreted one of the articles sentence to say something about this. In any case, thanks for the answer, I'll edit the "disservice" question to mark it for future readers.  

---

