|
|
|
This thread is locked; no one can reply to it.
|
1
2
|
| Angles, how i hate them... |
|
Elias
Member #358
May 2000
|
Thanks for the link to that article, it really looks great When I saw you were talking about Euler integration.. I remembered, some time back when I tried making a simple car game, someone (on comp.sci.physics i think) told me Euler integration can't be used because it takes too much CPU time when you want get things like sliding and skipping right. I forgot how the other technique is called he told me to use, but it was too complicated for me and I gave up on it. (it was called Runge-Kutta or Lagrange or somethinkg like that..) But now it seems, Euler integration (or the one mentioned in that article) is the best way after all, if even you people are using it -- |
|
Shawn Hargreaves
The Progenitor
April 2000
 |
The physics for all our games at Climax are based on a library called Dyne, written by Chris Caulfield (who previously did the physics for Revolt). It is fairly accurate, but not as sophisticated as the Revolt physics, for instance Dyne doesn't handle stacking multiple objects on top of each other very well (but runs in far less CPU, which is more important :-) Good game physics is a matter of getting a solid core (because it tends to feel nice if the behaviour is close to how the real world behaves), but then add lots of special case bodges over the top. For instance in MotoGP things like the wheelies and skids and spinning the rear wheel are total hacks added by George, nowhere near to being handled properly by the underlying physics layer, but these things are often the most fun and the bits that make people say the physics seems very realistic! So don't be afraid to mix and match proper physics simulations with special-case behaviours, and don't believe people who insist you need to use all those stupidly complicated techniques (you may need them in some cases, but if a simpler method is adequate for your task, you may as well use it and save yourself the hassle and CPU...) |
|
Matt Smith
Member #783
November 2000
|
If you've seen my Speedhack entry you'll know that
Angles have their uses for simple games, because in asm sin/cos are very cheap operations compared to the mul/div for normalising. In asm you have a table with a sine wave (cos uses the same table with a 90° phase shift) so you can turn an angle into a vector extremely quickly if you don't need high precision. |
|
Paul Pridham
Member #250
April 2000
 |
These conversations need to go into a FAQ. ---- |
|
Shawn Hargreaves
The Progenitor
April 2000
|
MattSmith writes: Rebounding off spheres is still much easier to do with vectors and dot products than it is with angles :-) > Angles have their uses for simple games, So what? Multiplies and divides are cheap, and CPU manufacturers have spent the last five years or so concentrating on ways to make vector math fast. Plus you can't do inverse tangents as lookup tables, which you will need for anything more than very trivial trig calculations. For anything even approaching an interesting level of complexity (ie. with more than one single force acting on objects, or with collision against diagonal lines, or in 3D), a vector approach will be most efficient, and if your application is so simple that just one angle and lookup table trig is sufficient, it really doesn't matter if you can shave a few cycles off by using an integer lookup rather than a multiply because it's going to run plenty fast enough anyway. It's one thing to support slow machines, but optimising to avoid multiplies hasn't made sense since 286 days! |
|
Bob
Free Market Evangelist
September 2000
 |
Quote: Multiplies and divides are cheap,
Multiplies? Yes. Divides? Hell no -- |
|
Shawn Hargreaves
The Progenitor
April 2000
|
> Multiplies? Yes. Divides? Hell no They aren't cheap if you're counting cycles in a per-pixel inner loop, but everything is relative. In the context of a physics system, they are incredibly cheap compared to most of the other things you will be doing! (which is probably going to be limited by the number of square roots and possibly memory access for collision checking). It's still worth avoiding stupid numbers of divides, but I think taking things way too far if you design the whole system around that avoidance. You'd have to work pretty hard to make divides be the performance bottleneck. |
|
Thomas Harte
Member #33
April 2000
 |
Quote: But acceleration is often a constant, Linear acceleration due to gravity may be, but what about, e.g., angular acceleration due to gravity + an acceleration point on the body such as a jet pack or something? [My site] [Tetrominoes] |
|
Bob
Free Market Evangelist
September 2000
|
I guess the lesson is: Shawn Is Always Right -- |
|
Zaphos
Member #1,468
August 2001
|
"Bouncing off walls is just a dot product"? In my speedhack game (Balls) I used a rotation matrix to rotate the speed vector for my ball to the angle of the line it was colliding with, changed y to -y * some_fraction, and then used the inverse rotation matrix to convert back to the standard coordinate system. Is there a better way to do that?
|
|
sicgamemaker
Member #1,365
June 2001
 |
see that... tahts the whole reason i havent messed with vectors...i dont understand a thing zaphos said _______________________ |
|
23yrold3yrold
Member #1,134
March 2001
 |
Well, to be fair, he didn't say it to be understood. He just made a quick summary, knowing well and good that gurus like Shawn and Bob would understand -- |
|
Bruce Perry
Member #270
April 2000
|
Hey, what about me? Zaphos: yep, vectors make it a whole lot easier. No rotation required. All you need is a vector (i.e. three numbers, (x,y,z), or two if you're in 2D) which points straight out of the surface you're bouncing off - that's a normal vector. Then it has to be normalised (x*x + y*y [+ z*z] = 1); you can do this by dividing each term by sqrt(x*x+y*y[+z*z]). Calculate the dot product of this normal vector and your velocity vector, and you should get a negative number. The fact that it's negative means the ball is moving into the surface (opposite the normal vector) rather than out. Its value indicates how fast, ignoring sideways velocity. Then you multiply it by the normal vector, subtract it from the velocity, and all of a sudden your ball isn't moving into the wall any more - it's moving along the wall. Subtract it again (or subtract it once but multiply by two first), and it's bounced! I just explained the same thing as Shawn but slightly differently. Shawn's explanation is more formal, whereas mine's just rushed -- |
|
Shawn Hargreaves
The Progenitor
April 2000
|
Like Ben said :-) It's the same thing as Zaphos's matrix technique, just a lot less code if you do it with a dot product. For a really simple example, take a look at arrow.cpp from my Cupid speedhack entry, lines 35+36. The collision check returns the normal of the barrier it hit, plus a distance value indicating how far we are on the wrong side of the barrier we are. Line 35 pulls the object back onto the correct side of the collision, and line 36 changes the velocity to make it bounce. |
|
Thomas Harte
Member #33
April 2000
|
Returning to my own private strand of this conversation, what about the fairly common acceleration due to being attached to a spring - will anyone claim this is 'constant'? [My site] [Tetrominoes] |
|
Bob
Free Market Evangelist
September 2000
|
Ok, constant acceleration doesn't apply in all cases obviously. However, it is constant in most game-related situations (unless your game involves a lot of springs...). -- |
|
Damyan Pepper
Member #2,181
April 2002
 |
I'm getting confused with all this constant acceleration stuff. Surely a game with constant acceleration would be extremely dull! |
|
George Foot
Member #669
September 2000
|
The main thing is that there's no accumulation of acceleration. Technically acceleration is the integral of jerk, but this isn't generally a useful way of viewing it -- in the real world, objects are influenced primarily by forces being applied, which map directly to acceleration. Translating that into the game world, it's far simpler to recalculate all forces applied to an object (including those due to springs, based on extension of spring) for each frame, and set the acceleration to that total (divided by mass, if applicable). Technically it's also not sufficient to just add this stuff up -- you ought to be multiplying in some time deltas too -- but if your update loop runs at a constant rate and you'll never change that rate then this doesn't matter. If you do want to change that rate, you want to do this: acc = force / mass; vel += acc * dt + impulse / mass; pos += vel * dt + extraction; or if you're tracking momentum: momentum += force * dt + impulse; vel = momentum / mass; pos += vel * dt + extraction;
|
|
Zaphos
Member #1,468
August 2001
|
Shawn & Ben: Thank you kindly
|
|
|
1
2
|
Still, I hope that clears things up.