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

> You are assuming Zdog is limited and can only be used interactively in practice.

Well, it is pretty limited, by design, in terms of possible constructions you can make with it. I would not call it a general purpose tool. As far as I can tell it doesn't even have an export function, you'd have to scrape the SVG data out of the tag yourself. (might be wrong, haven't closely looked at the api, just went through the examples)

> Zdog & SVG is two-pass and there's an intermediate 2d resolution independent representation.

I realize this, but there are reasons why I think this is of niche utility:

- The constructions I can make are limited; IE, this isn't a general purpose tool. It's mostly a neat toy. To me, for it to be a general purpose tool it'd need to be able to handle intersecting objects properly and it fundamentally cannot do this. I like it as a neat toy, that's not a criticism! It's good at being what it is. I just think that you can do more with other techniques, if you want to do more.

- Yes SVG is a useful format, but there are some downsides to rendering a 3d scene into an SVG: specifically, now you have to parse and interpret that data before you can even display it. That's definitely not computationally trivial. Also, having written things that render vector graphics, I can tell you that rendering vector graphics on 3d hardware is extremely hard to do efficiently. Either you need to tessellate into very high polygon meshes, or ignore the GPU entirely and do it in software on the CPU (slow!), or use much more obscure methods. I'm sure the clever people working on Chrome have done this well, but the point still stands that SVGs aren't some magical way to make graphics fast. What they're very good at is being resolution independent. Ironically, one of the more cutting edge ways to try to rasterize vector graphics faster is: ... by using signed distance fields :-) (Look up how Valve renders fonts, for instance)

- If you're saying that SVGs are more space efficient in this context then rasterized graphics, maybe, but I'd point out that even with a huge image we're talking about very few colors (in this style). You could store it in an 8bit png with extremely good lossless compression.

Presumably updateGraph() and even render() can both tidy up linkages and anything else that needs updating. The shape constructor might well have a side-effect though, I don't know.

Hey I hear your point, this API is a little bit different. Maybe since it's early your feedback is fully justified. Just from my perspective it didn't strike me as "very strange", only perhaps a little bit. I don't think you're wrong, it's just a matter of degree... which is subjective anyway, so take this as lukewarm agreement with you. :)

Perhaps if you want to stay truer to the spirit of the system, then you might have zDog generate faux depth buffers for each of its shapes (using gradients when necessary).

Then you might still take advantage of Chrome’s “optimized” SVG rasterization, but also use the GPU to do depth compositing on the color buffer afterward. As a bonus, depth-fade intersection shaders could work (which are tricky with raymarching).