From e3335c7272974897ffffc6e7cd31a29fcf4355d4 Mon Sep 17 00:00:00 2001 From: Chris Hodapp Date: Mon, 26 Jul 2021 22:03:30 -0400 Subject: [PATCH] Add more draft scraps for writing --- draft.org | 70 ++++++++++++++++++++------------ implicit.org | 22 ++++++++++ python_extrude_meshgen/README.md | 22 +++++----- 3 files changed, 78 insertions(+), 36 deletions(-) create mode 100644 implicit.org diff --git a/draft.org b/draft.org index 2f1e970..e7d1b84 100644 --- a/draft.org +++ b/draft.org @@ -21,12 +21,14 @@ (TODO: a note to me, reading later: you don't need to give your entire life story here.) + (TODO: pictures will make this post make a *lot* more sense) + Context Free is one of my favorite projects since I discovered it about 2010. It's one I've written about before (TODO: link to my posts), played around in (TODO: link to images), presented on, as - well as re-implemented myself in different ways (TODO: link to - contextual). That is sometimes because I wanted to do something - different, such as make it realtime and interactive, and sometimes + well as re-implemented myself in different ways (see: [[https://github.com/hodapp87/contextual][Contextual]]). + That is sometimes because I wanted to do something Context Free + couldn't, such as make it realtime and interactive, and sometimes because implementing its system of recursive grammars and replacement rules can be an excellent way to learn things in a new language. @@ -36,19 +38,20 @@ led me to learn about things like implicit surfaces, parametric surfaces, and procedural geometry - its scene language is full of constructs for that. Naturally, this led me to wonder how I might - extend Context Free's model to work more generally with 3D geometry. + extend Context Free's model to work more generally with 3D geometry, + and let me use it to produce procedural geometry. - [[http://structuresynth.sourceforge.net/index.php][Structure Synth]] of course already exists (thank you to Mikael + [[http://structuresynth.sourceforge.net/index.php][Structure Synth]] of course already exists as a straightforward + generalization of Context Free's model to 3D (thank you to Mikael Hvidtfeldt Christensen's blog [[http://blog.hvidtfeldts.net/][Syntopia]], another of my favorite - things ever), and so does [[https://kronpano.github.io/BrowserSynth/][BrowserSynth]], and they're excellent tools - that are straightforward generalizations of Context Free to 3D. - However, at some point I realized they weren't exactly what I - wanted. These tools let you combine together 3D primitives to build - up a more complex scene - but they don't properly handle any sort of - *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. + things ever, for introducing me to it awhile ago). See also + [[https://kronpano.github.io/BrowserSynth/][BrowserSynth]]. 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 '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. 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, @@ -63,17 +66,34 @@ distance bounds or SDFs or isosurfaces) handle almost all of this well! They express CSG (TODO: link to CSG) operations, blending shapes is easy, and they can be rendered directly on the GPU... see - Syntopia (again), or nearly anything by Inigo Quilez (TODO: link to - this), or look up raymarching, or look up sphere tracing, or see - nTopology (TODO: link), or libfive and Keeter's research paper - (TODO: link). It's pure magic and it's elegant. + [[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]]. It's pure magic and it's wonderfully + elegant and I'll probably have many other posts on this. - This is except for one big problem: converting them to good meshes - is a pain. None of my attempts have ever quite worked. + However, implicit surfaces still have one pretty big problem: + converting them to good meshes for rendering /is a huge pain/. I + have other posts on this as well, but for now, take it on faith. + (TODO: Make those posts.) - ----- - - So, with these limitations in mind, around 2018 June I had started + 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. - + "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 self-intersection, no high-degree vertices) - rather + than attempting to patch up the mesh after the fact, or subdivide it + to the necessary detail level. The form it took in my notes was in + sort of "growing" or "extruding" a mesh per these recursive rules, + building in these guarantees (some of them at least) by way of + inductive steps. + + (TODO: Illustrate this somehow) + + TODO while I'm not so tired: + + - Summarize from prosha: this didn't fully work + - Summarize from python_extrude_meshgen? + - Much much easier to OpenSubdiv it diff --git a/implicit.org b/implicit.org new file mode 100644 index 0000000..9ae5fa5 --- /dev/null +++ b/implicit.org @@ -0,0 +1,22 @@ +* Slush-pile from implicit rant + (TODO: This was shelved from another post. Do something with it.) + + None of my attempts have ever quite worked as soon as I start + dealing with implicit surfaces that have much sharpness to + them... which isn't saying much, since I am not exactly world-class + at dealing with meshes and mesh topology directly, but it's also + legitimately a very hard problem. Even when I tried in CGAL, which + can handle implicit surfaces and does a far better job at generating + "good" meshes than anything I could hope to write myself, the + problem I ran into is that it was generating good meshes for + industrial CAD, not good meshes for /rendering/. That is, their + inaccuracy to the true surface was bounded, and I could always + reduce it by just using denser meshes. For CAD applications, this + seems fine. For rendering, though, I kept running into some major + inefficiencies in terms of number of triangles required (and as well + the amount of time required). I don't know much about the algorithms + they use, but I am fairly sure that for detail level N (inversely + proportional to minimum feature size) both triangle count, time, and + likely memory usage grow with ~O(N^3)~. + + (TODO: Give an example of the above perhaps?) diff --git a/python_extrude_meshgen/README.md b/python_extrude_meshgen/README.md index b2cae41..38f678d 100644 --- a/python_extrude_meshgen/README.md +++ b/python_extrude_meshgen/README.md @@ -8,20 +8,20 @@ - https://en.wikipedia.org/wiki/Polygon_triangulation - do this to fix my wave example! - http://www.polygontriangulation.com/2018/07/triangulation-algorithm.html -- Clean up examples.ram_horn_branch(). The way I clean it up might +- Clean up `examples.ram_horn_branch()`. The way I clean it up might help inform some cleaner designs. - I really need to standardize some of the behavior of fundamental operations (with regard to things like sizes they generate). This is behavior that, if it changes, will change a lot of things that I'm trying to keep consistent so that my examples still work. -- Winding order. It is consistent through seemingly - everything, except for reflection and close_boundary_simple. - (When there are two parallel boundaries joined with something like - join_boundary_simple, traversing these boundaries in their actual order - to generate triangles - like in close_boundary_simple - will produce - opposite winding order on each. Imagine a transparent clock: seen from the - front, it moves clockwise, but seen from the back, it moves - counter-clockwise.) +- Winding order. It is consistent through seemingly everything, + except for reflection and `close_boundary_simple`. (When there are + two parallel boundaries joined with something like + `join_boundary_simple`, traversing these boundaries in their actual + order to generate triangles - like in `close_boundary_simple` - will + produce opposite winding order on each. Imagine a transparent clock: + seen from the front, it moves clockwise, but seen from the back, it + moves counter-clockwise.) - File that bug that I've seen in trimesh/three.js (see trimesh_fail.ipynb) - Why do I get the weird zig-zag pattern on the triangles, @@ -39,7 +39,7 @@ does seem to turn 'error' just to noise, and in its own way this is preferable. - Integrate parallel_transport work and reuse what I can -- /mnt/dev/graphics_misc/isosurfaces_2018_2019 - perhaps include my +- `/mnt/dev/graphics_misc/isosurfaces_2018_2019` - perhaps include my spiral isosurface stuff from here ## Abstractions @@ -81,4 +81,4 @@ ## Other thoughts -- Why do I never use the term "extruding" to describe what I'm doing? \ No newline at end of file +- Why do I never use the term "extruding" to describe what I'm doing?