To-do items, wanted features, bugs:
Cool
- More complicated: Examples of merging. I'm not sure on the theory behind this.
Annoying/boring
- https://en.wikipedia.org/wiki/Polygon_triangulation - do this to fix my wave example!
- 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.)
- 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,
despite larger numbers of them? Is it something in how I
twist the frames?
- How can I compute the torsion on a quad? I think it comes down to this: torsion applied across the quad I'm triangulating leading to neither diagonal being a particularly good choice. Subdividing the boundary seems to help, but other triangulation methods (e.g. turning a quad to 4 triangles by adding the centroid) could be good too.
- Facets/edges are just oriented the wrong way...
- Picking at random the diagonal on the quad to triangulate with 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 spiral isosurface stuff from here
Abstractions
-
This has a lot of functions parametrized over a lot of functions. Need to work with this somehow. (e.g. should it subdivide this boundary? should it merge opening/closing boundaries?)
-
Some generators produce boundaries that can be directly merged and produce sensible geometry. Some generators produce boundaries that are only usable when they are further transformed (and would produce degenerate geometry). What sort of nomenclature captures this?
-
How can I capture the idea of a group of parameters which, if they are all scaled in the correct way (some linearly, others inversely perhaps), generated geometry that is more or less identical except that it is higher-resolution?
-
Use mixins to extend 3D transformations to things (matrices, cages, meshes, existing transformations)
-
I can transform a Cage. Why not a CageGen?
????
- Embed this in Blender?
Future thoughts
- What if I had a function that could generate a Cage as if from a parametric formula and smoothly vary its orientation? My existing tools could easily turn this to a mesh. If I could vary the detail of the Cage itself (if needed), then I could also generate a mesh at an arbitrary level of detail simply by sampling at finer and finer points on the parameter space. (This might also tie into the Parallel Transport work.)
- What are the limitations of using Cages?
- Current system is very "generative". Could I do basically L-system if I have rules for how a much is refined? What about IFS?
- Do this in Rust once I understand WTF I am doing
Other thoughts
- Why do I never use the term "extruding" to describe what I'm doing?