I'm trying to get my box2d box to bounce when hitting another box2d box. The physical properties to both objects are set thus..
fixtureDef.density=1;
fixtureDef.friction=0;
fixtureDef.restitution=0.9;
And when I apply this line (which is meant to be the correct way of doing things) I get no bounce.
myElementsArray[0].myPhysics.myBody.ApplyImpulse(newVec, myElementsArray[0].myPhysics.myBody.GetWorldCenter());
But when I change the 2nd, part to some random vector, it bounces
myElementsArray[0].myPhysics.myBody.ApplyImpulse(newVec, new b2Vec2(20,20));
Which I don't get, what am I doing wrong?
The "bounce" you are seeing is probably a bit deceptive. I'm not a physics guru, I only know enough be dangerous as my main focus is game programming. Anyway here goes, the first statement uses the center of mass to apply the force to. When you are calculating a "bounce" using restitution, in most physics libraries it would very simply grab the largest restitution between the two collision objects:
restitution = Max( bodyA.restitution, bodyB.restitution )
Then disregarding torque, the new differential final velocities with respect to the restitution is:
–restitution * (bodyA.initialVelocity - bodyB.initialVelocity)
This is also more standardly written as:
–e(V1i - V2i)
Why is this important? Because this is probably the reason you are not seeing a bounce, the two initial velocities (without torque) are zeroing out. Now the second call to ApplyImpulse() uses a coordinate that is not the center of mass of the body. Because of this, Box2D is going to attempt to apply an angular velocity to the body. With that in mind a new series of equations will be used. I'm fairly confident that is where the problem resides, but someone else might correct me or know more about it.
I'm trying to add specular reflections to a Stage3D game and it is ALMOST working, but I don't think I have a good enough grasp of the maths happening at the actual reflection stage.
I have an incoming light vector and I have the face normal; I know what to do with the resulting reflected vector (normalize and then dot product with the normalized vector pointing to the player 'camera') but what are the AGAL opcodes to reflect the original light vector off the face? I can't get my head around that. Any help appreciated...
Unlike GLSL with its reflect(), AGAL does not have any kind of helper for doing this. But you can still calculate reflection vector yourself - even GLSL reference page for reflect() mentions the formula used for calculation:
For a given incident vector I and surface normal N reflect returns the reflection direction calculated as I - 2.0 * dot(N, I) * N.
I'm implementing a simple penalty shootout game using actionscript 3.0. The view of the game is similar to view of the old "Sensible World of Soccer". I want to use 3d game logic by using dimension z as I think that it could help me in order to achieve better collision detection - response results. However, I would like to keep the graphics style and view equivalent to old 2d soccers'. Hence, I assume that orthographic projection is suitable for this implementation. Although there is plenty of information in the internet regarding orthographic projection, I'm a little bit confused about how someone can apply it in his/her code.
So my questions are:
Which is the procedure step by step in order for someone to convert a 3d (x, y, z) point to 2d (x', y') point in orthographic projection?
Can we avoid using matrices? If yes, what are the equations that associate coordinates x', y' with x, y, z?
Do we have to define a camera position and angle before applying the conversion? In my case, camera will be in a fixed position and angle.
DisplayObjects and their descendants (ie MovieClip and Sprite) have a z property you can use to do this without the headaches - they also have rotationX/Y/Z and scaleX/Y/Z properties too!
Using 'z' will adjust the position and scale of an object accordingly (though it will convert vectors to bitmaps), there's no depth sorting, so it will stay on top of objects even if its z co-ord suggests it should be behind them, but for the project you have in mind I can't see this being a problem - it's pretty easy to fix anyway, have an array of objects in the scene, sort it according to z-position and reset the depth index of each/re-add to stage in sorted order.
You can use the perspectiveProjection member of a clip to adjust the FOV, origin etc -
Perspective Tutorial
..but you don't need to get any more sophisticated than that. Certainly you don't need to dabble with matrices with a fixed camera view, even if you wanted to calculate this manually as an experiment.
Hope this helps
Im not sure how to use vectors correctly in game programming. I have been reading advanced game design with flash which shows you how to create a vector with a start point and endpoint and how to use that for games, for example the start point would be used for a characters position in a game and the x and y length would be used for velocity. But since I have started looking online I have found that vectors are usually just x and y with no start point or end point and a character would be moved by having a position vector and a velocity vector and acceleration vector. I have started creating my own vector class. And wondered what the reasons for and against each method are. Or is it completely not important?
Initially a vector means direction. Classical vector is used in physics to present a velocity so that the vector direction stands for the heading and the vector length is a speed.But in graphics vectors are used also to present position. So if you have some point, let's say, in 2d space noted by x ,y it remains point if you don't want to know in what direction it set relating to the origin which is usually a center of the coordinate system. In 2d graphics we deal with Cartesian coordinate system which has an origin in top left corner of the screen. But you can also have a direction of some vector relative to any other point in the space.That is why you have also vector operations like addition, subtracting ,dot product, cross product. All those help you to measure distances and angles between vectors. I would suggest you to buy a book on graphics programming. Most of them introduce an easy to grasp primer to vector math.And you don't need to write a vector class in AS 3.0 You have a generic one - Vector3d
Does anyone have any good references for equations which can be implemented relatively easily for how to compute the transfer of angular momentum between two rigid bodies?
I've been searching for this sort of thing for a while, and I haven't found any particularly comprehensible explanations of the problem.
To be precise, the question comes about as this; two rigid bodies are moving on a frictionless (well, nearly) surface; think of it as air hockey. The two rigid bodies come into contact, and then move away. Now, without considering angular momentum, the equations are relatively simple; the problem becomes, what happens with the transfer of angular momentum between the bodies?
As an example, assume the two bodies have no angular momentum whatsoever; they're not rotating. When they interact at an oblique angle (vector of travel does not align with the line of their centers of mass), obviously a certain amount of their momentum gets transferred into angular momentum (i.e. they each get a certain amount of spin), but how much and what are the equations for such?
This can probably be solved by using a many-body rigid system to calculate, but I want to get a much more optimized calculation going, so I can calculate this stuff in real-time. Does anyone have any ideas on the equations, or pointers to open-source implementations of these calculations for inclusion in a project? To be precise, I need this to be a rather well-optimized calculation, because of the number of interactions that need to be simulated within a single "tick" of the simulation.
Edit: Okay, it looks like there's not a lot of precise information about this topic out there. And I find the "Physics for Programmers" type of books to be a bit too... dumbed down to really get; I don't want code implementation of an algorithm; I want to figure out (or at least have sketched out for me) the algorithm. Only in that way can I properly optimize it for my needs. Does anyone have any mathematic references on this sort of topic?
If you're interested in rotating non-spherical bodies then http://www.myphysicslab.com/collision.html shows how to do it. The asymmetry of the bodies means that the normal contact force during the collision can create a torque about their respective CGs, and thus cause the bodies to start spinning.
In the case of a billiard ball or air hockey puck, things are a bit more subtle. Since the body is spherical/circular, the normal force is always right through the CG, so there's no torque. However, the normal force is not the only force. There's also a friction force that is tangential to the contact normal which will create a torque about the CG. The magnitude of the friction force is proportional to the normal force and the coefficient of friction, and opposite the direction of relative motion. Its direction is opposing the relative motion of the objects at their contact point.
Well, my favorite physics book is Halliday and Resnick. I never ever feel like that book is dumbing down anything for me (the dumb is inside the skull, not on the page...).
If you set up a thought problem, you can start to get a feeling for how this would play out.
Imagine that your two rigid air hockey pucks are frictionless on the bottom but have a maximal coefficient of friction around the edges. Clearly, if the two pucks head towards each other with identical kinetic energy, they will collide perfectly elastically and head back in opposite directions.
However, if their centers are offset by 2*radius - epsilon, they'll just barely touch at one point on the perimeter. If they had an incredibly high coefficient of friction around the edge, you can imagine that all of their energy would be transferred into rotation. There would have to be a separation after the impact, of course, or they'd immediately stop their own rotations as they stuck together.
So, if you're just looking for something plausible and interesting looking (ala game physics), I'd say that you could normalize the coefficient of friction to account for the tiny contact area between the two bodies (pick something that looks interesting) and use the sin of the angle between the path of the bodies and the impact point. Straight on, you'd get a bounce, 45 degrees would give you bounce and spin, 90 degrees offset would give you maximal spin and least bounce.
Obviously, none of the above is an accurate simulation. It should be a simple enough framework to cause interesting behaviors to happen, though.
EDIT: Okay, I came up with another interesting example that is perhaps more telling.
Imagine a single disk (as above) moving towards a motionless, rigid, near one-dimensional pin tip that provides the previous high friction but low stickiness. If the disk passes at a distance that it just kisses the edge, you can imagine that a fraction of its linear energy will be converted to rotational energy.
However, one thing you know for certain is that there is a maximum rotational energy after this touch: the disk cannot end up spinning at such a speed that it's outer edge is moving at a speed higher than the original linear speed. So, if the disk was moving at one meter per second, it can't end up in a situation where its outer edge is moving at more than one meter per second.
So, now that we have a long essay, there are a few straightforward concepts that should aid intuition:
The sine of the angle of the impact will affect the resulting rotation.
The linear energy will determine the maximum possible rotational energy.
A single parameter can simulate the relevant coefficients of friction to the point of being interesting to look at in simulation.
You should have a look at Physics for Game Developers - it's hard to go wrong with an O'Reilly book.
Unless you have an excellent reason for reinventing the wheel,
I'd suggest taking a good look at the source code of some open source physics engines, like Open Dynamics Engine or Bullet. Efficient algorithms in this area are an artform, and the best implementations no doubt are found in the wild, in throroughly peer-reviewed projects like these.
Please have a look at this references!
If you want to go really into Mecanics, this is the way to go, and its the correct and mathematically proper way!
Glocker Ch., Set-Valued Force Laws: Dynamics of Non-Smooth Systems. Lecture Notes in Applied Mechanics 1, Springer Verlag, Berlin, Heidelberg 2001, 222 pages. PDF (Contents, 149 kB)
Pfeiffer F., Glocker Ch., Multibody Dynamics with Unilateral Contacts. JohnWiley & Sons, New York 1996, 317 pages. PDF (Contents, 398 kB)
Glocker Ch., Dynamik von Starrkörpersystemen mit Reibung und Stößen. VDI-Fortschrittberichte Mechanik/Bruchmechanik, Reihe 18, Nr. 182, VDI-Verlag, Düsseldorf, 1995, 220 pages. PDF (4094 kB)