0

I am working with some data that can have large number values and the data itself is important.

The highest number seen is "89,482". So originally I was going to use unsigned int.

However using these numbers in usigned int format is causing some headaches, namely manipulating them in OpenGL shaders.

Basically things would be a lot simpler if I could use float instead.

However I don't fully understand the repercussions of storing a number like this as floating point. Especially as in the OpenGL case I don't have the choice of storing a single channel 32 bit floating point texture, only 16bit.

For 16bit float Wikipedia states:

Precision limitations on integer values
Integers between 0 and 2048 can be exactly represented
Integers between 2049 and 4096 round to a multiple of 2 (even number)
Integers between 4097 and 8192 round to a multiple of 4
Integers between 8193 and 16384 round to a multiple of 8
Integers between 16385 and 32768 round to a multiple of 16
Integers between 32769 and 65519 round to a multiple of 32
Integers equal to or above 65520 are rounded to "infinity".

So does this quite simply mean that in the case of the number "89,482", trying to store it in an 16bit OpenGL texture it will be rounded to infinity? If so what are my options? Stick with unsigned int? What about when I need to normalize it, can I cast to float?

--EDIT---

I need the value to be un-normalised in the shader

chrispepper1989
  • 2,100
  • 2
  • 23
  • 48
  • 1
    OpenGL totally has 32bit float textures, GL_R32F for example. Does your target not support them or did you not know about them? – harold Dec 16 '14 at 16:30
  • OpenGL supports double textures (e.g. GL_R32F) for quite a while now. The other possibility would be to use fixed precision numbers and store them in an integer texture. – BDL Dec 16 '14 at 16:30
  • 1
    @RetoKoradi 89,482 WILL result in infinity, because the exponent is 5 bits, therefore its max value is 15 and the result will be infinity from a bit under 2*2^15. – ElderBug Dec 16 '14 at 17:00
  • 1
    You are kind of backwards here. Half-floats are less widely supported than single-precision 32-bit floats. They're mandatory in modern GL, but once upon a time they were only exposed through extensions such as `GL_ARB_half_float_vertex`. As far as textures go, half-precision and single-precision floating-point formats were both introduced at the same time. – Andon M. Coleman Dec 16 '14 at 18:35
  • Make your own type. A 16-bit unsigned `chr_int`. 0-32767, `chr_int` same as `uint16_t`. Above that, map even numbers 32768 to 98302 to/from 32768 to 65535. – chux - Reinstate Monica Dec 16 '14 at 23:29
  • Apologies harold and BDL I forgot to mention I need the value in an unormalised format. Although I am curious if I just sent "89,482" to a normalised format, what would GL normalize it to? – chrispepper1989 Dec 17 '14 at 08:51
  • 1
    And I have just realized I totally missed the point! http://stackoverflow.com/questions/5709023/what-exactly-is-a-floating-point-texture penny drop! – chrispepper1989 Dec 17 '14 at 08:55
  • 1
    @chrispepper1989: That depends on the data type you use. If it's `GL_UNSIGNED_SHORT` that number overflows and becomes **23,947**. Normalizing that to the fixed-point range for `ushort` ([**0**,**65535**]) produces **0.3654**. If it's `GL_UNSIGNED_INT` it is normalized based on the range for `uint` ([**0**,**4294967295**]) and produces **2.083e-5**. But in GL, floating-point texture formats are not normalized, only the fixed-point ([un]signed normalized) formats are (such as `GL_R8` or `GL_R8_SNORM`). – Andon M. Coleman Dec 17 '14 at 14:30
  • 1
    Possible duplicate of [What exactly is a floating point texture?](http://stackoverflow.com/questions/5709023/what-exactly-is-a-floating-point-texture) – Armali Mar 10 '17 at 13:23
  • 1
    @Armali I posted that above :), I am happy to have it marked as duplicate if there is no additional useful info – chrispepper1989 Mar 21 '17 at 15:14

0 Answers0