Misc refactor & notes update
This commit is contained in:
parent
4fe289083b
commit
0d0bed918a
35
README.md
35
README.md
@ -12,32 +12,33 @@
|
||||
## Important but less critical:
|
||||
|
||||
- Elegance & succinctness (my recent closure work may help with this):
|
||||
- Why must I repeat myself so much in these definitions?
|
||||
- What patterns can I factor out? I do some things regularly, like:
|
||||
the clockwise boundaries, the zigzag connections
|
||||
- Procedural macro to shorten this `Tag::Parent`, `Tag::Body`
|
||||
nonsense - and perhaps force to groups of 3?
|
||||
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
|
||||
- Grep for all TODOs in code, really.
|
||||
- Look at performance. Can I save on copies of geometry by using
|
||||
`Rc<OpenMesh>` or the like? In many cases I have nothing but copied
|
||||
geometry. Can I pre-allocate vectors instead of
|
||||
extending/appending?
|
||||
- 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).
|
||||
- The cost of small appends/connects seems to be killing
|
||||
performance.
|
||||
- Look at everything in `README.md` in `automata_scratch`.
|
||||
- Use an actual logging framework.
|
||||
- Migrate tests to... well... actual tests.
|
||||
- I am starting to see a pattern emerge in how I have to modularize
|
||||
things around closures. What can a macro do for me here?
|
||||
- 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`
|
||||
|
||||
- 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?
|
||||
@ -47,3 +48,5 @@
|
||||
- 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.
|
||||
- Migrate tests to... well... actual tests.
|
||||
|
||||
@ -126,7 +126,8 @@ fn twist(f: f32, subdiv: usize) -> Rule<()> {
|
||||
|
||||
// Generate 'count' children, shifted/rotated differently:
|
||||
let inner = (0..count).map(|i| child(incr_inner, dx0, i, 0.0, 1.0));
|
||||
let outer = (0..count).map(|i| child(incr_outer, dx0*2.0, i, qtr/2.0, 2.0));
|
||||
//let outer = (0..count).map(|i| child(incr_outer, dx0*2.0, i, qtr/2.0, 2.0));
|
||||
let outer = (0..0).map(|i| child(incr_outer, dx0*2.0, i, qtr/2.0, 2.0));
|
||||
|
||||
RuleEval::from_pairs(inner.chain(outer), prim::empty_mesh())
|
||||
};
|
||||
@ -276,13 +277,13 @@ struct RamHornCtxt {
|
||||
depth: usize,
|
||||
}
|
||||
|
||||
fn ramhorn_branch(depth: usize) -> Rule<RamHornCtxt> {
|
||||
fn ramhorn_branch(depth: usize, f: f32) -> Rule<RamHornCtxt> {
|
||||
|
||||
let v = Unit::new_normalize(Vector3::new(-1.0, 0.0, 1.0));
|
||||
let incr: Transform = Transform::new().
|
||||
translate(0.0, 0.0, 0.8).
|
||||
rotate(&v, 0.4).
|
||||
scale(0.95);
|
||||
translate(0.0, 0.0, 0.8 * f).
|
||||
rotate(&v, 0.4 * f).
|
||||
scale(1.0 - (1.0 - 0.95)*f);
|
||||
|
||||
let seed = vec![
|
||||
vertex(-0.5, -0.5, 0.0),
|
||||
@ -427,12 +428,7 @@ fn ramhorn_branch(depth: usize) -> Rule<RamHornCtxt> {
|
||||
let start = move |self_: Rc<Rule<RamHornCtxt>>| -> RuleEval<RamHornCtxt> {
|
||||
RuleEval {
|
||||
geom: Rc::new(OpenMesh {
|
||||
verts: vec![
|
||||
vertex(-0.5, -0.5, -0.5),
|
||||
vertex(-0.5, 0.5, -0.5),
|
||||
vertex( 0.5, 0.5, -0.5),
|
||||
vertex( 0.5, -0.5, -0.5),
|
||||
],
|
||||
verts: Transform::new().translate(0.0, 0.0, -0.5).transform(&seed),
|
||||
faces: vec![
|
||||
Tag::Body(0), Tag::Body(1), Tag::Body(2),
|
||||
Tag::Body(0), Tag::Body(2), Tag::Body(3),
|
||||
@ -613,12 +609,13 @@ pub fn main() {
|
||||
// some sort of numerical precision issue.
|
||||
|
||||
//run_test_iter(Twist::init(1.0, 2), 100, "twist");
|
||||
// This is a stress test:
|
||||
// let f = 20;
|
||||
// run_test_iter(Twist::init(f as f32, 32), 100*f, "twist2");
|
||||
|
||||
run_test(&Rc::new(cube_thing()), 3, "cube_thing3", false);
|
||||
run_test(&Rc::new(twist(1.0, 2)), 200, "twist", false);
|
||||
run_test(&Rc::new(ramhorn()), 100, "ram_horn3", false);
|
||||
run_test(&Rc::new(ramhorn_branch(6)), 31/*42*/, "ram_horn_branch", false);
|
||||
run_test(&Rc::new(ramhorn_branch(24, 0.25)), 32/*128*/, "ram_horn_branch", false);
|
||||
|
||||
// This is a stress test:
|
||||
//let f = 40;
|
||||
//run_test(&Rc::new(twist(f as f32, 128)), 100*f, "screw", false);
|
||||
}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user