This makes the output folder "required to exist" and not "required to be
more recent."
The folder's timestamp is updated when files are written into it. The
files inside depend on the folder existing. The result is that the WASM
and JS files are considered very slightly older than the folder that
contains them. The result is that the folder is up-to-date but it's
contents are not, thus re-building them and *again* updating the folder
timestamp. The makefile was stuck constantly rebuilding things that are
actually up-to-date.
Oops, it's not supposed to have a file suffix! It's a bit annoying that
it still produces both a WASM and JS file, just not the right ones (and
no _bg.wasm at all). Especially without any warning that it is doing
something different than normal. Oh well.
Call with `make -f makefile_web` to produce a web root for serving. Use
target "boids_web_root.tar" to bundle the files into a tarball. For...
publishing... or something.
The `wasm-server-runner` program seems to supply it's own index.html and
is doing *something* regarding MIME types -- hosting a dev build of the
Boids program results in the browser complaining about "" (empty string)
being an invalid MIME type.
I want my own index.html during testing, and I can't figure out why the
MIME type info is wrong. I've decided to automate the web-root build
process and serve it up with whatever webserver I have on hand.
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.
