This’ll be interesting to talk through refactoring here.
What’ve I got now?
- Parameters
- Turning parameters into a tree or segment data structure
- Rendering trees or segments
- Saving and loading parameters
- Randomizing parameters
- Screenshots / animations
- Rendering the Sliders
- Rendering the HUD
- Rendering the reference image
Saving and loading parameters can move into the parameters class, except that it extends a TypedDict so no it can’t.
I can add a PrimaryVeins class which takes the parameters provides a method for rendering. The underlying data structure can be abstracted.
pv = PrimaryVeins(parameters)
pv.renderTo(surf)
in one direction
So whenever the parameters change I’ll just instantiate a new PrimaryVeins class.
…
Ahh. Much better after refactoring that out into a class and precalculating the position, direction, and length for each line segment. Previously I was doing half the calculations during the initialization phase (number of veins, number of generations) and the rest during render (position, direction, length). Now it’s much more manageable. Downside is the entire data structure needs to be recalculated whenever parameters change but I’m getting the better end of the deal in that trade-off. Parameter changes don’t happen anywhere near as often as renders.
That made it much easier to write code that does a breadth-first search with a segment accumulator so I can compare every segment against every other segment. Breadth-first will detect collisions sooner because veins are far more likely to collide with each other than with themselves.
Next I just need to add the actual code which takes two line segments and tests for a collision.