openvg rasterization

[nobond]

Have a look at the reference implementation of the C code.
Particularly the rasterizer.

I am a more hardware guy. So I am just wondering it just a "reference" and the hw should not be limited to this?

I am asking since the scanline approach is very rare in the mode graphics hw and
Barcentric interpolation looks a more sensible approach.

 

[Simon F]

Have a look at the reference implementation of the C code.
Particularly the rasterizer.

I am a more hardware guy. So I am just wondering it just a "reference" and the hw should not be limited to this?

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

I am asking since the scanline approach is very rare in the mode graphics hw and
Barcentric interpolation looks a more sensible approach.

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

 

[nobond]

Hmm, I am thinking about the triangle only.
The filled shapes with self intersections, surely some sort of software/hardware tesslelatioin to transform them into triangles?

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

 

[Simon F]

Hmm, I am thinking about the triangle only.

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

The filled shapes with self intersections, surely some sort of software/hardware tesslelatioin to transform them into triangles?

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.

 

[jpilon]

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.

 

[nobond]

Hi Simon
I think there is a third approach which is the hybrid of the two you mentioned.
Also HW trianglulation migh not be that expensive considering the die area is so cheap these days

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.

 

[Simon F]

Hi Simon
I think there is a third approach which is the hybrid of the two you mentioned.

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

Also HW trianglulation migh not be that expensive considering the die area is so cheap these days

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.

 

[jpilon]

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.

 

[Simon F]

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

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

...if you went the triangulation route.

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

 

[jpilon]

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

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.

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

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!

 

[nobond]

HI, Simon
Is there a paper or article in the public introducing the details of using stencil buffer to raster a N-sided polygon??

 

[arjan de lumens]

HI, Simon
Is there a paper or article in the public introducing the details of using stencil buffer to raster a N-sided polygon??

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.)

 

[Simon F]

(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.

 

[muratmat]

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.

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

 

[Simon F]

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?

 

[muratmat]

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

 

[bitshiat]

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

 

[arjan de lumens]

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

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.

 

[Simon F]

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

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.

 

[bitshiat]

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.

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...

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.

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