85 lines
3.7 KiB
Markdown
85 lines
3.7 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
|
|
- 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
|
|
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?
|