openvg rasterization

It is merely an example implementation. Other methods are fine provided they pass the conformance tests.

Are you proposing to use barycentric coordinates to directly render filled shapes with self intersections, or just to render triangles?

 

I thought that was the case otherwise you could publish a great paper if you could have done the former

You basically have two choices:

• triangulate to non-overlapping triangles, which has a relatively expensive set-up cost, but then renders more quickly or
• Use whatever triangulation takes your fancy and use the stencil buffer to determine which pixels are inside or outside. The downside of approach is that it burns a lot more fill rate.

 

Ideally, vector graphics hardware should be capable of rendering and rasterizing bezier lines.

But assuming we were using 3d hardware which can only rasterize triangles, there would be several issues. The first major issue would be compatibility of both 3d graphics and vector graphics pipelines. They are not the same, and both 3d/VG based specifications have clear details on the how rasterization should occur. This leaves software implementations which are based on the openvg specification with data that is incompatible with 3d rasterization (as pointed out by nobound). Such as geometric data, edge segments vs (convex and concave) polygons tessellated into triangles.

There's several other issues, that i won't list because I'm trying to keep this short. But regardless, I'm not trying to saying it's impossible to have a conformant openvg implementation using 3d hardware, it's just not too efficient.

So to the point, using a scanline approach could very well be more effective then the overheard required for a proper tessellation into triangles.

 

Pray tell. (Of course, detecting convex and some other simple polygon types which have trivial non-overlapping triangulation algorithms, is certainly possible).

Just to give you an idea, the MBX OpenVG driver contains code to robustly triangulate completely arbitrary polygons to non-overlapping triangles. That represents ~25k lines of code (albeit with a lot of comments). IMHO, that's not really something that even the most high-end GPU is quite ready for as yet.

 

I'd be curious know how you handle the various quality/anti-aliasing options present in the openvg specification if you went the triangulation route.

 

OpenVG is deliberately specified so as not to tie you down to any particular AA method.

Are you hinting at Scaleform's technique? If so, we haven't tried implementing that.

 

True, but I'm thinking it might be a little difficult to apply any kind of AA algorithm to polygons which have been tessellated other than perhaps using an FSAA approach.

I'm not hinting to scaleform's approach in particular, more so to the 3d pipeline approach, regardless of whether it sits on top of opengl/directx or directly accesses the graphics driver.

Speaking of scaleform, I wish there was more details on the VGx stuff floating around!

 

Check out http://www.glprogramming.com/red/chapter14.html#name13 for a quick and simple description of how the method works.

(It covers only the odd-even fill-rule, though; nonzero fill-rule is somewhat trickier.)

 

Two sided stencils will do the non-zero rule for you fairly simply.

 

Robust triangulation of completely arbitrary polygons can be achieved with a lot less code, our triangulator is less than 4k lines (comments included).
http://www.amanithvg.com/pub_files/triangulator.zip

 

Thanks. Mind if I pinch some of the test data? FWIW I think by "25K including comments" I meant a lot of comments as your windows executable is of similar size to my Linux one.

Presumably this tessellator is a new one as another company (who shall rename nameless) said that the first versions of Amanithvg weren't very robust.

Any idea when it will be an officially conformant OpenVG solution?

 

Feel free to get all included test data, we have generated most of it using RPG ( http://www.cosy.sbg.ac.at/~held/projects/rpg/rpg.html ).
We have fully rewritten (and not licensed from a nameless company) the previous AmanithVG triangulator, just because it was not very robust

 

I wonder why people preffer the tesselation method over the stencil method outlined by the opengl redbook?

I've used the GLU tesselator too, but only because when I started back then all references on GPU vector rendering talked about tesselating concave polys...
But tesselation requires triangulization on the CPU, which seems much more inefficient than the stencil (GPU) approach to me? Next to the opengl redbook mentioning the stencil approach, this guy claims the stencil approach is much better performing:
http://zrusin.blogspot.com/2006/07/hardware-accelerated-polygon-rendering.html

PS: Another very interesting shader-only method is shown here: http://www.mdk.org.pl/2007/10/27/curvy-blues

 

Mainly because it has some rather pathological worst-case behaviors where certain polygon shapes (such as combs and spirals) can force enormous amounts of overdraw.

 

Also, if you are going to be drawing the same object over many frames, the triangulation cost can become relatively tiny.

A further reason is that not all devices have stencil buffer support or may only support, say, 4 bit stencils which is insufficient for general OpenVG use.

 

Couldn't that easily be circumvented by rendering the shape to a texture until the shape changes? Much like caching different LOD versions of tesselated shapes...

True, but if this stencilbased method is faster I would like to keep the tesselation as a fallback solution for cards that dont support it. Has anyone done benchmarks on how they compare (is tesselation really shown to be faster in the general case?) The benchmark on Zack Russin's blog seems to tell otherwise: http://zrusin.blogspot.com/2006/07/hardware-accelerated-polygon-rendering.html