Hey y'all, this might be a math-heavy post, idk.

So i am currently improving this project.. It contains many small gravity sims. Towards a position rather than another mass. Currently, I use (0.9 * previous X velocity * X distance / Total distance), a simplified version of the actual gravity equation. I'm looking to make this part of the code faster. Maybe instead of using pythag, I only take the X distance into account? Not too sure.

Here is the current order of processing

please read the above text wall, sorry!
when I receive [calculate this thang v]
go to x: (...) y: (...) // previous position
pen down
calculate X velocity
calculate Y velocty
update X velocity list and position
update Y velocity list and position
go to x: (...) y: (...) // new calculated position
pen up
setup next calculation

I'm not really sure what to change here at all to make it faster. Also removing the mini trails that each line has isnt an option. (Using less move functions). I am yet to add a dead zone so its still jittery neat it's desired position. dw about that

I don't need 100% accuracy, just something that looks close to an accurate sim.

Forgive me for the length of this post.
I'm pretty sure you know the extra move block is the problem. If I were you I'd experiment with different ways to make a trail. If you won't need to erase the pen quickly in whatever project you plan to use this with, you can use the following script (with a solid white costume2).

forever
stamp fade//rather than erasing all, it will all gradually fade
step::custom
end

define stamp fade
go to x: (0) y: (0)
switch costume to [costume 2 v]
set [ghost v] effect to (60)//adjust for fade speed
stamp
set [ghost v] effect to (0)
switch costume to [costume 1 v]

The actual physics script can be made faster, but it will likely make negligible difference. Would it be okay to just make each particle move in a straight line toward its target? This would make acceleration much faster as normalized x and y components would only need to be calculated once (store them in lists). Otherwise you could just remove the square root entirely. This speeds it up and should still look reasonable. Remember, g = m / d^2. If d is a sqrt, d^2 cancels out the sqrt.

oh my god. the second part of d squared is actually so smart how did I not think of that. And yea ig i have to remove that trail… unfortunate. I might be able to have only half of the particle's velocities calculated every other frame, so it alternates to save resources.

for any people reading this in the future:

no, this did not work. I am currently working on calculating particles every other frame instead of every frame, to save resources, and potentially another equation

i am leaving this thread open for any more suggestions, as I have discussed with many and basically all new equations simplified into the one I have currently

Jareddddddd wrote:

for any people reading this in the future:

no, this did not work. I am currently working on calculating particles every other frame instead of every frame, to save resources, and potentially another equation

i am leaving this thread open for any more suggestions, as I have discussed with many and basically all new equations simplified into the one I have currently

Without changing any of your equations you can still get a performance increase of 15%-20% by utilising variables rather than working directly on lists, only calculating the distance once per loop cycle and splitting x and y components over separate lists to simplify indexing. It also has the bonus of making your code far simpler to read and work on.



Obviously your set-up will also need modifying to match the list separation.

interesting thank you Mr Rok.