Well, Floating Points are a Binary Number System used to represent decimal points... there are a number of different precision versions. There's a "Half" it's a 16 bit floating point that has up to ~3 decimal points, a "Float" has about ~7 decimal points, and used 32 bits, and there's a "Double" it's 64 bits and has ~16 decimal points. There are larger ones, but, they're not really used, often.
My bet is that this render engine uses float variables to represent colors, instead of 8 bit unsigned integers. Another possibility is that the depth buffer uses floats for better depth decisions. Perhaps it would help if you tell us more about this render engine. Is
it a hardware render engine (GPU) or a software render engine?
Disclaimer: While I'm a programmer, I haven't written a "proper" render engine. Some of what I say is from my own experience, and therefore may be less than 100% true. With that said...
First off, one thing that we should be clear on with half/float/doubles are approximations of decimal numbers. Computers don't really have an understanding of decimal numbers. The two ways that I know of to approximate decimal numbers are through floats, and using really large integer numbers and treating the lower digits as decimal numbers (for example, if you want to represent 1.0 and you have an accuracy of 3 decimal places, then the number is really 1000). One thing to note with the float family (half, float, double, etc) is that there are certain numbers that it cannot represent. The larger the number becomes, the decimals become less and less accurate (for example, numbers 0 - 1 may have a resolution of 0.0001, while numbers between 1000-1001 may have a resolution of 0.01). There's also a limit to the size of the number before it just returns the highest number it can produce.
Also, a quick thing on half/float/double. Half values are special in that not everything supports it. As far as I know, the C/C++ standard doesn't have the concept of a half number, so some libraries had to build support for it (off the top of my head are OpenEXR, OpenImageIO, and I think OpenGL and DirectX have support for it). Halfs are 16 bits in size (the size of a 16 bit image in Photoshop, or 65,536 unique values per channel), floats are 32 bits, and doubles are 64 bits. The larger the bits, the more decimal places are supported, and the max value increases. So, we should use doubles all the time, right? Eh... not really.
Let's do some math (yay!) I'm going to make the follow assumptions about the image buffer (will get to the definition in a bit): width = 1920 height = 1080 channels = 3 (red, green, blue) <- Some engines may pad the channels to 4 because it fits in the memory better... but that's another story that I won't get into.
Case 1: bit depth = 8 (standard 0 - 255 image) result = width * height * channels * bit depth or 1920 * 1080 * 3 * 8 or 49,766,400 bits or 6,220,800 bytes or about 6.2 megabytes of memory.
Case 2: bit depth = 16 (0 - 65,535 image, or half) result = 99,532,800 bits or 12.4 megabytes of memory
Case 3: bit depth = 32 (float) result = 199,065,600 bits or 24.9 megabytes of memory
Case 3: bit depth = 64 (double) result = 398,131,200 bits or 49.8 megabytes of memory
As you can see, doubles take up a lot of video memory. If you have any sort of 3d scene that has a large amount of verticies, textures, normal maps, spec maps, etc... that'll eat up a huge chunk of your video memory (or all of it if you're on a lower end machine).
Quickly going back to the image buffer, this is what gets rendered to. Usually the GPU stores the image buffer in memory, renders all of the polygons and their lovely textures and shaders to each pixel in the buffer, and then displays the buffer (so, there's actually two buffers).
Anyways, now that the technical stuff is out of the way, why use a float image over something like an 8 bit image? Two main reasons. 1. Floats (even halfs) support more possible values than an 8 bit image. 2. Floats support images that are whiter than white, and blacker than black.
Let me explain the second part a bit by pretending that you have a piece of paper, and looking at the sun at the same time (note: don't do this in real life.) If you took a picture on your camera and sampled the paper and sun in Photoshop, you'll see that the piece of paper will have an rgb value very close to 255 255 255, and the sun's value will be 255 255 255. In real life, the values are completely different. The sun is waaaaay brighter than a piece of paper. If we convert 0 - 255 to 0.0 - 1.0, then those values may look something like 1.0 1.0 1.0 for the paper, and 10000.0 10000.0 10000.0 for the sun. An 8 bit image can't support values like that, since it will clamp the brightest value to 255 255 255 (or 1.0 1.0 1.0).
Anyways, I hope this makes sense. If you're still not clear, feel free to let me know and I'll try to explain better. Also, if there's any other programmers looking at this thread, let me know if I missed something.
Replies
There are larger ones, but, they're not really used, often.
Another possibility is that the depth buffer uses floats for better depth decisions.
Perhaps it would help if you tell us more about this render engine. Is it a hardware render engine (GPU) or a software render engine?
First off, one thing that we should be clear on with half/float/doubles are approximations of decimal numbers. Computers don't really have an understanding of decimal numbers. The two ways that I know of to approximate decimal numbers are through floats, and using really large integer numbers and treating the lower digits as decimal numbers (for example, if you want to represent 1.0 and you have an accuracy of 3 decimal places, then the number is really 1000). One thing to note with the float family (half, float, double, etc) is that there are certain numbers that it cannot represent. The larger the number becomes, the decimals become less and less accurate (for example, numbers 0 - 1 may have a resolution of 0.0001, while numbers between 1000-1001 may have a resolution of 0.01). There's also a limit to the size of the number before it just returns the highest number it can produce.
Also, a quick thing on half/float/double. Half values are special in that not everything supports it. As far as I know, the C/C++ standard doesn't have the concept of a half number, so some libraries had to build support for it (off the top of my head are OpenEXR, OpenImageIO, and I think OpenGL and DirectX have support for it). Halfs are 16 bits in size (the size of a 16 bit image in Photoshop, or 65,536 unique values per channel), floats are 32 bits, and doubles are 64 bits. The larger the bits, the more decimal places are supported, and the max value increases. So, we should use doubles all the time, right? Eh... not really.
Let's do some math (yay!)
I'm going to make the follow assumptions about the image buffer (will get to the definition in a bit):
width = 1920
height = 1080
channels = 3 (red, green, blue) <- Some engines may pad the channels to 4 because it fits in the memory better... but that's another story that I won't get into.
Case 1:
bit depth = 8 (standard 0 - 255 image)
result = width * height * channels * bit depth or 1920 * 1080 * 3 * 8 or 49,766,400 bits or 6,220,800 bytes or about 6.2 megabytes of memory.
Case 2:
bit depth = 16 (0 - 65,535 image, or half)
result = 99,532,800 bits or 12.4 megabytes of memory
Case 3:
bit depth = 32 (float)
result = 199,065,600 bits or 24.9 megabytes of memory
Case 3:
bit depth = 64 (double)
result = 398,131,200 bits or 49.8 megabytes of memory
As you can see, doubles take up a lot of video memory. If you have any sort of 3d scene that has a large amount of verticies, textures, normal maps, spec maps, etc... that'll eat up a huge chunk of your video memory (or all of it if you're on a lower end machine).
Quickly going back to the image buffer, this is what gets rendered to. Usually the GPU stores the image buffer in memory, renders all of the polygons and their lovely textures and shaders to each pixel in the buffer, and then displays the buffer (so, there's actually two buffers).
Anyways, now that the technical stuff is out of the way, why use a float image over something like an 8 bit image? Two main reasons.
1. Floats (even halfs) support more possible values than an 8 bit image.
2. Floats support images that are whiter than white, and blacker than black.
Let me explain the second part a bit by pretending that you have a piece of paper, and looking at the sun at the same time (note: don't do this in real life.) If you took a picture on your camera and sampled the paper and sun in Photoshop, you'll see that the piece of paper will have an rgb value very close to 255 255 255, and the sun's value will be 255 255 255. In real life, the values are completely different. The sun is waaaaay brighter than a piece of paper. If we convert 0 - 255 to 0.0 - 1.0, then those values may look something like 1.0 1.0 1.0 for the paper, and 10000.0 10000.0 10000.0 for the sun. An 8 bit image can't support values like that, since it will clamp the brightest value to 255 255 255 (or 1.0 1.0 1.0).
What does this mean? This means that we can have more accurate reflections (example: https://upload.wikimedia.org/wikipedia/en/8/89/Lost_Coast_HDR_comparison.png), and more information to do compositing on (for example, bloom, motion blur, etc). Also, you can push your values to extremely light or dark without having banding artifacts (example https://en.wikipedia.org/wiki/Colour_banding#/media/File:Colour_banding_example01.png). A good example of floating point images (known as HDR or High Dynamics Range images) vs regular 8 bit images (known as LDR or Low Dynamic Range images) is on this page: http://www.hdrshop.com/
Anyways, I hope this makes sense. If you're still not clear, feel free to let me know and I'll try to explain better. Also, if there's any other programmers looking at this thread, let me know if I missed something.