> On Fri, Aug 27, 2010 at 10:18 AM, Chris Marrin <cmarrin@...> wrote:
>> Hi Ken,
>> It would help me, and I think many others, if we could have a discussion of
>> how exactly your tessellation logic works and what it is intended to do. For
>> instance, is the algorithm you're using based on Loop-Blinn? I'm a bit
>> familiar with that algorithm and some of the problems it has with rendering
>> this type of geometry. For instance, there are typically anti-aliasing
>> artifacts at the points where the interior triangles touch the edges. These
>> are described in section 5.1 of the paper and the authors added additional
>> (and not well described) logic to solve the problem.
>> If you could describe your algorithm a bit and show some expected results
>> with typical cases, that would be really helpful.
>> For those not familiar with Loop-Blinn, here is a link to their original
>> paper, presented at Siggraph 2005:
>> Resolution Independent Curve Rendering using Programmable Graphics ...
>> It's a great algorithm for rendering resolution independent 2D objects using
>> the GPU. It has potential to render both 2D shapes (as used in Canvas and
>> SVG) and text glyphs. It's advantage is that once you generate the triangles
>> for the shape, you can render the shape at any resolution. It's disadvantage
>> is that the triangle generation is quite expensive, so mutating shapes can
>> potentially be slower than a simpler resolution dependent tessellation.
> I think there's a variant of the algorithm that uses the stencil
> buffer polygon rendering method (
> http://zrusin.blogspot.com/2006/07/hardware-accelerated-polygon-rendering.html > ) instead of triangulation. The paper I think I read on that only
> covered quadratic splines, but maybe somehow has extended that method
> to cubic splines by now?
It looks like that technique deals with polygons, so as long as you convert the shape to a piecewise linear curve it seems like it can handle any curve form, right?