I am coding a simulation of a cricket player throwing a ball and I have come to the part where the player throws the ball. I don't think my simulation of the ball is very accurate though and I am not quite sure why (no idea what to be looking for in physics). What I have so far is something similar to this, the arm has a rotation speed and the ball is released at a certain point. So I approached this using a vector from the arm to the ball, I figured the direction the ball should travel in the direction of the right normal. So this is what I have for the direction.
throwSpeedHorz = -1*sin(bowlerArmRotation * (3.14159/180)); // * rotationSpeed
throwSpeedVert = cos(bowlerArmRotation * (3.14159/180)); // * rotationSpeed
The problem I have is how do I use the speed of the arm with this to get the total speed for each. I have tried multiplying it by the speed of rotation which gave a way too high number for the speed.
If someone can point me in the right direction it will be greatly appreciated.
Speed is usually given in rotations per second, so the speed of the tip of bowlers "arm" is given by
speed = rotationSpeed * 2 * PI * bowlerArmLength
(or more exactly the distance of the ball to the rotation axis). You can then extract horizontal and vertical components as described in your question.
Related
So I am working on a simulation of the solar system and ran into a roadblock...
In reality, the speed of the moon compared to the earth is much slower then that of the earth compared to the sun. However, the moon completes its orbit much quicker because it has to travel much less distance. The moon orbits the earth about 13 times in 1 year.
In my simulation however, the moon gets maybe 2 orbits in a year...
I've checked the speed with wikipedia and they are correct.
The only difference is that I scale everything, making me suspect that that's the cause.
All distances are devided by 100 000 and all speeds are devided by 1000
this.angle += (speed * deltatime);
this.x = this.semi_major_axis * Math.cos(this.angle) + this.parent.x + this.focalX;
this.y = this.semi_minor_axis * Math.sin(this.angle) + this.parent.y + this.focalY;
Speed is the speed according to Wikipedia. (29.78 km/s for earth and 1.022 km/s for the moon)
Parent in this case means the object it is orbiting (in case of the earth, it's the sun. In case of the moon, it's the Earth)
focalX and focalY are the offset from the planet.
Speed and the 2 axis values are already scaled at this point.
Am I wrong in the manner of the scale? Am I completely missing something obvious? Am I just doing it completely the wrong way?
Since speed is distance/time (eg kilometres/second) when you scale speed by 1000 and distance by 100000 you have, whether you know it or not, scaled time by 100. Are you sure that you have taken this into account in the rest of your calculations ?
And yes, you are approaching this entirely the wrong way. If you were building a mechanical simulator you would want to scale distances quite early in the process, but in a numerical simulator why scale them at all ? Just work in the original units.
Since you don't have a computer screen which is several AU (astronomical units) across, you might have to scale the numbers for imaging but most graphics systems will do that for you at some point in the pipeline.
I'd say you should go through the exercise of non-dimensionalizing the original equation of motion, similar to what people do with Navier-Stokes equation for fluids (it's a good example to look for). You'll see that non-dimensional groupings should turn up, like the Prandtl and Reynolds numbers for fluids, that will give you meaningful insight into the problem AND make your numerical solution more tractable.
I don't think it'll be the scale, the simulation will do those distances 100 times quicker than is accurate (big drop in distance, small drop in speed), but it should be uniform across the board so the Earth and Moon will both speed up by the same amount, I'd look at the base speeds again and make sure they're correct and also your algorithm that calculates distance travelled.
So I have a system with colliding balls that generally works, except for when they collide with similar directions, less than 90 degrees apart.
This is because the ball above tries to collide against the yellow line which is supposedly the collision plane, but it sends it off the wrong direction, and it "follows" the other ball. The general algorithm for the collision is:
dot = direction.surface;
parallel = surface * dot;
perpendicular = direction - parallel;
direction = perpendicular - parallel;
Which negates the component of the direction parallel to the surface normal, which is perpendicular to the collision plane, and the part perpendicular to the surface normal is unchanged.
Does anyone know a fix for this? Have I done something wrong?
Edit: So now I added:
average = (ball1.velocity + ball2.velocity) / 2;
ball1.velocity -= average;
ball2.velocity -= average;
Before doing the calculations above, and after that:
ball1.velocity += average;
ball2.velocity += average;
To get in the right reference frame, according to #Beta's answer. The problem now is that the speeds of the balls aren't maintained, since they both have the same speeds and masses, yet after the collisions they're different. I do not think this is supposed to happen, or is it?
Consider the 1D problem of bouncing a ball off a wall. Simple.
Now watch me bounce a ball off the forward bulkhead of a jet plane in flight. The ball is moving north at 252 m/s, the bulkhead is moving north at 250 m/s. The answer is not obvious. But shift into my coordinate frame (by subtracting the velocity of the bulkhead, 250 m/s, from everything) and the problem is trivial. Solve it, then shift the result back into the ground frame (by adding 250 m/s to everything) and you're done.
Now the 2D problem of a ball bouncing off a wall at an angle. Simple. (But verify that your code does it correctly.)
Now two balls colliding with equal and opposite momenta (I'll assume they have the same mass, for now). You can imagine a yellow wall at the collision plane, and the answer comes easily.
Now two balls colliding, but with velocities that do not add up to zero. There's still a yellow wall, but it's moving. Well, shift into the wall's frame by subtracting the average of the balls' velocities (sum/2) from everything, solve the simpler problem, then shift back by adding that same velocity back to everything, and you're done.
For fun I am making Pong in Python with Pygame. I have run into some trouble with reflections.
So the ball has an angle associated with it. Since positive y is down this angle is downward. If the ball hits the top or bottom walls I can simply negate the angle and it will reflect properly, but the trouble is with the left and right walls. I cannot figure out the trigonometry for how to change the angle in this case. I am currently trying combinations of the below snippet but with no luck.
self.angle = -(self.angle - math.pi/2)
I have attached the code. You can try it for yourself easily. Just remember to take out the "framerate" module which I have not included or used yet. I would appreciate any input. Thanks!
You'll want to look into Angle of Incidence.
Basically you'll want to find the angle theta between your incoming vector and the normal of the wall the ball is hitting. Where the incoming angle is (wall normal)-theta the resulting angle is (wall normal)+theta.
The angle can be found using the dot product between your incoming vector and the normal of the wall, then taking the inverse cosine (normalize your vectors first).
You should use:
math.pi - angle
I have a slider, whose velocity I calculate via the difference between positions each tick (this can sometimes be huge due to using it via a touch screen, so maybe I should clamp this at some arbitrary number to avoid some of these issues?)
I have a ball with a 3 dimensional direction vector and a velocity.
When the ball collides with the slider I invert its direction on the Z axis (going away from the slider) and then use the sliders velocity to manipulate its X (left <-> right) direction. so:
ball.direction.x += (slider_friction * slider_velocity)
Now the ball update is carried out as follows:
velocity = ball.velocity * time
ball.direction.normalise()
ball.position = ball.direction * ball.velocity
This seems to work great, except in some cases it seems to be very possible for any of the balls axis to equal zero, resulting in it never returning to the slider in some cases. What would be a good solution to this? And what would be a good way to handle the response with the blocks when it collides with them? Should it return to bouncing at right angles, or should it maintain reflecting with the same bounce modifiers applied by the slider? Also any other physics tips for this kind of projectile simulation would be appreciated.
Hmm, this is a nice problem; the thing is, a good solution (that is, one that looks and feels just like real physics) is by nature one that uses real physics. Luckily, most of the newtonian physics within this problem can be easily simplified. Pardon me if I get overly verbose, but physics tends to do that to you.
So, to define the problem, this is an elastic (as in, no energy is absorbed) collision between an arkanoid ball and a paddle. First of all, since you've obviously got the vertical motion down, I won't concern myself with that. So what follows is all on the horizontal components of the collsions.
The paddle transfers a certain amount of horizontal momentum to the ball (although, since this is Arkanoid physics, the paddle loses no momentum itself :P). This can be recieved in two ways -- by making the ball spin, and by giving the ball some horizontal momentum (obviously, if the ball already has horizontal momentum or spin, the added momentum will be...well, added).
delta momentum + delta angular momentum = momentum paddle gave
Of course, it might be annoying to work with momenta, since you don't really have to. I would asssume that the ball and the paddle have constant mass (that is, the ball does not suddenly become heavier, although you could easily work with that), because then you could factor the mass of each out of your momentum equations. So then,
delta horizontal velocity + delta angular velocity = paddle velocity * mass of paddle / mass of ball
To get an equation you could use out of this, you have to set how much of the momentum from the paddle would go into the spin, and how much would go into ball movement. For example,
mass_factor = 2 # ratio between paddle and ball masses
angular_factor = 0.3 # the amount of the paddle's movement which will go into the ball's spin
# and now for the bouncy-bouncy
ball.hVel += (1 - angular_factor) * paddle.hVel * mass_factor * friction or whatever
ball.spin += angular_factor * paddle.hVel * mass_factor * friction or whatever
ball.vVel = - ball.vVel # of course, its vertical velocity reverses
This will be enough to set up a quasi-realistic bounce, but one nugget remains (which you don't need to adress, but adressing it would make your Arkanoid amazing) -- what happens to all that spin? Can the spin be used somehow for more interesting bounces?
So, to recap, your spin is the speed at which the periphery of the ball is moving relative to the center. Thing is, whenever a spinning ball bounces against something stationary, its spin changes as well as its velocity. If a spinning ball hits a stationary surface, the bal gets a little "kick" in the direction opposite that of its spin (if spin is measured at the point of contact), and the spin will change.
#Upon collision with a surface (assumed horizontal, with the ball above the surface)
ball.hVel += -(ball.Avel * rate) # Where "rate" is the ratio which determines how much angular velocity decays with each bounce
ball.Avel *= 1 - rate # So the angular velocity decays properly
Since angular velocity is rotationally symmetric, you would just treat collisions at different angles (balls on walls, balls on ceilings) as rotations of this.
Phew, that was unintentionally long-winded, and it is nowhere near complete, but it's enough to answer your question IMHO.
I'm having trouble wrapping my mind around how to calculate the normal for a moving circle in a 2d space. I've gotten as far as that I'm suppose to calculate the Normal of the Velocity(Directional Speed) of the object, but that's where my college algebra mind over-heats, any I'm working with to 2d Circles that I have the centerpoint, radius, velocity, and position.
Ultimately I'm wanting to use the Vector2.Reflect Method to get a bit more realistic physics out of this exercise.
thanks ahead of time.
EDIT: Added some code trying out suggestion(with no avail), probably misunderstanding the suggestion. Here I'm using a basketball and a baseball, hence base and basket. I also have Position, and Velocity which is being added to position to create the movement.
if ((Vector2.Distance(baseMid, basketMid)) < baseRadius + basketRadius)
{
Vector2 baseNorm = basketMid - baseMid;
baseNorm.Normalize();
Vector2 basketNorm = baseMid - basketMid;
basketNorm.Normalize();
baseVelocity = Vector2.Reflect(baseVelocity, baseNorm);
basketVelocity = Vector2.Reflect(basketVelocity, basketNorm);
}
basePos.Y += baseVelocity.Y;
basePos.X += baseVelocity.X;
basketPos.Y += basketVelocity.Y;
basketPos.X += basketVelocity.X;
basketMid = new Vector2((basketballTex.Width / 2 + basketPos.X), (basketballTex.Height / 2 + basketPos.Y));
baseMid = new Vector2((baseballTex.Width / 2 + basePos.X), (baseballTex.Height / 2 + basePos.Y));
First the reflection. If I'm reading your code right, the second argument to Vector2.Reflect is a normal to a surface. A level floor has a normal of (0,1), and a ball with velocity (4,-3) hits it and flies away with velocity (4,3). Is that right? If that's not right then we'll have to change the body of the if statement. (Note that you can save some cycles by setting basketNorm = -baseNorm.)
Now the physics. As written, when the two balls collide, each bounces off as if it had hit a glass wall tangent to both spheres, and that's not realistic. Imagine playing pool: a fast red ball hits a stationary blue ball dead center. Does the red ball rebound and leave the blue ball where it was? No, the blue ball gets knocked away and the red ball loses most of its speed (all, in the perfect case). How about a cannonball and a golf ball, both moving at the same speed but in opposite directions, colliding head-on. Will they both bounce equally? No, the cannonball will continue, barely noticing the impact, but the golf ball will reverse direction and fly away faster than it came.
To understand these collisions you have to understand momentum (and if you want collisions that aren't perfectly elastic, like when beanbags collide, you also have to understand energy). A basic physics textbook will cover this in an early chapter. If you just want to be able to simulate these things, use the center-of-mass frame:
Vector2 CMVelocity = (basket.Mass*basket.Velocity + base.Mass*base.Velocity)/(basket.Mass + base.Mass);
baseVelocity -= CMVelocity;
baseVelocity = Vector2.Reflect(baseVelocity, baseNorm);
baseVelocity += CMVelocity;
basketVelocity -= CMVelocity;
basketVelocity = Vector2.Reflect(basketVelocity, basketNorm);
basketVelocity += CMVelocity;
The normal of a circle at a given point on its edge is going to be the direction from its center to that point. Assuming that you're working with collisions of circles here, then one easy "shorthand" way to work this out would be that at the time of collision (when the circles are touching), the following will hold true:
Let A be the center of one circle and B the center of the other. The normal for circle A will be normalize(B-A) and the normal for circle B will be normalize(A-B). This is true because the point where they touch will always be colinear with the centers of the two circles.
Caveat: I'm not going to assume that this is completely correct. Physics are not my specialty.
Movement has no effect on a normal. Typically, a normal is just a normalized (length 1) vector indicating a direction, typically the direction that a poly faces on a 3d object.
What I think you want to do is find the collision normal between two circles, yes? If so, one of the cool properties of spheres is that if you find the distance between the centers of them, you can normalize that to get the normal of the sphere.
What seems correct for 2d physics is that you take the velocity * mass (energy) of a sphere, and multiply that by the normalized vector to the other sphere. Add the result to the destination sphere's energy, subtract it from the original sphere's energy, and divide each, individually, by mass to get the resulting velocity. If the other sphere is moving, do the same in reverse. You can probably simplify the math down from there, of course, but it's late and I don't feel like doing it :)
If both spheres are moving, repeat the process for the other sphere (though you could probably simplify that equation to get some more efficient math).
This is just back-of-the-napkin math, but it seems to give the correct results. And, hey, I once derived Euler angles on my own, so sometimes my back-of-the-napkin math actually works out.
This also assumes perfectly elastic collisions.
If I'm incorrect, I'd be happy to find out where :)