I want to at least have the smell of reproducible builds, so I'll make
the image build using the lockfile. Otherwise the build-time dependency
information gets lost.
The config.toml lets me run `cargo run --target wasm32-unknown-unknown`
and host a dev server.
I've adjusted the Cargo.toml to use the kdtree_rayon feature by default,
but disable the Rayon feature for WASM builds (because it doesn't work).
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.
This pins the dependencies of our dependencies so that the
`-Zminimal-versions` flag of cargo nightly will result in a working
build. Ideally the package authors would have their versions set
correctly. The flag is on nightly for a reason, though. Oh well.
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.
