Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

kickstarter.com

Post reply on HN
Print view View original

11–20 of 26 posts

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

#11

Post by jlokier »

borisdalstein wrote: post #5
ninetenfour wrote: post #2

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…

Thanks for the comment, I'm the developer of the app! Having it run in a browser would clearly be convenient, but unfortunately Javascript is really too slow. I even wish C++ was faster. Rendering the vector paths requires the same type of heavy computation as a modern AAA game, and we don't see AAA games implemented in Javascript for good reasons. The paths need to be tessellated, sent to the GPU, then the different…

Just in case it's useful: You actually can run C++ in the browser these days to do the intensive things, by using WebAssembly (WASM). It can call out to graphics APIs, so it might work for this project without changing the C++ much.

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

#12

Post by Const-me »

ninetenfour wrote: post #10
borisdalstein wrote: post #5

Earlier quoted context omitted.

Thanks for the comment, I'm the developer of the app! Having it run in a browser would clearly be convenient, but unfortunately Javascript is really too slow. I even wish C++ was faster. Rendering the vector paths requires the same type of heavy computation as a modern AAA game, and we don't see AAA games implemented in Javascript for good reasons. The paths need to be tessellated, sent to the GPU, then the different…

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 tessellation would just have weights from each control point. You can modify the vertices on the CPU, update the tessellation points and update those to the GPU. Get 60fps should be possible ev…

> 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 platforms, support across GPU vendors varies. And (b) doesn’t help much for 2D vector graphics. The hardware tessellation can be good for terrain, trees, or other triangle meshes in 3D space. Doesn’t help much for these Bezier curves/elliptical arcs for 2D shapes. Especially so for stroked paths.

Counter-intuitively, stroked paths are harder to render than filled ones. The offset of Bezier spline is not representable as another Bezier spline. Also, strokes have more parameters on input: line caps, join types, dashes, miter limit, etc.

> The main limitation in JS is the lack of really great multithreading

Also lack of SIMD. Also, the code in general is slow compared to C++, C# and many other statically typed languages. It’s incredibly hard to generate fast code from very dynamic languages like JS or Python, where everything is a hash map.

> I do not think you need it here.

Here’s my code which offloads CPU-bound pieces of 2D rendering to other CPU cores: https://github.com/Const-me/Vrmac/tree/master/Vrmac/Draw/Tes... Multithreading helped a lot.

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

#13

Post by fractallyte »

borisdalstein wrote: post #6
fractallyte wrote: post #4

Back in the early 2000s, there was a vector graphics application called Expression, created by Creature House, a small Hong Kong-based company ( https://en.wikipedia.org/wiki/Creature_House_Expression ). They also had a beta of an animation version of Expression, called LivingCels. It had been battle-tested in various local animation studios, and was just getting ready to burst into the market... (dominated, at that…

Wow, this is cool, I had heard of Expression but didn't the whole backstory. I will definitely have to check it out. And indeed I have a lot of catching up to do feature-wise :) VGC Illustration won't be able to be as feature-complete as Illustrator for a long time, but hopefully the killer features and better drawing experience will make up for it.

I sincerely wish you well! (And I'll back your KS campaign)

I've been entertaining a thought for a long time... to approach MS and ask (very, very nicely!) if they'd be willing to part with the source code for Expression and LivingCels. They're not using it in any way, and these are killer apps which definitely have a lot of life in them yet.

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

#14

Post by ninetenfour »

Const-me wrote: post #12
ninetenfour wrote: post #10

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 tessellation would just have weights from each control point. You can modify the vertices on the CPU, update the tessellation points and update those to the GPU. Get 60fps should be possible ev…

> 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 distance from stroke midline or similar.

> Also, the code in general is slow compared to C++, C# and many other statically typed languages. It’s incredibly hard to generate fast code from very dynamic languages like JS or Python, where everything is a hash map.

The above is 100% incorrect. The trick is to not use slow hashmaps and then your code is near the speed of C++. Use ArrayBuffers instead for everything. I said this in my earlier comment.

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

#15

Post by borisdalstein »

ninetenfour wrote: post #10
borisdalstein wrote: post #5

Earlier quoted context omitted.

Thanks for the comment, I'm the developer of the app! Having it run in a browser would clearly be convenient, but unfortunately Javascript is really too slow. I even wish C++ was faster. Rendering the vector paths requires the same type of heavy computation as a modern AAA game, and we don't see AAA games implemented in Javascript for good reasons. The paths need to be tessellated, sent to the GPU, then the different…

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 tessellation would just have weights from each control point. You can modify the vertices on the CPU, update the tessellation points and update those to the GPU. Get 60fps should be possible ev…

Thanks for all the advice, I know it is well-intended, but unfortunately this late in the project there is nothing that could change my mind anyway. It's too late.

But even if I had to start from scratch, I would still use C++. It is the most-used language in this field for rational reasons, not just for mistaken beliefs. Multi-threading is important, supporting custom pen tablets hardware is important, accessing Metal and Direct3D graphics API is important, being able to use the core as a shared library for command-line tools is important, being able to not crash when another tab makes the browser crash is important (okay, for this I could use electron). Being able to embed a Python interpreter is important (yes, it has to be Python it's a design decision). And we're not talking 1Ks vertices, but millions.

Again, AAA games are not developed in Javascript for a reason. Professional productivity graphics application have the same requirements than AAA games.

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

#16

Post by borisdalstein »

Const-me wrote: post #8
borisdalstein wrote: post #5

Earlier quoted context omitted.

Thanks for the comment, I'm the developer of the app! Having it run in a browser would clearly be convenient, but unfortunately Javascript is really too slow. I even wish C++ was faster. Rendering the vector paths requires the same type of heavy computation as a modern AAA game, and we don't see AAA games implemented in Javascript for good reasons. The paths need to be tessellated, sent to the GPU, then the different…

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.

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

#17

Post by ninetenfour »

borisdalstein wrote: post #15
ninetenfour wrote: post #10

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 tessellation would just have weights from each control point. You can modify the vertices on the CPU, update the tessellation points and update those to the GPU. Get 60fps should be possible ev…

Thanks for all the advice, I know it is well-intended, but unfortunately this late in the project there is nothing that could change my mind anyway. It's too late. But even if I had to start from scratch, I would still use C++. It is the most-used language in this field for rational reasons, not just for mistaken beliefs. Multi-threading is important, supporting custom pen tablets hardware is important, accessing Met…

Tablets are important, so native apps for tablets makes sense if you think this is the main device people will use. ProCreate, Autodesk Sketchbook, etc. live on the tablet and native makes sense for that experience.

But then do not target desktop. You should target tablets and the pen-based interface on them.

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

#18

Post by borisdalstein »

fractallyte wrote: post #13
borisdalstein wrote: post #6

Earlier quoted context omitted.

Wow, this is cool, I had heard of Expression but didn't the whole backstory. I will definitely have to check it out. And indeed I have a lot of catching up to do feature-wise :) VGC Illustration won't be able to be as feature-complete as Illustrator for a long time, but hopefully the killer features and better drawing experience will make up for it.

I sincerely wish you well! (And I'll back your KS campaign) I've been entertaining a thought for a long time... to approach MS and ask (very, very nicely!) if they'd be willing to part with the source code for Expression and LivingCels. They're not using it in any way, and these are killer apps which definitely have a lot of life in them yet.

Thanks a lot! Getting the code for Expression could be interesting, although the code is so old, I wonder how useful it would be. Especially modern C++ has changed a lot, sometimes it's nice to start with a clean slate.

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

#19

Post by borisdalstein »

wds wrote: post #9
ninetenfour wrote: post #2

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?

Playing devil's advocate, I'd argue that it does make development much faster, and portability much easier. This is important.

But otherwise I clearly agree with you. There's no reason why I would make it web-based in the first place.

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

#20

Post by borisdalstein »

ninetenfour wrote: post #17
borisdalstein wrote: post #15

Earlier quoted context omitted.

Thanks for all the advice, I know it is well-intended, but unfortunately this late in the project there is nothing that could change my mind anyway. It's too late. But even if I had to start from scratch, I would still use C++. It is the most-used language in this field for rational reasons, not just for mistaken beliefs. Multi-threading is important, supporting custom pen tablets hardware is important, accessing Met…

Tablets are important, so native apps for tablets makes sense if you think this is the main device people will use. ProCreate, Autodesk Sketchbook, etc. live on the tablet and native makes sense for that experience. But then do not target desktop. You should target tablets and the pen-based interface on them.

I will also target iPads and Android tablets as native apps, yes. But most professional users use a powerful desktop computer with a Wacom Intuos or Cintiq. Some professional work requires hundreds of layers, and in the context of animation, you're not going to make the next Studio Ghibli animation on an iPad. You need your 64GBs or RAM.
Post reply on HN