3 ms·

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 creati

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
    > I wrote an SVG renderer So, clearly you do understand the issues here. Which is why I’m a bit puzzled by your push-back here. When I said “baked” I was talking about ray-marching spitting out pixels at a certain resolution. Once you render, you can’t change the resolution without re-rendering, so the resolution is “baked” into the raster output. If I save it to a file, my only choice is to save an image file at the resolution that I rendered at. If I want to display that file at a different resolution later, and I don’t have the renderer, my only choice is to resample the image. > It’s a real time effect I don’t know what you mean here. Ray marching is a rendering technique, you can choose to do it in real time, or you can choose to take hours. This has no bearing on whether it renders to pixels or vector art. Zdog can also be real-time, or offline batch. > If you resize it the resolution changes and you re-render Yes, exactly. You have to re-render a ray-marched image if you change the resolution. That is unlike SVG, which you can re-rasterize without re-rendering. > The shapes that are used as a source for the rendering are all mathematical objects that can be combined an used at any scale, just like paths and curves in an SVG I feel like we’re regressing a bit here, we already covered this. Yes, the input SDF & scene certainly are resolution independent. You have to compare that to the input of Zdog, which is not SVG, it’s the 3d shape description. The output of ray marching is a raster. Zdog’s SVG output is, well, resolution independent SVG. > If you lose the interactive 3d component, Z-Dog doesn’t really give you anything over just drawing it in a vector art program. Your straw man hypothetical eliminated all of Zdog’s functionality there. You can use Zdog with 3d but without interactive, right? That’s one specific use case I’m interested in. What Zdog buys is a conversion from a 3d scene description to a 2d scene description, that’s the value for me, and the very thing that ray marching does not do.

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
  > I wrote an SVG renderer So, clearly you do understand the issues here. Which is why I’m a bit puzzled by your push-back here. When I said “baked” I was talking about ray-marching spitting out pixels at a certain resolution. Once you render, you can’t change the resolution without re-rendering, so the resolution is “baked” into the raster output. If I save it to a file, my only choice is to save an image file at the resolution that I rendered at. If I want to display that file at a different resolution later, and I don’t have the renderer, my only choice is to resample the image. > It’s a real time effect I don’t know what you mean here. Ray marching is a rendering technique, you can choose to do it in real time, or you can choose to take hours. This has no bearing on whether it renders to pixels or vector art. Zdog can also be real-time, or offline batch. > If you resize it the resolution changes and you re-render Yes, exactly. You have to re-render a ray-marched image if you change the resolution. That is unlike SVG, which you can re-rasterize without re-rendering. > The shapes that are used as a source for the rendering are all mathematical objects that can be combined an used at any scale, just like paths and curves in an SVG I feel like we’re regressing a bit here, we already covered this. Yes, the input SDF & scene certainly are resolution independent. You have to compare that to the input of Zdog, which is not SVG, it’s the 3d shape description. The output of ray marching is a raster. Zdog’s SVG output is, well, resolution independent SVG. > If you lose the interactive 3d component, Z-Dog doesn’t really give you anything over just drawing it in a vector art program. Your straw man hypothetical eliminated all of Zdog’s functionality there. You can use Zdog with 3d but without interactive, right? That’s one specific use case I’m interested in. What Zdog buys is a conversion from a 3d scene description to a 2d scene description, that’s the value for me, and the very thing that ray marching does not do.