Stanford CS248: Implement an SVG Rasterizer • Hacker News Board

Re: Stanford CS248: Implement an SVG Rasterizer

#71

Post by fulafel » Sat, Mar 21, 2020, 11:37 AM UTC

Jasper_ wrote: post #30

manfredo wrote: post #27

Earlier quoted context omitted.

What do you mean GPUs don't support them? Most opengl tutorials I've read have people building triangles in 2d to learn fragment shaders and vertices before going 3d. Most of them also support parametric curves, so even hardware accelerated bezier curves should be possible.

Wait, why do you say GPUs support parametric curves? GPUs are based on triangles mostly.

See eg https://github.com/mattdesl/parametric-curves/ and https://developer.nvidia.com/gpugems/gpugems3/part-iv-image-...

You can builds all kinds on top of pixels and triangles.

Re: Stanford CS248: Implement an SVG Rasterizer

#72

Post by fulafel » Sat, Mar 21, 2020, 11:56 AM UTC

Jasper_ wrote: post #42

manfredo wrote: post #39

Earlier quoted context omitted.

GPUs can take in way more than just triangles as input. There are particle simulation and even Ray tracing implemented on GPUs nowadays. Support for parametric curves was one of the more recent additions.

That's a very... naive view of how a GPU works. Particle simulation is done in compute, and ray tracing, as implemented in RTX/DXR, is done on a soup of triangles. The core of rasterization is still done on triangles, and can't easily be done in compute. Have any references to parametric curves on GPUs? All the approaches I know of, like the recent mesh shader work, still output triangle meshes.

"In compute" just means that there aren't inputs and outputs related to the current output frame in the calculation job - the computational possibilities are the same.

Triangles aren't necessarily involved in in rendering either, see eg how the stuff on shadertoy.com works.

Re: Stanford CS248: Implement an SVG Rasterizer

#73

Post by chrisseaton » Sat, Mar 21, 2020, 12:04 PM UTC

dublin wrote: post #22

rayshan wrote: post #13

What's a good JavaScript-based solution to render SVG into an image? html2canvas doesn't work well with SVG, especially those heavily styled with CSS.

Kinda defeats the whole purpose of SVG. Only photos should be bitmaps. Graphics should be vectors. This is the 21st century, folks...

Do you have a vector display of some kind?

No?

So someone somewhere is going to need to rasterise your vectors if you want to see them on a screen, aren't they?

Re: Stanford CS248: Implement an SVG Rasterizer

#74

Post by rpasquay » Sat, Mar 21, 2020, 12:04 PM UTC

Is there any good book/resource about how all that fancy stuff you can use in Inkscape/Illustrator is actually implemented in terms of rendering. E.g. how are curves and lines with a thickness rendered or shapes that are defined by boolean operations etc. ?

Re: Stanford CS248: Implement an SVG Rasterizer

#75

Post by tinus_hn » Sat, Mar 21, 2020, 12:57 PM UTC

An interesting challenge, are the accompanying lectures also available?

Re: Stanford CS248: Implement an SVG Rasterizer

#76

Post by manfredo » Sat, Mar 21, 2020, 7:02 PM UTC

Jasper_ wrote: post #42

manfredo wrote: post #39

Earlier quoted context omitted.

GPUs can take in way more than just triangles as input. There are particle simulation and even Ray tracing implemented on GPUs nowadays. Support for parametric curves was one of the more recent additions.

That's a very... naive view of how a GPU works. Particle simulation is done in compute, and ray tracing, as implemented in RTX/DXR, is done on a soup of triangles. The core of rasterization is still done on triangles, and can't easily be done in compute. Have any references to parametric curves on GPUs? All the approaches I know of, like the recent mesh shader work, still output triangle meshes.

This is from 2007: https://developer.nvidia.com/gpugems/gpugems3/part-iv-image-...

Again, the vast majority of use cases for GPUs is 3d vertex graphics. But they're capable of more than that. Modern GPUs are very different from early GPUs that only worked with triangles. Some of the early ones were actually ASICs, and couldn't even load different shader programs.

Re: Stanford CS248: Implement an SVG Rasterizer

#77

Post by mfabbri77 » Sat, Mar 21, 2020, 7:14 PM UTC

zerr wrote: post #70

mfabbri77 wrote: post #9

I've already implemented an SVG renderer at https://www.amanithsvg.com based on our openvg engine with software rasterization https://www.amanithvg.com Both are closed source, but there are evaluation version available, if someone is interested in compare rendering quality and speed.

Why did you name a closed source product openX? :)

The name is AmanithVG and it is an implementation of OpenVG (a standard API for 2D vector graphics from Khronos group).

Re: Stanford CS248: Implement an SVG Rasterizer

#78

Post by manfredo » Sat, Mar 21, 2020, 8:33 PM UTC

z3phyr wrote: post #57

manfredo wrote: post #27

Earlier quoted context omitted.

What do you mean GPUs don't support them? Most opengl tutorials I've read have people building triangles in 2d to learn fragment shaders and vertices before going 3d. Most of them also support parametric curves, so even hardware accelerated bezier curves should be possible.

The first triangle is still in 3d space but the z coordinates are set to 0

Or you can just not define a z coordinate in the vertex buffer object (at least, in opengl). I think the vertex shader might still need to output a 3rd coordinate. But you can always just discard it.

Re: Stanford CS248: Implement an SVG Rasterizer

#79

Post by Jasper_ » Sat, Mar 21, 2020, 9:00 PM UTC

fulafel wrote: post #71

Jasper_ wrote: post #30

Earlier quoted context omitted.

Wait, why do you say GPUs support parametric curves? GPUs are based on triangles mostly.

See eg https://github.com/mattdesl/parametric-curves/ and https://developer.nvidia.com/gpugems/gpugems3/part-iv-image-... You can builds all kinds on top of pixels and triangles.

That's like saying "GPUs support Master Chief". You can model Master Chief with triangles, and you can model parametric curves with triangles. But I wouldn't call it "supporting parametric curves", you're still rasterizing triangles, they're just morphed into the shape of a curve. And most practical, shipping versions of this technique would do adaptive triangulation on the CPU, since otherwise you don't have an idea of your mesh density and are either over-submitting or under-submitting triangles.

Loop-Blinn, similarly, is mostly a CPU-side approach and has a lot of drawbacks, but at it's core it's using the pixel shader to define a curve profile.

Re: Stanford CS248: Implement an SVG Rasterizer

#80

Post by danmg » Sat, Mar 21, 2020, 9:49 PM UTC

lainga wrote: post #56

danmg wrote: post #55

Earlier quoted context omitted.

No. We implemented a 3d software frame buffer pipeline at my non-Standford, non-"elite" computer science school, in C and with no dependencies other than the standard library, for our computer graphics class.

Well, that is a good example of an assignment you'd do at your local university and wouldn't get assigned at Stanford.

They're the same. The only difference here is you have to use an xml parsing library to read the input instead of rolling your own parser and spec.