d26cece387
kludge-tacular, but working. some parts are painful, but I have the fundamental structure in place.
72 lines
3.2 KiB
Markdown
72 lines
3.2 KiB
Markdown
# To-do items, wanted features, bugs:
|
|
|
|
## Cool
|
|
- Examples of branching. This will probably need recursion via functions
|
|
(or an explicit stack some other way). If I simply
|
|
split a boundary into sub-boundaries per the rules I already
|
|
have in my notes, then this still lets me split any way I want
|
|
to without having to worry about joining N boundaries instead
|
|
of 2, doesn't it?
|
|
- Note that for this to work right, either gen2mesh has to be
|
|
called separately on every straight portion, or I have to
|
|
make a version of gen2mesh that can handle something more
|
|
like trees of boundaries, not just flat lists.
|
|
- 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!
|
|
- 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
|
|
|
|
## 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?
|
|
|