pablo-mayrgundter
commented
3 years ago "What are lines 118 and 119 for?"
Ah darn, I meant that to be inside an "if (this.first) {}" block. In other words, set the particles spinning normal and proportional to their inward force. I think I added that, saw it worked and forgot it should only be for the first step.
Of course, it gives me exactly the effect I want, but for the wrong reasons. Now that I have it in the conditional, I'm having a much harder time balancing the forces. I suppose this is where things actually need to be correct! :)
Thanks for the explanation of Verlet integration. I'll also try that.
On Tue, Jan 12, 2021 at 11:47 AM won3d notifications@github.com wrote:
What are lines 118 and 119 for?
On the plus side, lines 120-122 seem to be doing semi-implicit Euler integration, which is a reasonable choice. Basically, the order you accumulate velocity and position matters. Doing:
position += velocity velocity += acceleration
Isn't as stable as vanilla Euler:
velocity += acceleration position += velocity
To be clear, that seems to be what you are already doing, but you should note that the order of accumulation matters.
A bonus thought:
A lot of physical simulations will do something slightly different called Verlet integration. I think it has some nicer properties than the Euler variants without being too much more complicated. You could even argue that it is conceptually simpler because it doesn't explicitly even use velocity. This is nice because a lot of more simulations will have constraints on positions, and when you go to enforce them you have to make sure your velocities are also corrected. Not having explicit velocities avoids that .Or maybe you want to draw streaks behind the particles, where you'll need the old positions. But most importantly, Verlet is just a more accurate numerical integrator.
Verlet works by reconstructing velocity from positions. You want to do something like:
pos_after = pos_now + vel + accel
You can recover vel with finite differences:
vel == pos_now - pos_before
When you substitute you get:
pos_after = 2*pos_now - pos_before + accel
In practice, pos_old and pos_next can be the same storage -- you're effectively double-buffering. In the context of ThreeJS, I don't know if that's a good thing or a bad thing. It is possible that ThreeJS tightly couples GPU and CPU vertex buffer storage layouts, which makes updating a buffer not as simple as just setting a flag. There are lots of ways around it but I'd have to know how ThreeJS worked better, and what you would want to accomplish.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pablo-mayrgundter/celestiary/issues/17, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAS5V36EX2QHNEBTQMSMCR3SZSDMVANCNFSM4V7SDWFQ .
-- interweb homepage http://sites.google.com/site/pablomayrgundter
won3d
https://github.com/pablo-mayrgundter/celestiary/blob/5c8e5f2b32272cf07a95f450987bb16596acbba8/js/Galaxy.js#L116-L124
What are lines 118 and 119 for?
On the plus side, lines 120-122 seem to be doing semi-implicit Euler integration, which is a reasonable choice. Basically, the order you accumulate velocity and position matters. Doing:
Isn't as stable as vanilla Euler:
To be clear, that seems to be what you are already doing, but you should note that the order of accumulation matters.
A bonus thought:
A lot of physical simulations will do something slightly different called Verlet integration. I think it has some nicer properties than the Euler variants without being too much more complicated. You could even argue that it is conceptually simpler because it doesn't explicitly even use velocity. This is nice because a lot of more simulations will have constraints on positions, and when you go to enforce them you have to make sure your velocities are also corrected. Not having explicit velocities avoids that .Or maybe you want to draw streaks behind the particles, where you'll need the old positions. But most importantly, Verlet is just a more accurate numerical integrator.
Verlet works by reconstructing velocity from positions. You want to do something like:
pos_after = pos_now + vel + accelYou can recover
velwith finite differences:vel == pos_now - pos_beforeWhen you substitute you get:
pos_after = 2*pos_now - pos_before + accelIn practice,
pos_oldandpos_nextcan be the same storage -- you're effectively double-buffering. In the context of ThreeJS, I don't know if that's a good thing or a bad thing. It is possible that ThreeJS tightly couples GPU and CPU vertex buffer storage layouts, which makes updating a buffer not as simple as just setting a flag. There are lots of ways around it but I'd have to know how ThreeJS worked better, and what you would want to accomplish.