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.<p>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.
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?"<p>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.
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.<p>Anyone who has tried to fake 2D using 3D rendering (such as inside a game engine) has likely run into the above issues.
related:<p><a href="https://surma.dev/things/webgpu/" rel="nofollow">https://surma.dev/things/webgpu/</a> (<a href="https://news.ycombinator.com/item?id=30600525" rel="nofollow">https://news.ycombinator.com/item?id=30600525</a>)<p><a href="https://mattdesl.svbtle.com/drawing-lines-is-hard" rel="nofollow">https://mattdesl.svbtle.com/drawing-lines-is-hard</a> (<a href="https://news.ycombinator.com/item?id=13671016" rel="nofollow">https://news.ycombinator.com/item?id=13671016</a>)<p><a href="https://blog.mapbox.com/drawing-antialiased-lines-with-opengl-8766f34192dc?gi=38f8cb8c1475" rel="nofollow">https://blog.mapbox.com/drawing-antialiased-lines-with-openg...</a><p>i'd like to try implementing this paper [1] in WebGPU, but think it's over my head currently, having mainly worked with Canvas2D.<p>[1] <a href="https://jcgt.org/published/0002/02/08/paper.pdf" rel="nofollow">https://jcgt.org/published/0002/02/08/paper.pdf</a>
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.
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.<p><a href="http://en.wikipedia.org/wiki/Paul_Haeberli" rel="nofollow">http://en.wikipedia.org/wiki/Paul_Haeberli</a><p><a href="http://www.graficaobscura.com/texmap/index.html" rel="nofollow">http://www.graficaobscura.com/texmap/index.html</a>
The content of the article contradicts its title.<p>The tl;dr is that 2D vector graphics uses implicit geometry while 3D is explicitly defined using vertices and triangles, implicit means "more maths".<p>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.<p>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.
> <i>"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"</i><p>Just for information : 10 years ago, NVidia has released this paper and extension "GPU Accelerated Path Rendering" : <a href="https://developer.nvidia.com/gpu-accelerated-path-rendering" rel="nofollow">https://developer.nvidia.com/gpu-accelerated-path-rendering</a> , so it seems GPU can still help
I've written about the history of PostScript, Interpress and NeWS before:<p><a href="https://news.ycombinator.com/item?id=21968175" rel="nofollow">https://news.ycombinator.com/item?id=21968175</a><p>>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). [...]<p><a href="https://news.ycombinator.com/item?id=22456710" rel="nofollow">https://news.ycombinator.com/item?id=22456710</a><p>>Owen Densmore recounted John Warnock's idea that PostScript was actually a "linguistic motherboard". [...]<p>>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.<p><a href="https://en.wikipedia.org/wiki/Brian_Reid_(computer_scientist)" rel="nofollow">https://en.wikipedia.org/wiki/Brian_Reid_(computer_scientist...</a><p><a href="http://glennreid.blogspot.com/" rel="nofollow">http://glennreid.blogspot.com/</a><p>Here's a post I wrote earlier:<p><a href="https://news.ycombinator.com/item?id=19874245" rel="nofollow">https://news.ycombinator.com/item?id=19874245</a><p>>DonHopkins 8 months ago [-]<p>>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:<p><a href="https://groups.google.com/forum/#!topic/fa.laser-lovers/H3us4h8S3Kk" rel="nofollow">https://groups.google.com/forum/#!topic/fa.laser-lovers/H3us...</a><p>>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.