10 ms·

Why are 2D vector graphics so much harder than 3D? (2019)

135 points by thesephist 5y ago

DonHopkins 5y ago
I've written about the history of PostScript, Interpress and NeWS before: https://news.ycombinator.com/item?id=21968175 https://news.ycombinator.com/item?id=21968175 >Kragen is right that PostScript is a lot more like Lisp or Smalltalk than Forth, especially when you use Owen Densmore's object oriented PostScript programming system (which NeWS was based on). PostScript is semantically very different and much higher level that Forth, and syntactically similar to Forth but uses totally different names (exch instead of swap, pop instead of drop, etc). [...] https://news.ycombinator.com/item?id=22456710 https://news.ycombinator.com/item?id=22456710 >Owen Densmore recounted John Warnock's idea that PostScript was actually a "linguistic motherboard". [...] >Brian Reid (whose brother is Glenn Reid, author of several books on PostScript from Adobe) wrote up an excellent historical summary in 1985 on the laser-lovers mailing list of the influences and evolution of PostScript. https://en.wikipedia.org/wiki/Brian_Reid_(computer_scientist) https://en.wikipedia.org/wiki/Brian_Reid_(computer_scientist... http://glennreid.blogspot.com/ http://glennreid.blogspot.com/ Here's a post I wrote earlier: https://news.ycombinator.com/item?id=19874245 https://news.ycombinator.com/item?id=19874245 >DonHopkins 8 months ago [-] >Brian Reid wrote about page independence, comparing Interpress' and PostScript's different approaches. Adobe's later voluntary Document Structuring Conventions actually used PostScript comments to make declarations and delimit different parts of the file -- it wasn't actually a part of the PostScript language, while Interpress defined pages as independent so they couldn't possibly affect each other: https://groups.google.com/forum/#!topic/fa.laser-lovers/H3us4h8S3Kk https://groups.google.com/forum/#!topic/fa.laser-lovers/H3us... >By now you can probably see the fundamental philosophical difference between PostScript and Interpress. Interpress takes the stance that the language system must guarantee certain useful properties, while PostScript takes the stance that the language system must provide the user with the means to achieve those properties if he wants them. With very few exceptions, both languages provide the same facilities, but in Interpress the protection mechanisms are mandatory and in PostScript they are optional. Debates over the relative merits of mandatory and optional protection systems have raged for years not only in the programming language community but also among owners of motorcycle helmets. While the Interpress language mandates a particular organization, the PostScript language provides the tools (structuring conventions and SAVE/RESTORE) to duplicate that organization exactly, with all of the attendant benefits. However, the PostScript user need not employ those tools.
n3k5 5y ago
2019. Previous discussion: https://news.ycombinator.com/item?id=19871207 https://news.ycombinator.com/item?id=19871207
- smegsicle 5y ago
  > bsenftner on May 10, 2019 | prev [–] > Revision of history, wrong, and insultingly so. This post is a rewrite of serious graphics history. Read Foley Dan Vam, forget this tripe.
deleted 5y ago
[deleted]
fatih-erikli 5y ago
Actually we have the same problems and challenges in 3d as well. At the end 3d is result of a 2d image rendered with a projection matrix and others. Stroking is difficult, for example. You need to combine little triangles to construct a line with miters in 3d, etc. In my opinion, 3d graphics are harder than 2d for sure. WebGL API is dirty. There's a Webgl, Webgl2, and we're going to have another one: WebGPU, and hopefully it will make 3d easier. In 2d we just have 2d drawing context.
- moron4hire 5y ago
  >> WebGPU... hopefully... will make 3d easier. That is explicitly not a goal of the WebGPU working group. They have acknowledged that WebGPU will make 3D graphics programming in the browser significantly harder. But it will make supporting the 3D graphics API in the browser easier for the browser developers. So basically, because Apple took over a decade to finally unsqueeze their tight fingers enough to dedicate any developers to WebGL2 in Safari, instead of improving the site developer experience, the W3C has opted to take huge swaths of responsibility away from browser developers and foist it on site devs. The "hope" is that middle-tier libraries like Three.js and Babylon.js will hide the complexity away. I'm sure they will, and by all my experiences with them, will do a fine job of it. But it's certainly not the direction I hoped things would go.
  - fatih-erikli 5y ago
    In my opinion if we're going to have a stable and a consistent API, I'm totally ok if it's going to be significantly harder. I think we should not need a middle-tier library for creating 3d graphics. Most of the time We needed threejs or twgl for mapping the shader inputs (uniforms etc) with javascript. The rest of it is just pure matrix math, that we do in 2d graphics as well. It's worth to mention that they're also going to create another shading language. https://www.w3.org/TR/WGSL/ https://www.w3.org/TR/WGSL/
  - esperent 5y ago
    The API may get harder, but that's not a huge deal. Not saying that's a good thing, but APIs are far from the hardest thing in 3D graphics. In my experience using WebGL, the hardest thing is all the missing parts compared to modern APIs and the fact that, whenever you want to implement something, you can't use the newest techniques and have to go hunting around to find out how the game dev community used to do things 20 years ago. I would take a jump in API complexity in exchange for access to a modern graphics pipeline and I'm excited by the new opportunities WebGPU will afford my work.
leeoniya 5y ago
related: https://surma.dev/things/webgpu/ https://surma.dev/things/webgpu/ (https://news.ycombinator.com/item?id=30600525 https://news.ycombinator.com/item?id=30600525) https://mattdesl.svbtle.com/drawing-lines-is-hard https://mattdesl.svbtle.com/drawing-lines-is-hard (https://news.ycombinator.com/item?id=13671016 https://news.ycombinator.com/item?id=13671016) https://blog.mapbox.com/drawing-antialiased-lines-with-opengl-8766f34192dc?gi=38f8cb8c1475 https://blog.mapbox.com/drawing-antialiased-lines-with-openg... i'd like to try implementing this paper [1] in WebGPU, but think it's over my head currently, having mainly worked with Canvas2D. [1] https://jcgt.org/published/0002/02/08/paper.pdf https://jcgt.org/published/0002/02/08/paper.pdf
- koshergweilo 5y ago
  I would highly recommend learning more about webgl before diving into webGPU. https://webglfundamentals.org/ https://webglfundamentals.org/ is a good place to start
  - leeoniya 5y ago
    from what i've read, they're pretty different abstractions, so i'm concerned that learning WebGL2 will give me a mental model that will be largely useless and just add to the confusion when switching to WebGPU. even the shader language is different (WGSL vs GLSL) [1]. how much knowledge will be transferable? [1] https://dmnsgn.me/blog/from-glsl-to-wgsl-the-future-of-shaders-on-the-web/ https://dmnsgn.me/blog/from-glsl-to-wgsl-the-future-of-shade...
    - pjmlp 5y ago
      Think of it like algorithms and data structures are at their basis language agnostic. Same applies to the 3D programming, while the way to implement something like deferred rendering (as an example) is different across APIs, it still is deferred rendering.
jayd16 5y ago
It's a strange take that 2D == vector graphics and 3D == resterization and then write a blog post that's really about vector vs raster under the auspices of 2D vs 3D.
- Jasper_ 5y ago
  Both the 2D and 3D here are vectors -- both the 2D lines and the 3D triangles are represented as a sequence of mathematical points which have to be "rasterized". But, put simply, triangle rasterization is just a much easier problem than curve rasterization.
phendrenad2 5y ago
Easy, 2D is harder because it can have hard edges. Look at any 3D game, the edges of the polygons are obscured by antialiasing methods and texture wrapping. In 2D, you need to draw a line at some arbitrary angle (or worse, a spline!) where on one side there's black and on the other side white. You will have to fake this with subpixel rendering. You also need to detect when the subpixels would interfere with the actual line width. You need to be able to snap two objects together that fit together seamlessly in the mathematical sense, without a sliver in-between popping in and out of existence. Anyone who has tried to fake 2D using 3D rendering (such as inside a game engine) has likely run into the above issues.
GuB-42 5y ago
The content of the article contradicts its title. The tl;dr is that 2D vector graphics uses implicit geometry while 3D is explicitly defined using vertices and triangles, implicit means "more maths". And as the article says, the reason we don't use implicit geometry in 3D is that it is simply too hard except for a few specific cases, at least for now. To answer the question "why 2D is harder?" is "because we are not talking about the same thing". From easiest to hardest we have: 2D triangle-based, 3D triangle-based, 2D implicit, 3D implicit.
bob1029 5y ago
I disagree with the fundamental assertion that 2d is harder than 3d. I think a more accurate title would be "Why are 2D vector graphics so much harder than 3D when using a 3D-oriented raster graphics pipeline?" If we remove the existing constraints and say you have to build these things in pure software, I think the equation would look a little different. I don't know of many developers who can accurately describe what the GPU does these days. Triangle rasterization is not an easy problem if you have to solve it yourself.
- tawaypol 5y ago
  Is it even that? People tolerate a lot more artifacts in 3D than 2D. If you wrote a 2D graphics engine that used triangles as primitives people probably wouldn't like it (and it would probably render text very slowly.)
- DonHopkins 5y ago
  It's that you're usually rasterizing much more complicated shapes than triangles in 2D, like polygons and curves and fonts with hinting (which is often actually implemented as Turing-complete byte code, not stuff that's easy to run in parallel entirely in the GPU). https://en.wikipedia.org/wiki/PostScript_fonts#Type_2 https://en.wikipedia.org/wiki/PostScript_fonts#Type_2 https://en.wikipedia.org/wiki/Font_hinting https://en.wikipedia.org/wiki/Font_hinting https://www.typotheque.com/articles/hinting https://www.typotheque.com/articles/hinting
- jstimpfle 5y ago
  Writing a triangle rasterizer is not that hard. What APIs like OpenGL give you for free (other than a performance boost) is walking all the pixels that are covered by each triangle, and computing the barycentric coordinates for each pixel (and then using these to lerp the vertex data). So that's what you have to replace by a CPU program. I find the much harder part is how to setup the architecture in such a way that the data flows through your shader pipelines without an unbearable amount of boilerplate. 3D APIs don't help with that - if anything they make it harder.
  - bob1029 5y ago
karteum 5y ago
> "GPUs, through a consequence of history, chose not to focus on real-time implicit geometry like curves, but instead on everything that goes inside them" Just for information : 10 years ago, NVidia has released this paper and extension "GPU Accelerated Path Rendering" : https://developer.nvidia.com/gpu-accelerated-path-rendering https://developer.nvidia.com/gpu-accelerated-path-rendering , so it seems GPU can still help
DonHopkins 5y ago
Paul Haberli, when he was a computer graphics researcher at SGI, wrote a paper in 1993 called Texture Mapping as a Fundamental Drawing Primitive, which was about how to use texture mapping for drawing anti-aliased lines, air-brushes, anti-aliased text, volume rendering, environment mapping, color interpolation, contouring, and many other applications. http://en.wikipedia.org/wiki/Paul_Haeberli http://en.wikipedia.org/wiki/Paul_Haeberli http://www.graficaobscura.com/texmap/index.html http://www.graficaobscura.com/texmap/index.html

135 points by thesephist 5y ago

I've written about the history of PostScript, Interpress and NeWS before: https://news.ycombinator.com/item?id=21968175 https://news.ycombinator.com/item?id=21968175 >Kragen is right that PostScript is a lot more like Lisp or Smalltalk than Forth, especially when you use Owen Densmore's object oriented PostScript programming system (which NeWS was based on). PostScript is semantically very different and much higher level that Forth, and syntactically similar to Forth but uses totally different names (exch instead of swap, pop instead of drop, etc). [...] https://news.ycombinator.com/item?id=22456710 https://news.ycombinator.com/item?id=22456710 >Owen Densmore recounted John Warnock's idea that PostScript was actually a "linguistic motherboard". [...] >Brian Reid (whose brother is Glenn Reid, author of several books on PostScript from Adobe) wrote up an excellent historical summary in 1985 on the laser-lovers mailing list of the influences and evolution of PostScript. https://en.wikipedia.org/wiki/Brian_Reid_(computer_scientist) https://en.wikipedia.org/wiki/Brian_Reid_(computer_scientist... http://glennreid.blogspot.com/ http://glennreid.blogspot.com/ Here's a post I wrote earlier: https://news.ycombinator.com/item?id=19874245 https://news.ycombinator.com/item?id=19874245 >DonHopkins 8 months ago [-] >Brian Reid wrote about page independence, comparing Interpress' and PostScript's different approaches. Adobe's later voluntary Document Structuring Conventions actually used PostScript comments to make declarations and delimit different parts of the file -- it wasn't actually a part of the PostScript language, while Interpress defined pages as independent so they couldn't possibly affect each other: https://groups.google.com/forum/#!topic/fa.laser-lovers/H3us4h8S3Kk https://groups.google.com/forum/#!topic/fa.laser-lovers/H3us... >By now you can probably see the fundamental philosophical difference between PostScript and Interpress. Interpress takes the stance that the language system must guarantee certain useful properties, while PostScript takes the stance that the language system must provide the user with the means to achieve those properties if he wants them. With very few exceptions, both languages provide the same facilities, but in Interpress the protection mechanisms are mandatory and in PostScript they are optional. Debates over the relative merits of mandatory and optional protection systems have raged for years not only in the programming language community but also among owners of motorcycle helmets. While the Interpress language mandates a particular organization, the PostScript language provides the tools (structuring conventions and SAVE/RESTORE) to duplicate that organization exactly, with all of the attendant benefits. However, the PostScript user need not employ those tools.

n3k5 5y ago

2019. Previous discussion: https://news.ycombinator.com/item?id=19871207 https://news.ycombinator.com/item?id=19871207

smegsicle 5y ago
> bsenftner on May 10, 2019 | prev [–] > Revision of history, wrong, and insultingly so. This post is a rewrite of serious graphics history. Read Foley Dan Vam, forget this tripe.

deleted 5y ago

[deleted]

fatih-erikli 5y ago

Actually we have the same problems and challenges in 3d as well. At the end 3d is result of a 2d image rendered with a projection matrix and others. Stroking is difficult, for example. You need to combine little triangles to construct a line with miters in 3d, etc. In my opinion, 3d graphics are harder than 2d for sure. WebGL API is dirty. There's a Webgl, Webgl2, and we're going to have another one: WebGPU, and hopefully it will make 3d easier. In 2d we just have 2d drawing context.

moron4hire 5y ago
>> WebGPU... hopefully... will make 3d easier. That is explicitly not a goal of the WebGPU working group. They have acknowledged that WebGPU will make 3D graphics programming in the browser significantly harder. But it will make supporting the 3D graphics API in the browser easier for the browser developers. So basically, because Apple took over a decade to finally unsqueeze their tight fingers enough to dedicate any developers to WebGL2 in Safari, instead of improving the site developer experience, the W3C has opted to take huge swaths of responsibility away from browser developers and foist it on site devs. The "hope" is that middle-tier libraries like Three.js and Babylon.js will hide the complexity away. I'm sure they will, and by all my experiences with them, will do a fine job of it. But it's certainly not the direction I hoped things would go.
- fatih-erikli 5y ago
  In my opinion if we're going to have a stable and a consistent API, I'm totally ok if it's going to be significantly harder. I think we should not need a middle-tier library for creating 3d graphics. Most of the time We needed threejs or twgl for mapping the shader inputs (uniforms etc) with javascript. The rest of it is just pure matrix math, that we do in 2d graphics as well. It's worth to mention that they're also going to create another shading language. https://www.w3.org/TR/WGSL/ https://www.w3.org/TR/WGSL/
- esperent 5y ago
  The API may get harder, but that's not a huge deal. Not saying that's a good thing, but APIs are far from the hardest thing in 3D graphics. In my experience using WebGL, the hardest thing is all the missing parts compared to modern APIs and the fact that, whenever you want to implement something, you can't use the newest techniques and have to go hunting around to find out how the game dev community used to do things 20 years ago. I would take a jump in API complexity in exchange for access to a modern graphics pipeline and I'm excited by the new opportunities WebGPU will afford my work.

leeoniya 5y ago

related: https://surma.dev/things/webgpu/ https://surma.dev/things/webgpu/ (https://news.ycombinator.com/item?id=30600525 https://news.ycombinator.com/item?id=30600525) https://mattdesl.svbtle.com/drawing-lines-is-hard https://mattdesl.svbtle.com/drawing-lines-is-hard (https://news.ycombinator.com/item?id=13671016 https://news.ycombinator.com/item?id=13671016) https://blog.mapbox.com/drawing-antialiased-lines-with-opengl-8766f34192dc?gi=38f8cb8c1475 https://blog.mapbox.com/drawing-antialiased-lines-with-openg... i'd like to try implementing this paper [1] in WebGPU, but think it's over my head currently, having mainly worked with Canvas2D. [1] https://jcgt.org/published/0002/02/08/paper.pdf https://jcgt.org/published/0002/02/08/paper.pdf

koshergweilo 5y ago
I would highly recommend learning more about webgl before diving into webGPU. https://webglfundamentals.org/ https://webglfundamentals.org/ is a good place to start
- leeoniya 5y ago
  from what i've read, they're pretty different abstractions, so i'm concerned that learning WebGL2 will give me a mental model that will be largely useless and just add to the confusion when switching to WebGPU. even the shader language is different (WGSL vs GLSL) [1]. how much knowledge will be transferable? [1] https://dmnsgn.me/blog/from-glsl-to-wgsl-the-future-of-shaders-on-the-web/ https://dmnsgn.me/blog/from-glsl-to-wgsl-the-future-of-shade...
  - pjmlp 5y ago
    Think of it like algorithms and data structures are at their basis language agnostic. Same applies to the 3D programming, while the way to implement something like deferred rendering (as an example) is different across APIs, it still is deferred rendering.

jayd16 5y ago

It's a strange take that 2D == vector graphics and 3D == resterization and then write a blog post that's really about vector vs raster under the auspices of 2D vs 3D.

Jasper_ 5y ago
Both the 2D and 3D here are vectors -- both the 2D lines and the 3D triangles are represented as a sequence of mathematical points which have to be "rasterized". But, put simply, triangle rasterization is just a much easier problem than curve rasterization.

phendrenad2 5y ago

Easy, 2D is harder because it can have hard edges. Look at any 3D game, the edges of the polygons are obscured by antialiasing methods and texture wrapping. In 2D, you need to draw a line at some arbitrary angle (or worse, a spline!) where on one side there's black and on the other side white. You will have to fake this with subpixel rendering. You also need to detect when the subpixels would interfere with the actual line width. You need to be able to snap two objects together that fit together seamlessly in the mathematical sense, without a sliver in-between popping in and out of existence. Anyone who has tried to fake 2D using 3D rendering (such as inside a game engine) has likely run into the above issues.

GuB-42 5y ago

The content of the article contradicts its title. The tl;dr is that 2D vector graphics uses implicit geometry while 3D is explicitly defined using vertices and triangles, implicit means "more maths". And as the article says, the reason we don't use implicit geometry in 3D is that it is simply too hard except for a few specific cases, at least for now. To answer the question "why 2D is harder?" is "because we are not talking about the same thing". From easiest to hardest we have: 2D triangle-based, 3D triangle-based, 2D implicit, 3D implicit.

bob1029 5y ago

I disagree with the fundamental assertion that 2d is harder than 3d. I think a more accurate title would be "Why are 2D vector graphics so much harder than 3D when using a 3D-oriented raster graphics pipeline?" If we remove the existing constraints and say you have to build these things in pure software, I think the equation would look a little different. I don't know of many developers who can accurately describe what the GPU does these days. Triangle rasterization is not an easy problem if you have to solve it yourself.

tawaypol 5y ago
Is it even that? People tolerate a lot more artifacts in 3D than 2D. If you wrote a 2D graphics engine that used triangles as primitives people probably wouldn't like it (and it would probably render text very slowly.)
DonHopkins 5y ago
It's that you're usually rasterizing much more complicated shapes than triangles in 2D, like polygons and curves and fonts with hinting (which is often actually implemented as Turing-complete byte code, not stuff that's easy to run in parallel entirely in the GPU). https://en.wikipedia.org/wiki/PostScript_fonts#Type_2 https://en.wikipedia.org/wiki/PostScript_fonts#Type_2 https://en.wikipedia.org/wiki/Font_hinting https://en.wikipedia.org/wiki/Font_hinting https://www.typotheque.com/articles/hinting https://www.typotheque.com/articles/hinting
jstimpfle 5y ago
Writing a triangle rasterizer is not that hard. What APIs like OpenGL give you for free (other than a performance boost) is walking all the pixels that are covered by each triangle, and computing the barycentric coordinates for each pixel (and then using these to lerp the vertex data). So that's what you have to replace by a CPU program. I find the much harder part is how to setup the architecture in such a way that the data flows through your shader pipelines without an unbearable amount of boilerplate. 3D APIs don't help with that - if anything they make it harder.
- bob1029 5y ago

karteum 5y ago

> "GPUs, through a consequence of history, chose not to focus on real-time implicit geometry like curves, but instead on everything that goes inside them" Just for information : 10 years ago, NVidia has released this paper and extension "GPU Accelerated Path Rendering" : https://developer.nvidia.com/gpu-accelerated-path-rendering https://developer.nvidia.com/gpu-accelerated-path-rendering , so it seems GPU can still help

DonHopkins 5y ago

Paul Haberli, when he was a computer graphics researcher at SGI, wrote a paper in 1993 called Texture Mapping as a Fundamental Drawing Primitive, which was about how to use texture mapping for drawing anti-aliased lines, air-brushes, anti-aliased text, volume rendering, environment mapping, color interpolation, contouring, and many other applications. http://en.wikipedia.org/wiki/Paul_Haeberli http://en.wikipedia.org/wiki/Paul_Haeberli http://www.graficaobscura.com/texmap/index.html http://www.graficaobscura.com/texmap/index.html