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.
This will help during debugging to prevent things from screaming around
the play area. Especially when the acceleration routines are unbounded
and can infinitely add energy to the system.
The separation function causes the boids to rush away from each other
when the simulation starts because they're all stacked at the origin.
Spawn them out in a ringso that this doesn't happen nearly as
aggressively.
The cohesion function was erroneously applying forces to boids that
shouldn't be experiencing them. It shouldn't be iterating over all
boids-with-velocity and adding speed. It should be applying that force
only to the one boid that the loop is examining at that iteration.
I also cleaned up the signature to have just one query struct. I had it
split as two because I was getting issues with mutability. The fix was
to make the query mutable, and then keep the Transforms as immutable
references. This way I can reach through and update the Velocity alone.
The clumping was because the function was moving the boids together,
not apart. The chaotic movement was the result of the large coefficient
on the force.
I've updated the position integration function to account for
acceleration. I need to change it once more to represent force, instead.
The idea is that the steering functions can all do their thing and apply
a force to the boid. Then, all mobs have their acceleration (forces)
integrated up through velocity and into their new position.
This version produces clumps of fast moving boids. Boids out on their
own will slowly come to a stop. I'm not sure why either of these is the
case.
I was trying to work out a way to run the loop using iterators, but
that doesn't really matter. I had an empty loop to consume the results,
which means I just have a for loop anyway.
I understand what Daniel was talking about when they referred to the
movement being very rigid.
https://github.com/danieldidiobalsamo/boids/blob/master/src/boids_plugin.rs#L289
Their implementation has a different main loop than mine so that the
acceleration can be delayed by one frame. This way things can choose
their movements without being able to observe the ones that have already
completed theirs for the current frame. I haven't done that, and things
are weird.
I'm going to try to resolve this by moving down into an acceleration
value. Apply a force, integrate at the beginning or end of the frame.
I got the cohesion function to act on the Boids, but there's something
wrong with the math. I already had to dance around the accidental
introduction of NaN's into the system.
I'm finally starting on the actual Boids flocking algorithm parts.
I don't want to iterate over all the things, and Bevy doesn't seem to
have fast collision testing yet, so I've reached for bevy_spatial to
track my Boids.
