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

Add some more writing to procedural-meshes post

Browse Source
This commit is contained in:
Chris Hodapp 2021-08-08 00:20:21 -04:00
parent 45c31eec27
commit 99a68b246f
1 changed files with 57 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -54,35 +54,71 @@ ever, for introducing me to it awhile ago). See also [[https://kronpano.github.
However, at some point I realized they weren't exactly what I wanted.
Structure Synth lets you combine together 3D primitives to build up a
more complex scene - but doesn't try to properly handle any sort of
*joining* of these primitives in a way that respects many of the
/joining/ of these primitives in a way that respects many of the
'rules' of geometry that are necessary for a lot of tools, like having
a well-defined inside/outside, not being self-intersecting, being
manifold, and so forth.
Here are a few images from an hour or two of my dabbling in Structure
Synth - one Blender screenshot, and two [[https://appleseedhq.net/][appleseed]] renders from when I
was trying to work with it:
{{< gallery >}}
{{< figure resource="structure-synth-mesh.png">}}
{{< figure page="images" resource="placeholder/appleseed_spiral_thing2.jpg">}}
{{< figure page="images" resource="placeholder/appleseed_spiral_thing.jpg">}}
{{< /gallery >}}
That's a "Hello World" tier design I try out when something gives me
geometric transforms and recursion. The first image (the Blender one)
snhould show the bits of unconnected and half-connected and
self-intersecting geometry - that is what I wanted to work around.
You can look at this and say, "That really makes no difference, and
Structure Synth is capable of anything you /practically/ want to
create, but you're just searching for something to nitpick and
complain about so that you have a justification for why you reinvented
it badly," and you're probably more right than wrong, but you're also
still reading, so the joke's on you.
Tools like [[https://openscad.org/][OpenSCAD]], based on [[https://www.cgal.org/][CGAL]], handle the details of this, and I
suspect that [[https://www.opencascade.com/][Open CASCADE]] (thus [[https://www.freecadweb.org/][FreeCAD]]) also does. In CAD work, it's
crucial. I experimented with similar recursive systems with some of
these, but I quickly ran into a problem: they were made for actual
practical applications in CAD, not so much for my generative art, and
they scaled quite poorly with the sort of recursion I was asking for.
crucial. Here's something similar I threw together in OpenSCAD with
the help of some automatically generated code:
Implicit surfaces (or one of the many related-but-not-identical things
around this, e.g. [[https://en.wikipedia.org/wiki/Function_representation][F-Reps]] or distance bounds or [[https://en.wikipedia.org/wiki/Signed_distance_function][SDFs]] or isosurfaces)
handle almost all of this well! They express [[https://en.wikipedia.org/wiki/Constructive_solid_geometry][CSG]] operations, they can
be rendered directly on the GPU via shaders, operations like blending
shapes or twisting them are easy... for more on this, see [[http://blog.hvidtfeldts.net/][Syntopia]]
again, or nearly anything by [[https://iquilezles.org/][Inigo Quilez]], or look up raymarching and
sphere tracing, or see [[https://ntopology.com/][nTopology]], or Matt Keeter's work with [[https://www.libfive.com/][libfive]]
and [[https://www.mattkeeter.com/research/mpr/][MPR]]. They're pure magic, they're wonderfully elegant, and I'll
probably have many other posts on them. (TODO: Link to my CS6460
stuff)
{{< gallery >}}
{{< figure resource="openscad-mesh.png">}}
{{< figure resource="openscad-mesh2.png">}}
{{< /gallery >}}
In the second image you can see how it properly handled intersecting
geometry, and facetizing the curve I purposely stuck in there. The
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.
But wait! Implicit surfaces handle almost all of this well! (Or call
them one of the many related-but-not-identical things around this,
e.g. [[https://en.wikipedia.org/wiki/Function_representation][F-Reps]] or distance bounds or [[https://en.wikipedia.org/wiki/Signed_distance_function][SDFs]] or isosurfaces...) They express
[[https://en.wikipedia.org/wiki/Constructive_solid_geometry][CSG]] operations, they can be rendered directly on the GPU via shaders,
operations like blending shapes or twisting them are easy... for more
on this, see [[http://blog.hvidtfeldts.net/][Syntopia]] again, or nearly anything by [[https://iquilezles.org/][Inigo Quilez]], or
look up raymarching and sphere tracing, or see [[https://ntopology.com/][nTopology]], or Matt
Keeter's work with [[https://www.libfive.com/][libfive]] and [[https://www.mattkeeter.com/research/mpr/][MPR]]. They're pure magic, they're
wonderfully elegant, and I'll probably have many other posts on them.
(TODO: Link to my CS6460 stuff)
However, there is one big issue: turning implicit surfaces to good
meshes for rendering /is a huge pain/, and while many renderers can
meshes for rendering /is a huge pain/. While many renderers can
handle implicit surfaces directly, Blender's renderers cannot. I will
have other posts going into more detail on this subject, but for now,
take it on faith. This is why I did not try to use implicit surfaces
for this project. (TODO: Make those posts.)
take it on faith. If you don't believe me, believe Matt Keeter in
[[https://www.mattkeeter.com/research/mpr/keeter_mpr20.pdf][his paper]] when he says in a rather understated way, "Having implemented
many of these algorithms, we've found it extremely difficult to make
them robust." This is why I did not try to use implicit surfaces for
this project.
(TODO: Make those posts.)
With these limitations in mind, around 2018 June I had started jotting
some ideas down. The gist is that I wanted to create
@ -131,6 +167,9 @@ shaders)
(TODO: Maybe split these off into sections for each one? That'd make
explanations/pictures easier.)
(TODO: The whole blog post is about my meandering path and should
probably include some Structure Synth things as part of this)
I put some serious effort into [[https://github.com/Hodapp87/prosha][Prosha]] and was conflicted on shelving
the project indefinitely, but the issues didn't look easily solvable.
Part of those issues were implementation issues with Rust - not that