Handling multiple vectors

Hi there,

Using a simlpe object vs vectors collision as is described in Tony's tutorial; how would I apply the folowing?

http://www.saphua.com/temp/vect.gif
The left image represents the first frame and the second image the folowing. The object falls down and by using a simple for-loop it finds a 'hittest' vs vector 'A' and thus moves the object to direction 'D'. It is obvious, however, that the object should head in direction 'C', since we also have vector 'B' that should be taken care of.

If this made sence to you; can you tell me how could I solve this problem? Assuming I have an array of multiple vectors that the object will hit, how will I find out which one will have priority?

Kind regards,
~Sph

not sure, I think in APE, its a first come first serve basis, so red vector is solved, then check other lines, solve them too. If red vector moves the object out of collision then green wont even detect it.

If your ball is moving down in that example, then if green vector is checked first, the resulting vector is not C, because you should be checking the green lines end point not its facing vector, so the result should be somewhere between C & D

http://www.tonypa.pri.ee/vectors/tut08.html

I think

is there a swf showing the problem?

Hmm yes, taking the average could somewhat solve the problem. However, in reality the ball should only hit vector 'B' and thus head in direction 'C'. I would offcourse rather like to use the more realistic method.

maybe find which contact point is closest to the old position of the ball, then choose that line for collision response.

I'm sure that you don't need to do that though if you are checking collisions at line ends.

just curious, are vectors A & B permanently attached like that forming a corner, or are they free floating lines?

Good question ;) They are free floating lines, so there are 4 points. I would rather not change the engine to work with connected lines as I'm assuming that would require lots of changes.

Here's a sample:
http://www.saphua.com/temp/vect/vect.html

ah now I see, I wasn't thinking about the resolving of velocity.

hmmm, Well I guess try the old position method or maybe iterate through all points, or maybe find the line which is overlapping the ball the most and choose that for response.

Iterating this pixel by pixel would be a bit overkill I think. I'm sure that there is a math-based sollution for this. The overlapping method might be interesting, I could see if I can work that out.

PS: Please take note that this does not count for corners only. It could aswell happen in the folowing picture.
http://www.saphua.com/temp/vect2.gif

OK, makes more sense now. Not familiar with that tutorial... are you finding the closest distance to center of the ball for each vector as part of the calculation? I presume that if you choose the closest one and disregard the other, you will almost always get the right result.

Perhaps I'm dumb, or maybe I missed something, but I thought the easiest way to handle multiple vectors was to simply add them to achieve the total force and direction. Then you simply apply it to the ball? Or would it be different with a static vector considering it doesn't technically have a force (unless you considered vx/vy a force)?

Quote:

---

Originally Posted by mr_malee

red vector is solved, then check other lines, solve them too. If red vector moves the object out of collision then green wont even detect it.

---

I think this is the correct solution. Even if it takes multiple frames to resolve the ball against every line, I think the end result will still match physical intution. You can solve multiple particle collisions like this - if 3 particles A/B/C impact simultaneously, resolve each encroached pair in succession. As long as momentum is conserved on every resolution step, the final results will "look right".

This is even true if multiple, cascaded encroachments happen - like untangling A and B tangles A and C, then untangling A and C tangles A and B again - this is OK, it will just take a couple of frames to resolve via pairwise tests over and over. And I don't see why line primitives would be any more problematic. Treat each collision as a 2-body problem, make sure your resolution step conserves momentum and restores tangency, and I think you'll be fine.

http://www.johanvanmol.org/content/view/41/37/1/4/

this has some explanations on determining ball colliding with corner vectors... it may help he explains how to determine the reactions witht he first corner, then with that reaction check the other vectors

Basically you find collision points with ALL vectors, in this case 2. Then if multiple collisions would happen, you find find which one would happen first (the length of vector between balls starting point and each collision point). Once you have found the first collision (shortest length) you solve using that wall and find new movement for the ball. Now the ball is at the point where it has hit closest vector and has new movement after bouncing off from that wall.

Interesting :D

Tony's method seems to solve this in 99/100 cases, so I think I'm going to go with that one. It was also the easiest one to implement :D

Thanks for the replies and url's.

Seems to me as if the only time tonypa's method wouldn't be exactly right is if the point of collision is at the corner of two walls, ie length to both vectors is equal and the ball is outside the acute angle of the walls. In this case, I've used a circle to circle method to determine the new vector, where you consider the corner of the wall to be as very small circle (or a point depending upon your math). It gives you a new vector that seems like the real thing, I'm just not sure if it's physically the right method.

You dont have to simulate corners with small circle, it is easy to calculate bounce from corner point:
http://www.tonypa.pri.ee/vectors/tut08.html
Every line segment can have 3 collisions: collision with line itself or collision with one of its endpoints.

Thanks tonypa!

Learning that will help optimize some of my code :)

Hey Jerry,
Mind telling us what you're working on?

Right now I'm working on an aneurysm trying to optimize a 3d rendering system. I've got it down to only making one calculation per vertice, but I'm at a bottle neck with rendering. Seems using bitmaps and matrix transformations offers no performance increase over a lineTo method, due to the fact the draw() method uses the same flash rendering system when you include a transform.

My BIG project is trying to determine an algorithm that would prove the Dolphins can beat the Patriots, but I'm having a very hard time with that one! Thank god I'm a Cowboys fan!

In my spare time I'm working on a game for my godson. One that uses a voxel type engine, with a webcam based control system that doesn't require motion detection in the normal sense. He has always played video games standing up and acting as if he is in the game. He is so animated that most basic motion detection methods in flash wont work, so I figured out a "dark-room" approach that seems promising. I'll be sure to post more about it soon!