I figured out why the new flocking behavior is different...
The previous version used 1/4th the view range for boid separation and I
didn't preserve that.
Working demonstration, but I'm not sure shape casting is the action I
want to be doing. I've just found a "shape_intersections" method in the
docs, but I'm saving my progress before making further changes.
The player-controlled boid was for testing the flocking behavior. It has
outlived this purpose and I never even bothered to make it larger like
the others. It's finally going away completely.
The birdoid flocking parameters are now a resource named
`FlockingParameters`. Adjustments can be made using the Egui inspector
widget, although I plan to make a custom UI in the future.
I'm not happy with the flocking behavior so I fiddled with the program
to find these new behavior parameters. It's annoying to constantly
rebuild the program, though, and I'd like for the end-user to be able to
fiddle with it at runtime. To that end, v0.7.0 shall be the UI update.
With the 1.0 radius boids (instead of whatever `Circle::default()`
uses), a separation activation of 1/4 the range looks more visually
appealing (imo).
The starting velocities going outwards in a circle means that the sum of
energy in the system is 0. As the boids come back together, they will
slow down to fall into a lattice. This is interesting, but not the
flocking behavior Boids are supposed to have.
I've replaced the `space_brakes` function with this new speed controller
to keep boids moving between two speeds. Anything too slow will speed up
along it's current vector, and anything too fast will slow down.
The "length" is actually the `enumerate()` index, which is one less than
the item count. The previous version was not using the average, and may
have been deviding by 0 for boids with exactly one neighbor.
The keyboard input should apply a force, not modify the velocity. Right
now, there is no Mass component, but in the future there might be. I've
just fixed a broken physics integrator made by bad assumptions, too, so
I'm goig to do this for consistency if nothing else.
The velocity component never got updated. Instead, the system was only
calculating the current frame's deltaV. That instantaneous dV and any
velocity that *did* get assigned (bundle insertion, keyboard control)
would be added to the position.
Now forces are integrated into velocity, and velocity is integrated into
position. You know... like a real integration function.
The module isn't the plugin, so it's going to be called simply
"birdoids" going forward.
I've turned it into a folder and a `mod.rs` so I can slap down a small,
custom physics system.
The force functions are discontinuous at (0,0), and as such need to
return an optional. Without this, I'll be feeding NaNs back into the
program, which will propogate and cause a total simulation collapse.
This calculation should produce an infinity, or NaN. Either way, it's an
error that definitely still exists. I'll make a test for it, and then
fix it at some point. This is so that I don't forget.
The cohesion function would accept inputs over the range (-1, 1) when it
has been designed to work over (0, 1). This changes the math to
calculate the magnitude separately and re-apply it to the pointing
vector.
Finally time to just use the unit testing tools Cargo gives me. These
are all a bunch of simple tests to verify that the functions work as
expected.
... They don't. I made the assertion that the input ranges are (0, 1)
when, in fact, they are not. The boid's view distance is scaled into
a unit vector space. The trouble with this is that a valid coordinate
is (-1, 0). The force functions don't have the correct shape at this
range.
The fix is to get the absolute value -- the vector's magnitude -- and
feed that through the force calculation function. This way it *is* in
the range (0, 1). The magnitude can then be multiplied back over the
deviation vector to get a proper force application.
This unit vector can then optionally be multiplied back up to have more
exaggerated effects. The {COHESION,SEPARATION,ALIGNMENT}_FACTOR's can
pick up that role again.
Closes#2
Acceleration is mass * force.
This doesn't materially change anything, but it will make it easier to
give the boids a mass component. The change will not require updates to
most of the systems, only the physics integrator and the boids bundle.
The Boids algorithm functions need a lot of work, but the cohesion and
separation functions appear to nominally perform their stated goal.
Both are constant forces across their whole range, so there is a jerking
motion as things cross in and out of the activation boundaries.
I think the alignment function breaks the laws of thermodynamics, as
well. Oh well, that's what the spacebrakes system is for.
The physics integrator is real scuffed. Nothing has mass, and no forces
are applied. Instead, objects affect each other's acceleration. It acts
functionally like a force accumulator where everything has a mass of 1.
Under this model, it must be cleared each frame so that it can be
re-accumulated during the next physics calculation cycle.
This bug was spotted because of anomolous behavior of the velocity
pointer. Nearly stationary boids would have a rather large (especially
after the coefficient reduction earlier) velocity. I noticed this
earlier when building the debug tool and thought it was an error in
the calculations. There might still be bugs, I still need to test, but
that particular one seems to have been a position integrator error.
The reubild frequency of the spatial tree was causing calculations to
operate on old information. This is not the intended behavior. The
default schedule seems to be to run every frame.
I also lowered the debug pointer coefficient. Boids moving at a normal
velocity are actually fast enough to draw a meaningful line. Maybe I'll
switch it into some kind of exponential space so small changes are
visible, and big changes don't draw a line all the way across the
screen.
