97 lines
4.4 KiB
Markdown
97 lines
4.4 KiB
Markdown
# This needs a title
|
|
|
|
## Highest priority:
|
|
|
|
- Make a series of guidelines for *exactly* how to order
|
|
transformations so that I'm actually constructing things to be
|
|
correct instead of just throwing shit at the wall.
|
|
See my "Composing Transformations" link in log.org.
|
|
- Adaptive subdivision - which means having to generalize past some
|
|
`arg_vals` stuff.
|
|
- Try some non-deterministic examples.
|
|
- Get identical or near-identical meshes to `ramhorn_branch` from
|
|
Python. (Should just be a matter of tweaking parameters.)
|
|
- Look at performance.
|
|
- Start at `to_mesh_iter()`. The cost of small appends/connects
|
|
seems to be killing performance.
|
|
- `connect()` is a big performance hot-spot: 85% of total time in
|
|
one test, around 51% in `extend()`, 33% in `clone()`. It seems
|
|
like I should be able to share geometry with the `Rc` (like noted
|
|
above), defer copying until actually needed, and pre-allocate the
|
|
vector to its size (which should be easy to compute).
|
|
- See `automata_scratch/examples.py` and implement some of the tougher
|
|
examples.
|
|
- `twisty_torus`, `spiral_nested_2`, & `spiral_nested_3` are all
|
|
that remain. To do them, I need to compose transformations (not
|
|
in the matrix sense), but I also probably need to produce
|
|
RuleEvals which always have `xf` of identity transformation since
|
|
the Python code does not 'inherit' transforms unless I tell it to.
|
|
|
|
## Important but less critical:
|
|
|
|
- Elegance & succinctness:
|
|
- Clean up `ramhorn_branch` because it's ugly.
|
|
- What patterns can I factor out? I do some things regularly, like:
|
|
the clockwise boundaries, the zigzag connections.
|
|
- Declarative macro to shorten this `Tag::Parent`, `Tag::Body`
|
|
nonsense - and perhaps force to groups of 3? Does this have any
|
|
value, though, over just making helper functions like `p(...)` and
|
|
`b(...)`?
|
|
- I'm near certain a declarative macros can simplify some bigger
|
|
things like my patterns with closures (e.g. the Y combinator like
|
|
method for recursive calls).
|
|
- Docs on modules
|
|
- Compute global scale factor, and perhaps pass it to a rule (to
|
|
eventually be used for, perhaps, adaptive subdivision)
|
|
- swept-isocontour stuff from
|
|
`/mnt/dev/graphics_misc/isosurfaces_2018_2019/spiral*.py`. This
|
|
will probably require that I figure out parametric curves
|
|
- Make an example that is more discrete-automata, less
|
|
approximation-of-space-curve.
|
|
|
|
- Catch-alls:
|
|
- Grep for all TODOs in code, really.
|
|
- Look at everything in `README.md` in `automata_scratch`.
|
|
|
|
## If I'm bored:
|
|
|
|
- Fix links in tri_mesh docs that use relative paths & do a PR?
|
|
- Look in https://www.nalgebra.org/quick_reference/# for "pour
|
|
obtain". Can I fix this somehow? Looks like a French-ism that made
|
|
its way in.
|
|
- Multithread! This looks very task-parallel anywhere that I branch.
|
|
- Would being able to name a rule node (perhaps conditionally under
|
|
some compile-time flag) help for debugging?
|
|
- Use an actual logging framework.
|
|
- Take a square. Wrap it around to a torus. Now add a twist (about
|
|
the axis that is normal to the square). This is simple, but it looks
|
|
pretty cool.
|
|
- How can I take tangled things like the cinquefoil and produce more
|
|
'iterative' versions that still weave around?
|
|
|
|
## Research Areas
|
|
|
|
- When I have an iterated transform, that is basically transforming by
|
|
M, MM=M^2, MMM=M^3, ..., and it seems to me that I should be able to
|
|
compute its eigendecomposition and use this to compute fractional
|
|
powers of the matrix. Couldn't I then determine the continuous
|
|
function I'm approximating by taking the `d/di (M^i)V` - i.e. the
|
|
partial derivative of the result of transforming a vector `V` with
|
|
`M^i`? (See also:
|
|
https://en.wikipedia.org/wiki/Eigendecomposition_of_a_matrix#Functional_calculus
|
|
and my 2020-04-20 paper notes. My 2020-04-24 org notes have some
|
|
things too - this relates to dynamical systems and eigenvalues.)
|
|
Later note: I have a feeling I was dead wrong about a bunch of this.
|
|
|
|
## Reflections
|
|
|
|
- My old Python version composed rules in the opposite order and I
|
|
think this made things more complicated. I didn't realize that I
|
|
did it differently in this code, but it became much easier -
|
|
particularly, more "inner" transformations are much easier to write
|
|
because all that matters is that they work properly in the
|
|
coordinate space they inherit.
|
|
- Generalizing to space curves moves this away from the "discrete
|
|
automata" roots, but it still ends up needing the machinery I made
|
|
for discrete automata.
|