2D vector graphics using shaders

Started by
12 comments, last by Amadeus 13 years, 5 months ago
Quote:Original post by apatriarca
But, how much translucent overlapping objects do you want to support? Have you verified this is actually a problem?


For things like circles, I'm basically creating a procedural texture in the pixel shader. So just right there all circles will need alpha blending. If I antialias the edges of shapes in the pixel shader, they'll all need alpha blending. So if I do things in the pixel shader like I want to pretty much every quad I draw needs to be

Quote:Have you considered depth peeling techniques?


From what I understand, if this worked, it would just reduce fillrate. Which is a worthy goal, but not really the issue I'm wrestling with right now.

Quote:Original post by mokaschitta
I would suggest you simply render the shapes triangulated.


As I said before, the issue with triangulating everything is that to make things smooth you have to dynamically tesselate shapes as the zoom level changes, or you'll get artifacts (the circle will not look smooth at high zoom levels, as you see the "kink" in its surface). Which is a huge pain to do. And if I want pixel-perfect shapes, you're talking about a lot of triangles.

Quote:
that way you can simply benefit from alot of feature like MSAA etc. and are not limited to simple shapes


Keep in mind that you can stretch the shapes using transforms. So a pixel-perfect circle can be stretched to form any ellipse without changing anything in the pixel shader code (since you're doing the pixel (approximated as an ellipse) to circle collision code in texture coordinate space).

So circle, square, open/closed (that is, whether it's a line or a polygon) linear curve and open/closed bezier curve (or cubic spline curve) should be the only primitives necessary to build up all the other shapes. There's some elbow grease to figure out how to get the curves working properly in the pixel shader, but it seems fairly doable.

Quote:
Another idea would be to approximate the shapes using distancefields. that would have the benefit that you could simply use quads, and even simple textures (holding the distancefield) to define arbitrary shapes. You would also only have one shader to draw the shapes, so you would not have the problem of too many state changes. Alpha blending is still needed, but that should not be a problem.


I don't know what you mean by distancefields specifically, but using textures runs into the problem that at some zoom level things are going to look pixellated, which I'm trying to avoid (that's the whole point of vector graphics, after all). If you procedurally generate the texture in the pixel shader, you're basically back to what I'm doing right now anyway.
[size=2]Darwinbots - [size=2]Artificial life simulation
Advertisement
Rather than using circles, rectangles, etc. as primitives, you could use a single general/generic primitive, for instance beziers: Resolution Independent Curve Rendering using Programmable Graphics Hardware

You could then build circles, rectangles, etc. by combining many of these simpler primitives.
distance field rendering allows you to render vector like graphics from low resolution textures (and also antialiase them) It's the way valve renders the text and some other textures in team fortress 2. they scale exactly like you want, search google and the forums for it, there have been many threads about that topic before.
Quote:Original post by Halifax2
Chapter 25 of GPU Gems 3 might be of interest to you: Rendering Vector Art on the GPU.


Quote:Original post by raigan
Rather than using circles, rectangles, etc. as primitives, you could use a single general/generic primitive, for instance beziers: Resolution Independent Curve Rendering using Programmable Graphics Hardware

You could then build circles, rectangles, etc. by combining many of these simpler primitives.


This is an area i have been attempting to look into as well. Have there been any implementations of these methods. i was attempting to work out the alpha-blending method mentioned for graphics cards that do not support the ddx/ddy gradient instructions. Although not entirely necessary for more recent cards, i would like to better understand the math involved, and would be nice to have support for it in those instances. Any help in that area would be greatly appreciated.

Haven't compared against using distance fields yet though.
----------------------------"Whatever happens, happens..." - Spike"Only the strong survive, if they choose to leave those weaker than themselves behind." - Myself

This topic is closed to new replies.

Advertisement