3 ms·

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 us

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.
- overgard 7y ago
  I think our fundamental disagreement here is that I think the main use for this is interactive graphics, and that's how it seems to be marketed, and you seem to think its main utility is as an art tool for generating SVGs. I personally think it would be a pretty awkward way to generate an SVG compared to the alternatives, since pulling the data out of the browser requires using dev tools or saving the entire pages' HTML, and if you don't care about being able to move a camera around then it's probably quicker just to draw what you want in inkscape. But if you want an interactive 3d thing and you don't care about self-intersecting objects than this is fine. > 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. Hours is really misrepresenting things. It's not ray tracing. It takes milliseconds. You can do it hundreds of times per second, with scenes that are vastly more rich and complicated than this can do. > 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. Huh? That's a really weird distinction to make. Unless you mean "rendering" in the sense that web-devs often use it for writing tags, rasterizing and rendering are essentially the same thing. You have data and you need to convert it into pixels or blotches of ink. If you insist on thinking of "rendering" as having a definition of the scene, then the shader you would have which defines the shapes would essentially be the "rendering". In fact it'd look very similar to the javascript, other than being written in glsl. If I needed a ray marched scene on very fancy glossy printed paper I'd just rasterize it on a really big canvas and print that. It would take about ten milliseconds to generate that image. > Your straw man hypothetical eliminated all of Zdog’s functionality there. Not at all. It's perfectly fine if you want pseudo 3d in a browser. But a lot of people don't like depth sorting artifacts (I am among them). Not being able to intersect objects creates a very strict limit on what you can do. That's fine, but if you want something more flexible I was just mentioning that there's an alternative. I don't know why you're pushing back so hard on my suggestion that, specifically, if you want a 3d scene in a browser that has fewer limitations you can do that in an alternative way. You don't HAVE to. There are trade-offs. I just suggested the possibility. Signed distance fields aren't as well known as svgs are so I thought people would be interested in the concept. > 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. I mean, if it provides value for you to create art in that way that's great, do whatever you want. But I'm pretty sure if I polled 99/100 artists that wanted to create a static SVG file, the last thing they'd want to do is write javascript to place each object and then use the browser's dev tools to pull their data out of the SVG tag. (Most of them wouldn't even know how to do that). I mean if you don't want an interactive scene then there's much more flexible ways to create an SVG. (+ You'll notice in most of their examples, they're rendering to a canvas anyway, kind of making my point) I guess my overall point is that if you're making something for print or you need a content authoring tool, you're probably using an entirely different set of tools, and if you're making something to be consumed in a browser, then whether you use SVG or a webgl canvas, you can achieve the same effect to the person viewing your content.

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.

overgard 7y ago
I think our fundamental disagreement here is that I think the main use for this is interactive graphics, and that's how it seems to be marketed, and you seem to think its main utility is as an art tool for generating SVGs. I personally think it would be a pretty awkward way to generate an SVG compared to the alternatives, since pulling the data out of the browser requires using dev tools or saving the entire pages' HTML, and if you don't care about being able to move a camera around then it's probably quicker just to draw what you want in inkscape. But if you want an interactive 3d thing and you don't care about self-intersecting objects than this is fine. > 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. Hours is really misrepresenting things. It's not ray tracing. It takes milliseconds. You can do it hundreds of times per second, with scenes that are vastly more rich and complicated than this can do. > 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. Huh? That's a really weird distinction to make. Unless you mean "rendering" in the sense that web-devs often use it for writing tags, rasterizing and rendering are essentially the same thing. You have data and you need to convert it into pixels or blotches of ink. If you insist on thinking of "rendering" as having a definition of the scene, then the shader you would have which defines the shapes would essentially be the "rendering". In fact it'd look very similar to the javascript, other than being written in glsl. If I needed a ray marched scene on very fancy glossy printed paper I'd just rasterize it on a really big canvas and print that. It would take about ten milliseconds to generate that image. > Your straw man hypothetical eliminated all of Zdog’s functionality there. Not at all. It's perfectly fine if you want pseudo 3d in a browser. But a lot of people don't like depth sorting artifacts (I am among them). Not being able to intersect objects creates a very strict limit on what you can do. That's fine, but if you want something more flexible I was just mentioning that there's an alternative. I don't know why you're pushing back so hard on my suggestion that, specifically, if you want a 3d scene in a browser that has fewer limitations you can do that in an alternative way. You don't HAVE to. There are trade-offs. I just suggested the possibility. Signed distance fields aren't as well known as svgs are so I thought people would be interested in the concept. > 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. I mean, if it provides value for you to create art in that way that's great, do whatever you want. But I'm pretty sure if I polled 99/100 artists that wanted to create a static SVG file, the last thing they'd want to do is write javascript to place each object and then use the browser's dev tools to pull their data out of the SVG tag. (Most of them wouldn't even know how to do that). I mean if you don't want an interactive scene then there's much more flexible ways to create an SVG. (+ You'll notice in most of their examples, they're rendering to a canvas anyway, kind of making my point) I guess my overall point is that if you're making something for print or you need a content authoring tool, you're probably using an entirely different set of tools, and if you're making something to be consumed in a browser, then whether you use SVG or a webgl canvas, you can achieve the same effect to the person viewing your content.