Live data from Hacker News

A novel technological approach to vector graphics (“Vector Graphics Complexes”)

kickstarter.com

21–26 of 26 posts

Re: A novel technological approach to vector graphics (“Vector Graphics Complexes”)

#21
post #8

Earlier quoted context omitted.

How are you rendering these vectors on Linux? I'm asking because AFAIK unlike Windows with Direct2D, Linux doesn't have GPU-targeted vector graphics libraries. I have once made my own one when I needed something similar: https://github.com/Const-me/Vrmac#vector-graphics-engine

I'm using 3D graphics APIs, OpenGL on Linux currently, but Vulkan will be an option later. I'm converting everything to triangles on the CPU and send to OpenGL. Note that the animation app actually needs to show 3D graphics for a 2D+time visualization which is part of the innovation in my research.

> I'm converting everything to triangles on the CPU and send to OpenGL

Thanks, that’s what I thought. The library I have linked does the same thing. Only it’s either D3D12, or GLES 3.1 underneath.

Re: A novel technological approach to vector graphics (“Vector Graphics Complexes”)

#22

Earlier quoted context omitted.

> I think you can tessellation on the CPU in an adaptive fashion (e.g. based on curvature or similar) and update that on a per frame (add, remove tessellation points) basis rather than re-tesselating from scratch each frame. The GPU’s hardware-implemented tessellation is (a) not compatible enough. It’s OK on Windows because Microsoft requires them for GPU vendors to declare the support of Direct3D 11. On the rest of…

> The GPU’s hardware-implemented tessellation is (a) not compatible enough. I am unsure why we are talking about GPU-based tesselation again. I said do it on the CPU in my comment you are referencing. > Counter-intuitively, stroked paths are harder to render than filled ones. I would if it could be rendered via a 2D SDF? Similar to how you can do resolution independent fonts/decals via SDFs... basically use a cutoff…

> if it could be rendered via a 2D SDF?

I don’t think so. For one, computing SDF is a computationally hard problem.

Another thing, SDF will result in round joins, look at these pictures for available options: https://docs.microsoft.com/en-us/windows/win32/api/d2d1/ne-d... That particular spec is for MS Direct2D, but the rest of them offer the same features. Vector graphic formats are old and very stable. Similar story with line caps, SDF will get you round caps but sometimes you need different ones: https://docs.microsoft.com/en-us/windows/win32/api/d2d1/ne-d...

> The trick is to not use slow hashmaps

Every JavaScript object has such a slow hashmap, for the properties of that object.

> and then your code is near the speed of C++

JavaScript can only approach the speed of C++ for I/O bound things. For crunching numbers on CPU, the difference is rather large. Here’s some benchmark across many programming languages: https://benchmarksgame-team.pages.debian.net/benchmarksgame/ The average difference between C++ and JavaScript is 4x, for some problems it’s almost an order of magnitude.

Two reasons.

1. It’s hard to produce fast code from dynamically typed languages. CPU instructions are typed, different data types need different instructions.

2. C++ compilers work offline. In release builds, C++ optimizer can spend more time optimizing code. JavaScript JIT simply doesn’t have time to do these optimizations.

Re: A novel technological approach to vector graphics (“Vector Graphics Complexes”)

#23

Earlier quoted context omitted.

> The GPU’s hardware-implemented tessellation is (a) not compatible enough. I am unsure why we are talking about GPU-based tesselation again. I said do it on the CPU in my comment you are referencing. > Counter-intuitively, stroked paths are harder to render than filled ones. I would if it could be rendered via a 2D SDF? Similar to how you can do resolution independent fonts/decals via SDFs... basically use a cutoff…

> if it could be rendered via a 2D SDF? I don’t think so. For one, computing SDF is a computationally hard problem. Another thing, SDF will result in round joins, look at these pictures for available options: https://docs.microsoft.com/en-us/windows/win32/api/d2d1/ne-d... That particular spec is for MS Direct2D, but the rest of them offer the same features. Vector graphic formats are old and very stable. Similar stor…

Thanks a lot Const-me for all your very accurate responses! I basically have nothing more to add.

Oh, and indeed, SDF is just completely irrelevant to the problem at hand here.

I would kindly suggest ninetenfour to avoid making bold statements without more domain experience. JS is great for many things. It's just not the tool for the job here.

Re: A novel technological approach to vector graphics (“Vector Graphics Complexes”)

#24

Earlier quoted context omitted.

I'm using 3D graphics APIs, OpenGL on Linux currently, but Vulkan will be an option later. I'm converting everything to triangles on the CPU and send to OpenGL. Note that the animation app actually needs to show 3D graphics for a 2D+time visualization which is part of the innovation in my research.

> I'm converting everything to triangles on the CPU and send to OpenGL Thanks, that’s what I thought. The library I have linked does the same thing. Only it’s either D3D12, or GLES 3.1 underneath.

Wow, your library actually looks impressive! Yeah, I'm pretty much implementing all the same things.

Re: A novel technological approach to vector graphics (“Vector Graphics Complexes”)

#25

Earlier quoted context omitted.

> if it could be rendered via a 2D SDF? I don’t think so. For one, computing SDF is a computationally hard problem. Another thing, SDF will result in round joins, look at these pictures for available options: https://docs.microsoft.com/en-us/windows/win32/api/d2d1/ne-d... That particular spec is for MS Direct2D, but the rest of them offer the same features. Vector graphic formats are old and very stable. Similar stor…

Thanks a lot Const-me for all your very accurate responses! I basically have nothing more to add. Oh, and indeed, SDF is just completely irrelevant to the problem at hand here. I would kindly suggest ninetenfour to avoid making bold statements without more domain experience. JS is great for many things. It's just not the tool for the job here.

SDF 2D fields are fun though.

Give you can create them from any cubic curve and it gives you offsets from it.

https://www.iquilezles.org/www/articles/distfunctions2d/dist...

If you offset in both direction from a curve, you can pick a start and end threshold to fill an outline. This only gives you rounded outline strokes. If you had separable tangential versus normal SDFs you could vary your end cap types.

Now how do you handle an arbitrary set of knots/control points in one shader? That is a separate problems for which there are a bunch of solutions.

Re: A novel technological approach to vector graphics (“Vector Graphics Complexes”)

#26
post #9

Amazing, but this really should be a web-based app and not desktop based. Or a hybrid strategy where the desktop-based app is actually running JavaScript in an Electron shell or something. Please switch your approach ASAP or you will be beaten by a web-based app that does this exact thing, someone else will be the Figma to your Sketch. This specific use-case doesn't require the large amount of resources that would ne…

But why should it be web-based? Why would something else web-based 'beat' this based on that fact alone?

> But why should it be web-based? Why would something else web-based 'beat' this based on that fact alone?

Software distribution and/or installation, presumably.

But these factors mostly apply to the consumer and prosumer market segments (hence, the web triggered the 'consumerization of IT'), rather than to the professional market.

Post reply on HN