Hey fk'ers, I was playing around with some old examples I found the other day(more specifically the ball line collision example in Jobe's Flash MX demystified). I was curious as to how to implement this into a simple bike/skateboard/2 wheeled object engine. Now I know there has been lots of discussion on this, but I'm wondering how the engine works in order to not only keep the 2 wheels(circles) at a constant distance(I wouldn't want my bike ripping in half), but to also have the wheels react according to the lines they are in contact with. I came up with this :
Basically it also sets the distance to 60. I have this code running before any collision detection reaction occurs. Problem is that with this is let's say there's a straight line and a ramp, as one of the wheels goes up the ramp, the distance between the two wheels will be set to 60, which will make 1 of the wheels sometimes go underneath the ramp in order to satisfy the distance constraint. Now how might I get around this? I'm not necessarily looking for problems in how I'm doing it, but rather as to how 2 wheels are at constant distance + not being funky in games involving bikes and such going on hills. Thanks.
Add the distance the wheel must move to satisfy the 60 pixel distance as a one time boost to acceleration/velocity so that it is taken into account by the collision detection.
Thats how I would do it.
The greatest pleasure in life is doing what people say you cannot do.
- Walter Bagehot The height of cleverness is to be able to conceal it.
- Francois de La Rochefoucauld
I think its better idea to move both wheels by half the value off from 60:
*find current distance between 2 wheels (curDist)
*find how much current distance differs from 60 (offset=curDist-60)
*move 1 wheel by half the value (offset/2) in one direction and other wheel by half the value in opposite direction
Thanks Tonypa for the tip on expanding/contracting. Now if you could only shed some light as to how to keep both constraints valid at all times(constant distance+above lines). Hehe. I seem to have trouble with the fact if the wheel does penetrate the line, then the collision doesn't work anymore for that wheel. I'd need to somehow find a way to figure out if the wheel has collided with the line in the near past, and if so, adjust it back on the line. As you know I'm using Jobe's ball-line intersection method, which I think you're sort of familiar with since I remember you mentionning it in another thread.
Now is this method plausible with the 2D bike style thing I'm trying to get going? Or should I switch to using verlet integration as described here http://www.gotoandplay.it/_articles/...hp?PHPSESSID=4.
To keep all of the constraints valid you have to continually re-compute the constraints and collisions several times each frame.
As I said, to prevent circles going through the lines you have to add the movement it must make to resolve the collision as a one time boost to the velocity. This means that it will be counted as movement for the circle-line code you are using and will prevent it from pushing a circle through a line.
The greatest pleasure in life is doing what people say you cannot do.
- Walter Bagehot The height of cleverness is to be able to conceal it.
- Francois de La Rochefoucauld
As I said, to prevent circles going through the lines you have to add the movement it must make to resolve the collision as a one time boost to the velocity. This means that it will be counted as movement for the circle-line code you are using and will prevent it from pushing a circle through a line.
Could you please elaborate on this? I'm just wondering about the one time boost thing. Let's say the circle has to move 25 pixels left, and 10 pixels up in order to satisfy distance constraint. When you say add a one time boost to the velocity, you're figuring something like xvel+=25 and yvel+=10?
Could you please elaborate on this? I'm just wondering about the one time boost thing. Let's say the circle has to move 25 pixels left, and 10 pixels up in order to satisfy distance constraint. When you say add a one time boost to the velocity, you're figuring something like xvel+=25 and yvel+=10?
It will take a bit of work to code properly, but essentially yes.
Lets say that there is a starting velocity of 5,0 and gravity is 0,1 and we have to satisfy the above constraint:
xVelocity = 5; (starting velocity)
yVelocity = 0;
yVelocity += 1 (gravity);
xVelocity += 25 (constraint)
yVelocity += 10 (constraint)
xCorrection = 25 (constraint)
yCorrection = 10 (constraint)
Run the movement and collision detection code
xVelocity -= xCorrection (remove the correction so that the velocity doesn't go insane)
yVelocity -= yCorrection
The idea is that since the code already works well with velocity, we just have to alter the constraints corrections so that they are also treated as velocity and are therefore calculated in the collision detection.
The greatest pleasure in life is doing what people say you cannot do.
- Walter Bagehot The height of cleverness is to be able to conceal it.
- Francois de La Rochefoucauld
Well it seems to be working now, except sometimes when the wheels are verticallly aligned and the wheel on the bottom hits a flat line, it simply goes through it after a bit of jitter. I've attached the .fla in case you want to have a look. Would you think iterating over the steps for a bit would end up validating all constraints in this situation?
Unfortunately, I dont have flash 8, but I suggest that you try to figure out at what point movement is being applied without being run through the collision checking.
Running the calculations several times each frame may increase the reliability, but it wont fix an existing problem completely.
The greatest pleasure in life is doing what people say you cannot do.
- Walter Bagehot The height of cleverness is to be able to conceal it.
- Francois de La Rochefoucauld
Unfortunately I have another problem. It's with collision when 2 intersecting lines are involved. So let's say there's a straight line and then connected to it is a line at 45 degrees. Going up the slope works, but as the wheels come down, they fall through the point where the straight line meets the slope. I'm guessing this is because the collision script is detecting 2 collisions taking place, adjusting for both, and thus causing some conflict. I tried keeping track of which collision would happen first, and just act on that one, but then my problem got reversed. The wheels could go down the hill fine, but as it would go up, it would keep going straight and fall through. Ugh. Any help is appreciated.
This collision detection method returns the amount of time until the collision happens right?
If you compare those and choose the shortest one to resolve it should fix the problem. It sounds like thats what you are already doing though, and I have no other ideas of what the problem might be.
The greatest pleasure in life is doing what people say you cannot do.
- Walter Bagehot The height of cleverness is to be able to conceal it.
- Francois de La Rochefoucauld
for every object detect and resolve collision with every other object and surface
do your lines have start and end points or do the go into invinity?
The lines have start and endpoints and I do try to resolve collision for each surface. The problem is that let's say you have something like this.
________/
If a ball is travelling on this surface from left to right, once it hits the intersection between both balls, it will check for what collision will happen first. When it finds out that it will collide with the bottom first, it will sometimes nudge the ball over to the right, where the slope won't pick it up for collision, since the ball is already past it. I'd almost have to look in the past to see if the ball would have collided(basically checking for a small negative time value).
sorry if i'm not understanding. But both balls are independant right?
so their each checking their own collisions, have you got radius checking in?
if your flat bottom line is moving your wheel right on collision if the ball is already travelling right and is rested on it then your projections are wrong.
Reply With Quote
Originally Posted by 691175002
