Wednesday, April 29, 2009

Defining splitting of primitives

Adding a primitive to every bucket it touches turned out to be a bad choice. Quite an explosion of splits !
In fact, splitting with buckets in mind in general doesn't seem such a good idea now.

There are two reasons to split a primitive:

1) Simplification. The primitive is too complex to bother implementing dicing for it (obvious example: concave polygons)

2) Reducing screen area. When dicing would require too many vertices compared to a chosen work-space limit.

..first of all, I think it would be easier to make this distinction clear in the pipeline. REYES abstracts with a generic "split" function, but I may be introducing an explicit "simplification" phase for those primitived that don't have a dice method.
The simplification would only happen once at most. So, the original complex primitives can be forgotten early on (though may be work keeping them around for debugging purposes).

Then one can proceed with splitting all those primitives that could be diced if it weren't for an unpractical amount of vertices that the dicing would generate in one single dice operation.