4 ms·

> 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 th

> 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/ 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.

dahart 7y ago
> 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.
- overgard 7y ago
  That's kinda a weirdly accusatory tone dude. If the output is the screen, which it probably would be 99.9% of the time since this is a javascript library creating a 3d object in a browser, then the distinction is entirely academic. Just set the canvas size to whatever you want. After all the output of displaying an SVG on a screen is also a resolution dependent raster, as is the output of plotting ink on a piece of paper. Also I wasn't like saying this was a useless library, just that if z-fighting was a concern there's an alternative using GPU shaders that can get you a very similar effect. Geez.
  - dahart 7y ago
    I’m sorry, I didn’t mean to accuse you of anything, my intention was to give you the benefit of the doubt that you understand all the issues here; you sound like you know what you’re talking about with SVG & ray marching. This distinction is very much practical and not academic. SVG exists for a reason. I use (and write) SVG renderers in practice precisely for their resolution-independent, rasterize-on-demand functionality. > Just set the canvas size to whatever you want. This is missing the point that an SVG output can rasterize to multiple different resolutions, when it’s viewed, where a ray-marching output is baked at one size. > If the output is the screen, which is probably would be 99.9% of the time I would counter with most SVG on the web today is served as files, and a major use case of Zdog would be creating those files, not necessarily including Zdog in the js and rendering everything from scratch at display time. Rendering to files allows Zdog output to work on all browsers that support SVG, which from the comments appears to be more browsers than Zdog can run on. I was thinking specifically of the case where I render files in Zdog and save them for display & print later. It’s restrictive to assume that you’re rendering & rasterizing at the same time, one of the benefits of rendering to SVG is being able to separate rendering from rasterizing. That part of the discussion doesn’t change the fact that Zdog renders to SVG and ray marching renders to pixels, so they aren’t compatible rendering techniques unless you change Zdog to only rasterize it’s output and disable SVG.
    - overgard 7y ago
      Ray marching isn't baked at all, it's a webgl canvas. It's a real time effect. If you resize it the resolution changes and you re-render. The shapes that are used as a source for the rendering are all mathematical objects that can be combined and used at any scale, just like paths and curves in an SVG. The only time it would be "baked" is if you're exporting it out of the browser. > This distinction is very much practical and not academic. SVG exists for a reason. I use (and write) SVG renderers in practice precisely for their resolution-independent, rasterize-on-demand functionality. I wrote an SVG renderer: https://github.com/fathat/glsvg https://github.com/fathat/glsvg > I was thinking specifically of the case where I render files in Zdog and save them for display & print later. If you lose the interactive 3d component, Z-Dog doesn't really give you anything over just drawing it in a vector art program. Actually it gives you less, because you have less control and you have to type out your shapes instead of just drawing them. And it's not like it's easy to export out of the browser. In chrome at least, if it renders to a canvas and you right click on the element to save it you get a png, and if it renders into an SVG you get the option to save the entire web page. Anyway all I was suggesting is that if you want a similar rendering effect (IE, 3D objects without triangulation) and z-fighting is an issue for you then you can consider signed depth fields. That's all. If z-dog works for your purposes use it instead.

dahart 7y ago

> 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.

overgard 7y ago
That's kinda a weirdly accusatory tone dude. If the output is the screen, which it probably would be 99.9% of the time since this is a javascript library creating a 3d object in a browser, then the distinction is entirely academic. Just set the canvas size to whatever you want. After all the output of displaying an SVG on a screen is also a resolution dependent raster, as is the output of plotting ink on a piece of paper. Also I wasn't like saying this was a useless library, just that if z-fighting was a concern there's an alternative using GPU shaders that can get you a very similar effect. Geez.
- dahart 7y ago
  I’m sorry, I didn’t mean to accuse you of anything, my intention was to give you the benefit of the doubt that you understand all the issues here; you sound like you know what you’re talking about with SVG & ray marching. This distinction is very much practical and not academic. SVG exists for a reason. I use (and write) SVG renderers in practice precisely for their resolution-independent, rasterize-on-demand functionality. > Just set the canvas size to whatever you want. This is missing the point that an SVG output can rasterize to multiple different resolutions, when it’s viewed, where a ray-marching output is baked at one size. > If the output is the screen, which is probably would be 99.9% of the time I would counter with most SVG on the web today is served as files, and a major use case of Zdog would be creating those files, not necessarily including Zdog in the js and rendering everything from scratch at display time. Rendering to files allows Zdog output to work on all browsers that support SVG, which from the comments appears to be more browsers than Zdog can run on. I was thinking specifically of the case where I render files in Zdog and save them for display & print later. It’s restrictive to assume that you’re rendering & rasterizing at the same time, one of the benefits of rendering to SVG is being able to separate rendering from rasterizing. That part of the discussion doesn’t change the fact that Zdog renders to SVG and ray marching renders to pixels, so they aren’t compatible rendering techniques unless you change Zdog to only rasterize it’s output and disable SVG.
  - overgard 7y ago
    Ray marching isn't baked at all, it's a webgl canvas. It's a real time effect. If you resize it the resolution changes and you re-render. The shapes that are used as a source for the rendering are all mathematical objects that can be combined and used at any scale, just like paths and curves in an SVG. The only time it would be "baked" is if you're exporting it out of the browser. > This distinction is very much practical and not academic. SVG exists for a reason. I use (and write) SVG renderers in practice precisely for their resolution-independent, rasterize-on-demand functionality. I wrote an SVG renderer: https://github.com/fathat/glsvg https://github.com/fathat/glsvg > I was thinking specifically of the case where I render files in Zdog and save them for display & print later. If you lose the interactive 3d component, Z-Dog doesn't really give you anything over just drawing it in a vector art program. Actually it gives you less, because you have less control and you have to type out your shapes instead of just drawing them. And it's not like it's easy to export out of the browser. In chrome at least, if it renders to a canvas and you right click on the element to save it you get a png, and if it renders into an SVG you get the option to save the entire web page. Anyway all I was suggesting is that if you want a similar rendering effect (IE, 3D objects without triangulation) and z-fighting is an issue for you then you can consider signed depth fields. That's all. If z-dog works for your purposes use it instead.