hodapp/blag
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Procedural meshes post: more rambling on POV-Ray

Browse Source
This commit is contained in:
Chris Hodapp 2021-08-10 12:33:12 -04:00
parent 68e1b3c3a2
commit be54e20811
1 changed files with 36 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
content/posts/2021-07-27-procedural-meshes/index.org
View File

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