4 ms·

Assigning each polygon its own color to identify the bad one via color picker is brilliant. I'd love to see more posts like these here.

vernie 8y ago
This is commonly used for compositing and debugging in animation, where it's called an object ID pass. It also tends to look pretty fun.
corysama 8y ago
It’s also an effective way to do object selection under a mouse click. Assign each object a unique color and draw them to an off-screen buffer with a 1x1 viewport. Read back the viewport to the CPU. It’s great because since it reuses the same code, data and hardware that draws the visible screen, you know that it is pixel-accurate and reasonably fast. Long ago I used this in a protein visualization where you could select individual atoms (with 100s of thousands on the screen). I definitely would not want to promise a ray-sphere test that guarantees pixel-perfect consistency with the render forever.
- OskarS 8y ago
  Clever, but it sounds expensive! Re-rendering the entire scene (especially with that many objects) instead of a single raycast? I'm guessing you had no acceleration structure for any kind of raycasts, and if this was the only thing you needed raycasts for, it wasn't worth making one?
  - vvanders 8y ago
    That's assuming you have raycasting rendering(most game engines don't) and/or hoping that the way you draw your ray cast scene matches up pixel perfect with the GPU(it won't). Generally rendering Geo + Fill is cheap, it's the complex shaders and post that tend to drag down your GPU. Heck, if you're doing GPU occlusion culling you're basically doing the same idea but for rendering whole objects. You can also do this every 1/10 frames or so to keep overhead low. UE3 and a bunch of game editors use this technique pretty extensively.
    - AHTERIX5000 8y ago
      Most game engines do have acceleration structure that can be used for raycasts such as one provided by physics system though. Of course it is not 1:1 compared to rendering but coarse bboxes are in many cases more useful than really accurate methods. And you can avoid syncing.
  - haldean 8y ago
    Many game render pipelines will draw the scene a dozen times; here's an article about the pipeline from GTA V, for example: http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphics-study/ http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphic... Adding one more draw call for mouse interaction, especially one that requires no shading at all, is a pretty minimal additional cost.
  - corysama 8y ago
    It's "a lot of work" for the machine, but very little work for the programmer. It is assumed that rendering the scene is already fast enough to be happily interactive for the UI. Mouse picking is a human timeline interaction. And, it's likely that the scene is static during the pick (do you want to pick a tiny, moving atom?). So, if the pick is as fast or faster than a single frame of spinning the model, it should be unnoticeably fast for the user.
  - tokyodude 8y ago
    you only need to draw one pixel, the one under the mouse. cull to only objects under that pixel, set your frustum, viewport, and scissor for that one pixel and I'm guessing drawing is faster than walking triangles in the gpu
- Jasper_ 8y ago
  Yeah, this is the classic trick known as "picking": https://www.opengl.org/archives/resources/faq/technical/selection.htm https://www.opengl.org/archives/resources/faq/technical/sele... It's what developers went to after the even more classic GL_SELECT render mode was removed. It's not suitable to happen every frame because the CPU stall waiting on the frame to render is unacceptable. Most engines will do a CPU raycast into the scene. I don't know why that you say it wouldn't be pixel-perfect, because it should be. The math will work out.
  - vvanders 8y ago
    > The math will work out. When you're dealing with GPUs you're never dealing with just the math. Various vendors make shortcuts in the name of performance so there's a good chance your raycast code doesn't match 100%. Seen this a lot with "golden image" tests, one vendor's rendered scene has bunch of inconsistencies with another vendor's(or different driver version) causing sporadic test failures.
    - corysama 8y ago
      Bonus: In my case the atoms used sprite-imposters to fake drawing a zillion tiny spheres.
    - Jasper_ 8y ago
      Usually those tricks show up during texturing or because of float/half imprecision in the pixel shaders. Rasterization of should be the same across all hardware, mandated by the D3D spec, and a very well-tested thing in the D3D compliance suite [0]. If not, you would see various seams in applications. [0] https://docs.microsoft.com/en-us/windows-hardware/drivers/display/point--line--and-triangle-filling-requirements https://docs.microsoft.com/en-us/windows-hardware/drivers/di...
OskarS 8y ago
Yeah, it's very clever, but it only works if the surface is unshaded.
- TeMPOraL 8y ago
  You disable shading for such rendering.

vernie 8y ago

This is commonly used for compositing and debugging in animation, where it's called an object ID pass. It also tends to look pretty fun.

corysama 8y ago

It’s also an effective way to do object selection under a mouse click. Assign each object a unique color and draw them to an off-screen buffer with a 1x1 viewport. Read back the viewport to the CPU. It’s great because since it reuses the same code, data and hardware that draws the visible screen, you know that it is pixel-accurate and reasonably fast. Long ago I used this in a protein visualization where you could select individual atoms (with 100s of thousands on the screen). I definitely would not want to promise a ray-sphere test that guarantees pixel-perfect consistency with the render forever.

OskarS 8y ago
Clever, but it sounds expensive! Re-rendering the entire scene (especially with that many objects) instead of a single raycast? I'm guessing you had no acceleration structure for any kind of raycasts, and if this was the only thing you needed raycasts for, it wasn't worth making one?
- vvanders 8y ago
  That's assuming you have raycasting rendering(most game engines don't) and/or hoping that the way you draw your ray cast scene matches up pixel perfect with the GPU(it won't). Generally rendering Geo + Fill is cheap, it's the complex shaders and post that tend to drag down your GPU. Heck, if you're doing GPU occlusion culling you're basically doing the same idea but for rendering whole objects. You can also do this every 1/10 frames or so to keep overhead low. UE3 and a bunch of game editors use this technique pretty extensively.
  - AHTERIX5000 8y ago
    Most game engines do have acceleration structure that can be used for raycasts such as one provided by physics system though. Of course it is not 1:1 compared to rendering but coarse bboxes are in many cases more useful than really accurate methods. And you can avoid syncing.
- haldean 8y ago
  Many game render pipelines will draw the scene a dozen times; here's an article about the pipeline from GTA V, for example: http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphics-study/ http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphic... Adding one more draw call for mouse interaction, especially one that requires no shading at all, is a pretty minimal additional cost.
- corysama 8y ago
  It's "a lot of work" for the machine, but very little work for the programmer. It is assumed that rendering the scene is already fast enough to be happily interactive for the UI. Mouse picking is a human timeline interaction. And, it's likely that the scene is static during the pick (do you want to pick a tiny, moving atom?). So, if the pick is as fast or faster than a single frame of spinning the model, it should be unnoticeably fast for the user.
- tokyodude 8y ago
  you only need to draw one pixel, the one under the mouse. cull to only objects under that pixel, set your frustum, viewport, and scissor for that one pixel and I'm guessing drawing is faster than walking triangles in the gpu
Jasper_ 8y ago
Yeah, this is the classic trick known as "picking": https://www.opengl.org/archives/resources/faq/technical/selection.htm https://www.opengl.org/archives/resources/faq/technical/sele... It's what developers went to after the even more classic GL_SELECT render mode was removed. It's not suitable to happen every frame because the CPU stall waiting on the frame to render is unacceptable. Most engines will do a CPU raycast into the scene. I don't know why that you say it wouldn't be pixel-perfect, because it should be. The math will work out.
- vvanders 8y ago
  > The math will work out. When you're dealing with GPUs you're never dealing with just the math. Various vendors make shortcuts in the name of performance so there's a good chance your raycast code doesn't match 100%. Seen this a lot with "golden image" tests, one vendor's rendered scene has bunch of inconsistencies with another vendor's(or different driver version) causing sporadic test failures.
  - corysama 8y ago
    Bonus: In my case the atoms used sprite-imposters to fake drawing a zillion tiny spheres.
  - Jasper_ 8y ago
    Usually those tricks show up during texturing or because of float/half imprecision in the pixel shaders. Rasterization of should be the same across all hardware, mandated by the D3D spec, and a very well-tested thing in the D3D compliance suite [0]. If not, you would see various seams in applications. [0] https://docs.microsoft.com/en-us/windows-hardware/drivers/display/point--line--and-triangle-filling-requirements https://docs.microsoft.com/en-us/windows-hardware/drivers/di...

OskarS 8y ago

Yeah, it's very clever, but it only works if the surface is unshaded.

TeMPOraL 8y ago
You disable shading for such rendering.