87 lines
4.0 KiB
Markdown
87 lines
4.0 KiB
Markdown
# To-do items, wanted features, bugs:
|
|
|
|
## Cool
|
|
- More complicated: Examples of *merging*. I'm not sure on the theory
|
|
behind this.
|
|
|
|
## Annoying/boring
|
|
- Fix non-manifold bug at branch. (The edges must be *shared*. It is
|
|
not sufficient that the subdivided edges both lie incident on some
|
|
other edge and cover it completely. You must subdivide that larger
|
|
edge, and thus the triangle it lies on.)
|
|
- See cage.py and CageGen.to_mesh
|
|
- CageFork may need to supply some 'opening' cage that I use as
|
|
a basis for how I subdivide a 'closing' cage. If I subdivide
|
|
the closing cage, then I must triangulate *after*, not before.
|
|
- classify_overlap might be unnecessary, but its classification may
|
|
have the right idea.
|
|
- https://en.wikipedia.org/wiki/Polygon_triangulation - do this to
|
|
fix my wave example!
|
|
- http://www.polygontriangulation.com/2018/07/triangulation-algorithm.html
|
|
- 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)
|
|
|
|
## ????
|
|
- 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?
|