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.
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.
I made the center_of_boids() and velocity_of_boids() functions so that
they can be reused in the debug overlay operations. I should probably
use them in the main system, too.
Right-clicking toggles velocity sensing mode and the cursor gets a line
that indicates the average velocity of the targeted points.
There is a coefficient of 50.0 on the pointer magnitude. The boids move
so slowly that the line is very short without this magnification.
There is also something wrong with the math. The boids expand and slow
down, but the velocity vector does not reflect this. It *grows* slightly
and then stays at that size as the boids slowly approach a stop.
When writing the average velocity function, I realized that it is
**exactly** the same as the center of mass function. They're both just
averaging a bunch of points. Both functions are implemented as pass-
through calls to a general purpose Vec2 averaging function.
The `impl Iterator<...>...` *is* actually necessary because of the use
of `map()`s to filter out the boids parts from the spatial tree.
`enumerate()` begins counting at 0, so I was dividing the sum by one
less than the count of boids. Thus the over-expanded result.
I should do unit testing.
I should rewrite this function to take the vector directly. I *know*
that the input is a vector at all times. Mmh.
