   Motion blur using fixed-point velocities
  This seems like it should be fundamentally a simple problem, but I'm afraid it's got me stumped.I'm trying to store velocities in a fixed-point texture. The velocities range from -1 to 1, so before writing to the (unsigned) texture I rescale them to [0,1]. This results in an original velocity of 0 being rescaled to 0.5. However, 0.5 can't be represented precisely in fixed-point with an odd number of bits, so the value stored in the texture is actually slightly less than 0.5. This means that when I read the value and scale it back to [-1,1], the result is around -0.00392 (using 8-bit precision) rather than 0.I'm using this "velocity buffer" to perform full-screen motion blur, and this problem means that anything stationary (velocity 0) ends up being slightly blurred. Of course this error can be reduced by using more bits per channel, but even with 32 it's noticeable. I'd like to avoid using a floating-point buffer, and besides, I've seen a few resources that specifically recommend using fixed point velocities for motion blur. So how is this problem avoided?   
  use the range from 0 to 254 instead of 0 to 255.or 0 to 1.f-1.f/255f -> 0.f to 0.9960785f beside that, be carefull with rounding, 0 to 0.9999f/255f is represented in 8bit by 0, but just 1.f is represented by 255, maybe you just need to clamp to 0.999999f and truncation will do all the magic.scaling back is x*2.f-0.9960785f;  What is the exact fixed point type? Obviously you don't have a sign bit, or you hacked something together yourself, which you store in an unsigned int; but how many bits have for the integer part, and how many for the fractional part? Probably my question is too simple, but can't you just use an even number of bits for the fractional part?edit: I guess using a magic bit-pattern to represent 0/0.5 doesn't help in your case?   ;  Thanks for the replies!Krypt0n: so multiply all output from the shader by 254/255? That still doesn't work - 0.5*254/255 can't be represented exactly by the 32-bit floating point format which is output by a fragment shader. So it instead outputs a slightly lower value, which is rounded to 126 rather than 127 when converted to 8-bit.phresnel: The texture is R8G8 (two channels because I need velocities along two axes). I don't use a custom format with separate integer and fractional parts or anything - just a straightforward 8-bit integer per channel.As for using a special bit pattern to represent 0 - yes, I suppose I could do something like that, but it seems such a terrible hack and would require extra conditionals in the shader. Surely there's a simpler way? There are threads here that just cavalierly say "yeah, use a fixed point format for the velocity buffer", as if that's all there is to it.Has anyone implemented motion blur using a fixed-point velocity texture? Did the "stationary" case cause problems? Am I missing something obvious?   ;Quote:Krypt0n: so multiply all output from the shader by 254/255?I did multiply by slightly more than that;)and, you could even multiply by 0.999999, cause it will be truncated, like I said, 0 covers an range from 0.f to 0.9999999999f/255.f like all of 254 ints do, but 255 is just mapped to 1.f, that's because of truncation. (without clamping it's mapping from 1.f to 1.f+0.9999999f/255.f)so you can multiply by 0.99999999f, the exact 254.f/255.f value is just needed for back conversion from int to your -1.f to 1.f range.;  multiply by step(0.01, abs(value) )thus introducing a "dead zone"   ;  Krypt0n - I think I see what you mean now. I'll try it when I get home.AndyFirth - Would that cause a noticeable "jump" when a fragment moves just enough to leave the "dead zone" and suddenly starts being blurred? If not, it might be preferable to Krypt0n's approach, since it would only affect velocities close very to 0. I'll try it too.   ;  it won't jump at all provided the theta you use in place of 0.01 is the lowest amount of blur you allow in your system.   