This PR adds support for triangle rasterization through vertex and fragment shaders. An example is provided to demonstrate how this API works.
One concern I’m thinking about here is API bloat. Rasterization is a complicated process. So to keep the API bloat to a minimum, we recycle the current API surrounding configuring the shader binding table.
Just like with closest hit, any hit and intersection programs, vertex and pixel programs are assigned to a geometry type, and instances of that geometry type are made. Then, vertex and fragment programs receive the same “record” of data that a closest hit program for the same geometry would receive. To upload parameters to the GPU, we reuse the existing buildShaderBindingTable call.
We do currently require a couple additional steps to rasterize geometry. First, a color and depth texture must be assigned to the geometry type. Then, users must call gprtGeomTypeRasterize.
This PR adds support for triangle rasterization through vertex and fragment shaders. An example is provided to demonstrate how this API works.
One concern I’m thinking about here is API bloat. Rasterization is a complicated process. So to keep the API bloat to a minimum, we recycle the current API surrounding configuring the shader binding table.
Just like with closest hit, any hit and intersection programs, vertex and pixel programs are assigned to a geometry type, and instances of that geometry type are made. Then, vertex and fragment programs receive the same “record” of data that a closest hit program for the same geometry would receive. To upload parameters to the GPU, we reuse the existing buildShaderBindingTable call.
We do currently require a couple additional steps to rasterize geometry. First, a color and depth texture must be assigned to the geometry type. Then, users must call gprtGeomTypeRasterize.