From be54e20811c4fe3de0e7a65f9cf5852edc6734ee Mon Sep 17 00:00:00 2001 From: Chris Hodapp Date: Tue, 10 Aug 2021 12:33:12 -0400 Subject: [PATCH] Procedural meshes post: more rambling on POV-Ray --- .../2021-07-27-procedural-meshes/index.org | 64 +++++++++++-------- 1 file changed, 36 insertions(+), 28 deletions(-) diff --git a/content/posts/2021-07-27-procedural-meshes/index.org b/content/posts/2021-07-27-procedural-meshes/index.org index 1d9745f..d1bdc83 100644 --- a/content/posts/2021-07-27-procedural-meshes/index.org +++ b/content/posts/2021-07-27-procedural-meshes/index.org @@ -40,15 +40,12 @@ about 1999 in PolyRay and POV-Ray... though my [[../../images/portfolio/1999-12- from 1999]] are mostly garbage. POV-Ray is probably what led me to learn about things like procedural geometry and textures, especially implicit surfaces and parametric surfaces, as its scene language is -full of constructs for that. The images below are some of my POV-Ray -scenes from way back in 2005, with the first two done completely with -its implicit surfaces. +full of constructs for that. Below is one of my procedural POV-Ray +scenes from experimenting back in 2005, and though I hadn't heard of +Context Free at that point (if it even existed) I was already trying +to do similar things in a sort of ad-hoc way. -{{< gallery >}} - {{< figure page="images" resource="portfolio/2005-07-05-spiral-isosurface2.jpg">}} - {{< figure page="images" resource="portfolio/2005-07-08-vaguely-celtic-metalwork.jpg">}} - {{< figure page="images" resource="portfolio/2005-08-23-shear6.jpg">}} -{{< /gallery >}} +{{< figure page="images" resource="portfolio/2005-08-23-shear6.jpg">}} Naturally, this led me to wonder how I might extend Context Free's model to work more generally with 3D geometry, and let me use it to @@ -105,7 +102,7 @@ mesh looks great, but I quickly ran into a problem: OpenSCAD scales pretty poorly with this level of complexity - and as far as that goes, this geometry is even fairly mild. This really isn't surprising, as tools like this were made for practical applications in CAD, and not -so much for my silly explorations in generative art. +so much for my silly explorations in procedural art. But wait! *Implicit surfaces* handle almost all of this well! (Or see any of the related-but-not-identical things around this, e.g. [[https://en.wikipedia.org/wiki/Function_representation][F-Reps]] @@ -121,17 +118,16 @@ Keeter's work with [[https://www.libfive.com/][libfive]] and [[https://www.mattk wonderfully elegant, and I'll probably have many other posts on them. (TODO: Link to my CS6460 stuff) -Many renderers can render implicit surfaces directly. POV-Ray is one -of them - see [[https://www.povray.org/documentation/view/3.6.1/300/][Isosurface Object]] which a few of my examples above -use. The appleseed renderer can sort of do it via a [[https://github.com/appleseedhq/appleseed/blob/master/sandbox/examples/cpp/distancefieldobject/distancefieldobject.cpp][custom object via -a plugin]]. [[https://www.shadertoy.com/][Shadertoy]] is also full of user-created examples of ad-hoc -realtime rendering of implicit surfaces, mostly in the form of sphere -tracers, done completely in [[https://en.wikipedia.org/wiki/OpenGL_Shading_Language][GLSL]]. Keeter's work on [[https://www.mattkeeter.com/research/mpr/][MPR]] is all about -realtime rendering of this sort in a much more scalable way. +Many renderers can render implicit surfaces directly. [[https://www.shadertoy.com/][Shadertoy]] is +full of user-created examples of ad-hoc realtime rendering of implicit +surfaces, mostly in the form of sphere tracers, done completely in +[[https://en.wikipedia.org/wiki/OpenGL_Shading_Language][GLSL]]. Keeter's work on [[https://www.mattkeeter.com/research/mpr/][MPR]] is all about realtime rendering of a +similar sort, but in a much more scalable way. The [[https://appleseedhq.net/][appleseed]] renderer +can do it via a [[https://github.com/appleseedhq/appleseed/blob/master/sandbox/examples/cpp/distancefieldobject/distancefieldobject.cpp][custom object via a plugin]]. POV-Ray, as mentioned +before, also handles them nicely with its [[https://www.povray.org/documentation/view/3.6.1/300/][Isosurface Object]]. That is +what I used below in yet another of my 2005 experiments: -# TODO: Why not move the spiral isosurface from POV-Ray here, and give -# its formula and explain a little? Or - should this be for another -# post? +{{< figure page="images" resource="portfolio/2005-07-05-spiral-isosurface2.jpg">}} Many renderers don't handle implicit surfaces at all. Blender's renderers, [[https://www.cycles-renderer.org/][Cycles]] and [[https://docs.blender.org/manual/en/latest/render/eevee/introduction.html][Eevee]], are among them. Using implicit surfaces @@ -140,24 +136,36 @@ handle - typically a polygon mesh. This leads to a pretty big issue: turning implicit surfaces to good meshes for rendering /is a huge pain/. If you don't believe me, -believe Matt Keeter in [[https://www.mattkeeter.com/research/mpr/keeter_mpr20.pdf][his paper]] when he says, "There is significant -literature on converting implicit surfaces into meshes for +believe Matt Keeter in [[https://www.mattkeeter.com/research/mpr/keeter_mpr20.pdf][his paper on MPR]] when he says, "There is +significant literature on converting implicit surfaces into meshes for visualization. Having implemented many of these algorithms, we've found it extremely difficult to make them robust." I'd love to tell you that I saw this advice before wasting my time trying to turn implicit surfaces to meshes, first with various libraries and then -with ad-hoc conversions and optimizations of my own, but I didn't. I -may have other posts talking about my failures here, but for now, take -it on faith that this is why I gave up trying to use implicit surfaces -for this project. (TODO: Make those posts.) +with ad-hoc conversions and optimizations of my own, but I didn't. +For comparison, POV-Ray raytraced the above example comfortably on a +machine with 512 MB of RAM, and that's at 4000x3000 resolution - while +I've had very limited success at turning this particular implicit +surface to a polygon mesh good enough to produce anywhere near a +comparable render, and that fits in 32 GB of RAM. + +I may have other posts talking about my failures here, but for now, +take it on faith: things like this are why I gave up trying to use +implicit surfaces for this project. (TODO: Make those posts.) + +# TODO: Perhaps make a note here on explicit vs. implicit, maybe try +# to explain generative/procedural/algorithmic/parametric? +# +# https://en.wikipedia.org/wiki/Parametric_equation#Computer-aided_design - +# note explicit vs. implicit vs. parametric. With these limitations in mind, around 2018 June I had started jotting some ideas down. The gist is that I wanted to create "correct-by-construction" meshes from these recursive grammars. By that, I meant: incrementally producing the desired geometry as a mesh, -triangle-by-triangle, in such a way that guaranteed that the resultant -mesh had the desired detail level, was a manifold surface, and that it -was otherwise a well-behaved mesh (e.g. no degenerate triangles, no +polygon-by-polygon, in such a way that guarantees that the resultant +mesh has the desired detail level, is a manifold surface, and that it +is otherwise a well-behaved mesh (e.g. no degenerate triangles, no self-intersection, no high-degree vertices, no triangles of extreme angles) - rather than attempting to patch up the mesh after its creation, or subdividing it to the necessary detail level. For