I think I want to gather up a flat list of Segments. Accumulate them even.
Aha. I have a problem because I never actually store the endpoints of the line segment anywhere. I traverse the tree and render them on the fly. So I’m gonna need a new data structure for my accumulator.
Looks like it’s actually better if I maintain the line segment start position and its direction and length (just another vector) rather than its endpoints. At least for the collision detection algorithm I plucked from Stack Overflow. https://stackoverflow.com/a/1968345used randomization to
I’m uncomfortable calling it a position and direction because usually I consider direction to be a unit vector but. A quick search online seems to support this convention. So it’s a position and a vector?
My code is starting to get a little hairy.
I was writing it up so that the segment render function and the collision detection function would have a lot of wet code. Maybe a better way is to, well, let’s draw it.
This is what I was working toward right now. The drawing parameters are already used to generate a tree data structure. That data structure is used to render the primary veins.
So I was going to add collision detection which also traverses the tree, but it needs a flat list of segments in an accumulator so I started introducing that.
I guess really it’s more like this:
But when rendering it doesn’t matter if it’s working from a tree or a list of segments, so what I probably want instead is:
I don’t gain any benefit from maintaining the tree data structure right now. I can store some tree information on each segment, for example the segment’s generation in the tree.
git stash
Code is getting a bit unwieldy anyway. Might be time to break it up.