The hemicube algorithm renders the scene to 5 sides of a half-cube, from the perspective of each polygon.

Assume you place the hemicube around me and render to the 5 sides. The idea is, we can see exactly how much of each other polygon in the scene I see, and so determine the amount of light I receive from those respective polygons.


The way I did this before was using DWORD colors, and assign a different (integer) color to each poly, called its id. This allows for 16M colors using DWORDS. It worked fine with the fixed function pipeline, because I was able to choose D3DDECLTYPE_D3DCOLOR in the vertex declaration, render to texture, and tally up the polygon coverage counts.

Now that I've switched over to shaders, I can't seem to make DWORD colors work anymore. All that works is 3x 32-bit float-type colors (I am using Cg, so float4's.)

Is there a way to force D3D9 or D3D11 to use integer colors in a shader, and if not, how can I guarantee the colors I choose as "ids" for the respective polygons will end up being distinct colors in the texture I render to?

  • 1
    \$\begingroup\$ At the end its just bytes, you can convert and pack any data you want. \$\endgroup\$ Jul 25, 2011 at 20:45
  • 1
    \$\begingroup\$ For instance in an 24 bit rgb value, 8 bit each component, you can store 2^24 numbers, that range should be high enough for the IDs \$\endgroup\$ Jul 25, 2011 at 20:56

1 Answer 1


You can simply take your integer vertex colors and divide by 255.0 them prior to sending them to the shader. I was wary of doing this when I posted the question, because I was afraid that floating point error would cause this to be inaccurate.

But as you can see from Photoshop / point sampling the circle below, the colors smoothly show transitions from 0->255, without skipping a value.

256 colors

Because the end result is you have to export a float4 for color from your pixel shader anyway.

So again the 2 options are:

  • Convert your RGB_DWORD( 0->255,0->255,0->255 ) colors to rgb_float( 0.0->1.0, 0.0->1.0, 0.0->1.0 ) colors prior to sending colors to the shader (recommended, since it eliminates a needless DWORD->float4 conversion in the vertex shader)
  • Use DXGI_FORMAT_R32_UINT in your vertex layout for the color component (DXGI_FORMAT_R8G8B8A8_UINT doesn't work for some reason), send RGB_DWORD( 0->255,0->255,0->255 ) colors, and bitshift/divide by 255.0 in the shader code (arguably less efficient than simply passing rgb_float( 0.0->1.0, 0.0->1.0, 0.0->1.0 ) colors to the shader.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .