I have to say the example blindfish was suggesting is a little weired. Sometimes if you drag a particle and let go, it zooms away as extremely high speed. Even fishing for a particle (have mouse stay at the same position all time) then let go is not immune to this problem. After inspecting the code, I found no mention of time in calculating for speed. Say if dragged gets processed every so often at a very constant pace, no problem. But if dragged doesn't get processed very regularily and especially not at the same constant pace as draw, we have a problem. I suggest using System.nanoTime() to store time and the speed will be multiplied a factor of 2 if say dragged is triggered around 60fps instead of 30fps for draw(). I try to pin a particle by clicking on the window and let go without moving the mouse, the particle still has speed when I let go of the mouse button, sometime huge speed

Yep. You compared a distance of mouse positions between two events happening in sequence that are not necessarily happening at fixed delay. Plus, there is also a case where the dragged ball is bounced away from the mouse while being pinned but not dragged ^_^. Just find a ball and keep it in place and see it bounces off to the side by other balls. But once you move your mouse, the dragged routine updates the ball position just fine.

OK - I just fixed a lot of the issues with the code and updated my sketch on OpenProcessing.

First off I stopped using the ball position to determine the velocity when thrown and now use the mouse position.  The issue with insane speed was caused because of my tendency to centre the ball on the mouse position when it is 'picked up': that created a large distance between oldX/Y and currentX/Y leading to high speed on release.  Happily resolving this issue resolved the other problem: using pmouseX/Y by definition compares the position from the previous frame (and there's also no need to store the variable on mouseReleased).

There's an argument to factor in framerate (or use a time-based approach) since that would affect the distance recorded between the two points and therefore affect the speed (i.e. I imagine at higher framerates the speed will diminish).  There's also still an issue at slow speeds where it can go off in an unexpected direction; but this is more of a physical issue and I'm not sure a time based solution would avoid it: the act of releasing the button can lead to unintended motion of the mouse...  I guess storing the last few positions and averaging out the vector might limit this to some extent.

I did write the original code a while ago and would do things a little differently now anyway (e.g. handle mouse events in the class, use registerDraw() etc.), so might create an updated example and look into possible improvements; but for the moment it's now a lot better than it was.

Sorry Giles for posting a bad example and thanks liudr for the heads-up.

blindfish,

Very nice and smooth mouse handling now! I just speculate a time-based tracking and averaging over several frames might help. I'm doing a project to track position on a camera. The tracked position is jittery. I'll try the averaging on it and post some results.

liudr

You've really nailed it, Blindfish. The blue balls are very impressive at low speeds - seems to capture the release speed very well.

Glad I've been able to make up for my previous badly implemented example

The current version on OpenProcessing looks OK to me: the particle I pick up isn't influenced by other particles (i.e. doesn't drift) though it does still have influence on them.  You could check to ensure both particles have 'affected' set to true before applying forces to them if you wanted to avoid this...

One thing I just noticed: in each loop you process the forces twice:

Code:

for(int i=0; i<numparticles; i++)  {
    for(int j=0; j<numparticles; j++)    {
      float ijdist = dist(particles[i].xpos, particles[i].ypos, particles[j].xpos, particles[j].ypos);
    }
} 

e.g. when i=0 and j=3 you compare the same two particles as when i=3 and j=0.  Another useful nugget I've seen posted by Quark: start j at the current value of i:

Code:

for(int i=0; i<numparticles; i++)  {
    for(int j=i; j<numparticles; j++)    {
      float ijdist = dist(particles[i].xpos, particles[i].ypos, particles[j].xpos, particles[j].ypos);
    }
} 

It all still works; though you may find the reactions are less strong since you're only applying them once and not twice each frame

Yes, that's right...the i+1 means you use half the matrix of comparisons, not including the diagonal (where i=j). Thanks for pointing that out.