jdryg
commented
6 years ago Rejected as too complicated.
Color is just a uint32_t so there will be no benefit on converting it to an index, since we should also change this index per instance. Since cached mesh instances are already copied to the vertex buffer on every submit, we could just alter the color at that point.
Non-AA meshes (w/o alpha fringes) are easy. We already memset32 the color from the command list to all mesh vertices. Reading that color from a parameter buffer and passing it to submitCachedMesh() should work.
For AA'd meshes, the change is a bit more complicated, but it might work. Instead of memcpy'ing the data from the cached mesh directly we could change the RGB channels and leave the A channel intact while copying.
Issues
- Only the RGB part of the color will be affected. Whatever alpha value was used in the initial mesh color will still be applied to all instances. For opaque meshes this is fine (alpha other than 1.0 appears only on AA fringes). Transparent meshes will have the problem.
Reason
Being able to draw the same cached command list with different colors per-instance. E.g. in an editor you can change the color of the selected shape without needing a separate command list with the same shape but with different colors.
Idea
Instead of baking the actual color per vertex, use the RGB channels of the vertex color as an index into a color texture (alpha should still be calculated for AA fringes). In the vertex shader, decode the RGB part of the color into UV coordinates and in the fragment shader sample the color texture using these UV coords.
Pros
Cons
Extras
clStrokePath(..., Color col)also haveclStrokePath(..., ParamID param)where the ParamID will point to a parameter buffer which will be passed tosubmitCommandList().