title: OpenGL texture coordinates and the precision of small floats
body: <p>I'm using floats to specify texture coordinates, in the range 0-1. OpenGL likes things in this range, and I'm fine specifying coordinates this way, but I'm concerned when I start using larger textures (say up 4096 or 8192 pixels), that I may start losing precision. For example, if I want to specify a coordinate of (1,1) in a 8192x8192px texture, that would map to <code>1/8192=0.0001220703125</code>. That seems to evaluate to <code>0.000122070313</code> as a float though... I'm concerned that my OpenGL shader won't map that to the same pixel I intended.</p>
  
  <p>I could keep the coordinates as integers in pixels for awhile, but sooner or later I have to convert it (perhaps as late as in the shader itself). Is there a workaround for this, or is this something I should even be concerned about?</p>
  
  <hr>
  
  <p>Multiplying it back out, I get <code>1.000000004096</code> which I guess would still be interpreted as <code>1</code>? Actually, OpenGL does blending if its not a whole number, doesn't it? Perhaps not with "nearest neighbour", but with "linear" it ought to.</p>
  
  <pre><code>1/4096f * 4096 =   1, error = 0
  1/8192f * 8192 =   1.000000004096, error =  0.000000004096
  1/16384f * 16384 = 1.0000000008192, error = 0.0000000008192
  1/32768f * 32768 = 0.9999999991808, error = 0.0000000008192
  ...
  1/1048576f * 1048576 = 0.9999999827968, error = 0.0000000172032
  </code></pre>
  
  <p>(I'm using Visual Studio's debugger to compute the float, and then multiplying it back out with Calculator)</p>
  
  <p>Is the lesson here that the error is negligible for any reasonably sized texture?</p>