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

Zdog – Pseudo-3D JavaScript engine for Canvas and SVG

zzz.dog

Post reply on HN
Print view View original

71–80 of 96 posts

Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG

#71

Post by undershirt »

luminati wrote: post #31

N00b question - why is it called pseudo-3d? It looks and feels very much 3d like a three.js output.

Submitted a clarifying description: https://github.com/metafizzy/zdog-docs/issues/4

> Zdog is a pseudo-3D Vector Art engine. You define your geometry using 3D splines and blobs, which render as 2D SVG shapes for any arbitrary perspective.

> For nerds—this simple translation is made possible by assuming an orthographic projection (where drawing 3D splines becomes trivially reducible to flat 2D splines—not so with perspective projection). More obvious, the occlusion-culling is achieved with a trivial drawing order or by hiding entire 2D primitives when appropriate.

Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG

#72

Post by overgard »

pjc50 wrote: post #34
overgard wrote: post #6

I notice that there are some issues with depth sorting (which I guess would be expected). It'd be complicated, but one way you could do the same effect without that issue is to use signed distance fields in a shader: https://www.iquilezles.org/www/articles/distfunctions/distfu... (Demo at the bottom of the page)

If you've got a shader engine you could render real 3D. This is a very different approach.

Well the advantage of this approach is you get vector graphics, which you don't with a standard mesh based approach to 3d. That's why I was mentioning the signed distance field thing -- you can get the same style without z-fighting, plus you can do some interesting shape blending and stuff which allows for some interesting possibility.

Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG

#73

Post by overgard »

soylentgraham wrote: post #33
overgard wrote: post #6

I notice that there are some issues with depth sorting (which I guess would be expected). It'd be complicated, but one way you could do the same effect without that issue is to use signed distance fields in a shader: https://www.iquilezles.org/www/articles/distfunctions/distfu... (Demo at the bottom of the page)

Are you suggesting ray marching the object instead of drawing 2D shapes?

Yes, if you don't want z-fighting. If you don't care then this is perfectly fine. But since both approaches can be expressed in a very similar way (primitives that can easily be mathematically modeled), and rendered in the same style, I figured it's an interesting way of achieving the same thing if you want the same style and scalability while allowing for intersecting objects. The trade-off is that ray marching is more expensive.

Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG

#74

Post by overgard »

dahart wrote: post #65
overgard wrote: post #6

I notice that there are some issues with depth sorting (which I guess would be expected). It'd be complicated, but one way you could do the same effect without that issue is to use signed distance fields in a shader: https://www.iquilezles.org/www/articles/distfunctions/distfu... (Demo at the bottom of the page)

A signed distance field approach is fundamentally incompatible with this library and it's goals. Zdog is a vector drawing library, it's resolution independent. When you render to SVG, you can later rasterize that SVG at any resolution. This lets you do things like print at large sizes or high DPI. Ray marching is a raster (pixel based / resolution dependent) way to render.

> Zdog is a vector drawing library, it's resolution independent. When you render to SVG, you can later rasterize that SVG at any resolution. This lets you do things like print at large sizes or high DPI.

Signed distance fields and ray marching are completely resolution independent... The only limit is your canvas size. You can emulate the exact same effects, plus some additional ones since you can blend the shapes.

They aren't incompatible, but the trade-off is in efficiency. Ray marching is more expensive usually, but also more expressive and extensible. If you look at https://www.shadertoy.com/ , a large set of those effects use signed distance fields exactly because by using mathematical functions you can have vector-like infinite precision.

I guess you're right in that you can't, say, put it in a document and print it. But considering that the advantage of this is that it's 3D, if you wanted this for print you'd probably just draw something in inkscape or illustrator anyway.

Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG

#75

Post by overgard »

myfonj wrote: post #20
overgard wrote: post #6

I notice that there are some issues with depth sorting (which I guess would be expected). It'd be complicated, but one way you could do the same effect without that issue is to use signed distance fields in a shader: https://www.iquilezles.org/www/articles/distfunctions/distfu... (Demo at the bottom of the page)

It is addressed in https://zzz.dog/extras#z-fighting as a feature: > Z-fighting in Zdog is the natural result of its pseudo-3D engine. Zdog’s 3D shapes are actually 2D projections, rendered without any accounting for collisions with other shapes. > Rather than fighting against this effect, the best course is to accept it. Z-fighting is one of Zdog’s charms. Embrace it.

Yeah, although personally I don't want to embrace z-fighting :-) Different subjective opinion though.

Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG

#76

Post by overgard »

ClassyJacket wrote: post #11
overgard wrote: post #6

I notice that there are some issues with depth sorting (which I guess would be expected). It'd be complicated, but one way you could do the same effect without that issue is to use signed distance fields in a shader: https://www.iquilezles.org/www/articles/distfunctions/distfu... (Demo at the bottom of the page)

I wonder if some sort of progressive dither or fade is practical to implement and fast enough (and visually useful)? If I wasn't at work right now I would have a look at the code. I have some experience with Canvas rendering but, like this, just in straightforward layers. I don't think a dither would be practical, a fade might be using a mask and setting the alpha, but you'd still have to detect all the overlap. I'd…

Yeah, you could do it in a shader, but in SVG not so much

Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG

#77

Post by The_Amp_Walrus »

jmiskovic wrote: post #38
The_Amp_Walrus wrote: post #25

Does this library support dynamic rendering? I tried to add extra elements to the illustration after rendering it to the canvas and it doesn't appear to work. I might be using the API incorrectly though - is the idea that you can use this library to produce a static model which can then be transformed (eg. rotated), but can't be extended after the first render?

Did you try to call updateGraph() after adding elements? It seems like it should do the trick. [] https://zzz.dog/api#anchor-updategraph

This was my initial attempt using an Illustration https://codepen.io/anon/pen/NVORrZ

This is my 2nd attempt using the docs you linked https://codepen.io/anon/pen/QRZKxy?editors=0010

What do you think - is updateGraph + render supposed to work more than once?

Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG

#79

Post by dahart »

overgard wrote: post #74
dahart wrote: post #65

Earlier quoted context omitted.

A signed distance field approach is fundamentally incompatible with this library and it's goals. Zdog is a vector drawing library, it's resolution independent. When you render to SVG, you can later rasterize that SVG at any resolution. This lets you do things like print at large sizes or high DPI. Ray marching is a raster (pixel based / resolution dependent) way to render.

> Zdog is a vector drawing library, it's resolution independent. When you render to SVG, you can later rasterize that SVG at any resolution. This lets you do things like print at large sizes or high DPI. Signed distance fields and ray marching are completely resolution independent... The only limit is your canvas size. You can emulate the exact same effects, plus some additional ones since you can blend the shapes. T…

> Signed distance fields and ray marching are completely resolution independent

That’s not what I meant. I expect you knew that. The output of ray marching is a resolution-dependent raster. The output of Zdog is a vector format image.

Ray marching doesn’t make sense in Zdog, because the output SVG is rasterized later, on demand, by your browser or printer, not by Zdog. You can’t do that with ray-marching, and that’s why these two ways of rendering are incompatible. It’s not just efficiency, putting ray marching in Zdog makes no sense.

Re: Zdog – Pseudo-3D JavaScript engine for Canvas and SVG

#80

Post by ehsankia »

dahart wrote: post #67
ehsankia wrote: post #66

Earlier quoted context omitted.

That makes sense, I'm just not used to constructors having side-effect, though I can imagine wanting to skip the extra step of adding it to the illustration. But wouldn't something like illustration.addRect({}) look better?

Don't constructors always have side effects? That's the only reason to have them. I wouldn't think of this as a side-effect though, think of it as a graph property. addTo is setting up a tree structure, the same way you might setup a linked list. Think of the addTo property as a pointer to the parent, rather than a side-effect. A doubly-linked list has two pointers per node, one for next node and one for previous. A…

> Don't constructors always have side effects?

The only side effect they should have is creating a new instance, no playing around with some other object's hierarchy.

> think of it as a graph property. addTo is setting up a tree structure

The problem is that the hierarchy here is backwards. You usually add children to the parent, not parent to the children. Having a link back to your parent does help with navigating, but it shouldn't be how you "build" the tree.

When building a tree, do you think of it as building from children up to the parent? I did see that addChild was a thing, and that makes much more sense to me.

Post reply on HN