On Tue, 2008-10-21 at 18:41 -0400, Tom Cooksey wrote: > On 10/21/08, Neil Roberts <[EMAIL PROTECTED]> wrote: > > Another thing I've been thinking about for the paths is to tessellate > > them into triangles so that we avoid using the stencil buffer > > altogether. In that case we would probably need to calculate the texture > > coordinates again, but it might help with your other idea which was to > > get a handle to a stored path. We could combine this with the Mesh API > > idea from Rob Bragg [2] and store the tessellated path as a mesh. The > > tessellation idea is described in bug #1198. > > If you do this, look into caching the results of the tesselation as it > can be quite expensive - especially for complex paths. Also, if you > cache the tesselation, be careful if the path contains curves. If the > path gets scaled up your curves aren't curvy any more and you need to > re-tesselate. The mesh API is essentially going to be a fairly raw abstraction over buffer objects which we can use to cache the tesselation. (Though apparently the GLU tesselation path is already faster than using the stencil buffer tricks, which is cool :-) )
Since we will be caching the results, one way of dealing with the non curvy edges issue initially might be to just wack the detail level of the tesselation right up, store that, and then I think we should be able to sample lower resolution geometry out from the same buffer quite cheaply. Perhaps another way would be to walk around the boundary vertices and determine a variable LOD based on how curved the boundary is at any point, then find a way to feed that data into the tessellating. If anyone has any other tricks/experience with this problem that'd be cool to hear about though! kind regards, - Robert -- Robert Bragg, Intel Open Source Technology Center -- To unsubscribe send a mail to [EMAIL PROTECTED]
