the application stage: it’s the client application that performs CPU tasks and invokes the renderer whenever it’s required
the geometry stage: it’s responsible of transforming, modifying or removing/adding geometry to the passed in primitives
the rasterizer stage: triangle scanline, merger and so on and so forth
In theory, materials should branch on the rasterizer stage. Currently, it’s branched on both the geometry stage and rasterizer one, which is wrong, because we have to embed the same geometry part in many of your materials, and that’s annoying.
Solution
Separable shader programs and shader pipelines are the first clues to solve that problem efficiently and elegantly. We then need to introduce new types and concepts to build over the existing material system.
Material shader
A material shader should be a fragment program and should read values from the geometry stage.
Context
A rendering pipeline is a three stages system:
In theory, materials should branch on the rasterizer stage. Currently, it’s branched on both the geometry stage and rasterizer one, which is wrong, because we have to embed the same geometry part in many of your materials, and that’s annoying.
Solution
Separable shader programs and shader pipelines are the first clues to solve that problem efficiently and elegantly. We then need to introduce new types and concepts to build over the existing material system.
Material shader
A material shader should be a fragment program and should read values from the geometry stage.