Well, that was fun, but frustrating. I realized after logging off last night that I may be able to correctly calculate the amount of time until an attractor and attractee meet in space based on the attractee’s current velocity toward to the attractor. Googling informed me that an aiming an object’s velocity vector towards another point in space is called vector projection. I saw a good analogy in this YouTube video:
Basically, to project vector A onto vector B, you draw a right-angled line from vector B to the end of vector A. The result is basically a scalar of vector A. Now, like any normal human trying to assimilate to the age of AI, I asked ChatGPT for the proper Unity code to project my attractee’s velocity vector onto its direction vector towards the attractor. The problem was that ChatGPT could not produce a consistent formula for the projection. Here are the suggestions it made:
float projectedVelocity = Vector3.Dot(rb.velocity, specifiedDirection);
float projectedVelocity = Vector3.Project(rb.velocity, specifiedDirection).magnitude;
float projectedVelocity = Vector3.Dot(target.rb.velocity, direction.normalized);
Upon implementing my new algorithm, which scaled the player based on the amount of frames needed for it to reach the attractor given its current velocity and multiplied the scale based on the distance it had already traveled from the startScaleDistance, Option 3 yielded the only decent result.
I say decent, because while the above Gif shows success, the algorithm mysteriously fails when the bodies are different sizes, leading the smaller body to over-scale and the larger body to under-scale. The algorithm unsurprisingly breaks worse when a third sphere is introduced.
Notice the attraction radii changing sizes. At first they scale uniformly but later they diverge and that’s when the glitch happens. Because the nature of this algorithm is to add or subtract scale continuously regardless of the attractee’s current size, I needed to implement a way to stop scaling beneath a certain distance or velocity. I tried that to no avail.
I think the same bug from yesterday is causing these shenanigans. Two bodies merging stops a third one from joining completely. I tried manually setting all merged objects to a common position once they got close enough together, but abandoned that technique when I realized how many future problems manually setting position would cause.
I tried a new idea—tampering the scale based on a relative velocity dot product threshold. The results are the best I’ve gotten so far. In the below image, the starting scale of each sphere are 0.5, 0.75, and 1. The combined mass? 2.25.
This is great, but I still need to fix that jitter. Also, the masses don’t combine as well when traveling at higher speeds. It’s Friday! I’m logging off for today.