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)
Related
I'm trying to make a basic first person shooter game with Bullet and OpenGL. I'm having the issue of my rigid bodies not colliding at high speed.
My bullets will go straight through any other rigid bodies that I have, such as walls. Reducing velocity to less than 10 does result in collisions, but this is too low for a moving bullet. The bullet also moves insanely fast (I know it's a fast moving bullet, but sometimes I can't even see it, not sure if that's expected).
I'm thinking that it's to do with how I'm stepping the simulation? Reading up on it has left me confused. How can I make it so that my objects will always collide (at least, when going reasonably fast), and if possible, is there a way to slow the simulation down whilst maintaining the correct bullet velocity etc. so that I can actually see the bullet moving and colliding?
Here are some approaches to solve:-
It is copied from How can I avoid missing collisions for fast moving objects? - an official FAQ
smaller timesteps
extruding the object along the motion
ray cast to the new position
swept collision test (convex cast, linear cast)
continuous collision detection, including rotational motion
Please read the link for more detail. It is not a trivial issue.
One important thing to ask before try anything: do you really need high speed object?
It is not free (cost more CPU).
Here is another useful link (less useful though) : https://gamedev.stackexchange.com/questions/11961/how-can-i-enable-ccd-in-bullet-physics
One pet peeve I have with a lot of older rock music records from the 60's and 70's
is they sometimes are slightly of of tune with the standard a440 reference pitch, so playing along on my guitar sounds bad. Right now I manually adjust the pitch of the track by ear in Audacity, but this often takes some time. I was hoping there was something out there that could detect the frequency of the first few notes of a music file, analyze that and see how far it is from any standard A440 note, and then you could use that number to determine how much you needed to make the track sharp or flat to match A440 tuning.
Is it possible to create an app that automatically retunes slightly out-of-tune music to be A440 with Javascript?
Yes. Check out this pitch detection demo by Chris Wilson.
There are some big caveats though, and they don't really have anything to do with JavaScript.
Voice Selection
What instruments do you care about? Obviously wideband stuff like percussion is atonal... but it's still going to turn up in your audio, and will have a pitch. How about the difference between a voice and wind instruments? A lot of vocalists will go off pitch intentionally. You will need to use bandpass fliters to get the range you care about, at a minimum.
Original Intonation
What about the instruments being in tune in the first place? "Another one bites the dust" comes to mind as a rock record from the 70s that starts off terribly out of tune... and maybe intentionally.
Pyscoacoustics and Harmonics
Sometimes we hear things that aren't really there. If I play a trombone down a scale, to the very bottom of its range, it will actually stop producing a fundamental... yet because I was playing a familiar scale downward, us humans will still perceive one. This might not throw off your detection by a lot, but it will somewhat, particularly on those atonal-but-not-really percussion instruments.
In summary, this is possible but it's going to be a lot of work. Please come back and post a link once you've done this!
I'm attempting to write a short mini-program in Python that plays around with force-based algorithms for graph drawing.
I'm trying to minimize the number of times lines intersect. Wikipedia suggests giving the lines an electrical charge so that they repel each other. I asked my physics teacher how I might simulate this, and she mentioned using calculus with Coulomb's Law, but I'm uncertain how to start.
Could somebody give me a hint on how I could do this? (Or alternatively, another way to tweak a force-based graph drawing algorithm to minimize the number of times the lines cross?) I'm just looking for a hint; no source code please.
In case anybody's interested, my source code and a youtube vid I made about it.
You need to explicitly include a term in your cost function that minimizes the number of edge crossings. For example, for every pair of edges that cross, you incur a fixed penalty or, if the edges are weighted, you incur a penalty that is the product of the two weights.
I can see how this might not be a good enough question but I have just embarked on a journey to build the first decent Game Engine for HTML5 canvas that is cross browser and most of all fast. The only problem is I am very new to game design and don't know many tricks of the trade that will help me.
The game I am currently implementing for which the engine will be taken out of is a tile based 2D platformer with MANY tiles (around 3500). I'll start with some tips that I've thus far learnt.
Redraw Regions - only redraw areas that change
Avoid unnecessary function calls (Firefox does not like too many of them)
Use the DOM if you can
Chunk tiles together for quicker access
Other things I am looking for are things like Terrain Generation, Lighting in 2D, Maps, quick server communication. If this is too vague, I will try and close it. Just want to know game design better.
Links/resources would be good. Especially for physics or important maths.
Only draw stuff that's visible, that means only draw the tiles etc. that are currently on the screen. For tiles that's fairly easy, if you got lots of entities you may either want to use a sliding window to keep a list of screen local objects or use such a thing like a quadtree.
Since there's no easy/fast way to copy one canvas to another, redrawing regions is really complicated, since you can't keep a buffered state of (for example) the background if it hasn't changed. So keeping a list of "dirty rectangles" will be a computational overhead for sure.
The whole topic is very broad, even handling the FPS rate can be quite difficult, this question contains some good links and answers on that topic:
https://gamedev.stackexchange.com/questions/1589/fixed-time-step-vs-variable-time-step
You've also mentioned server communication, if you want to do some multiplayer you'll have to care about even more stuff, you can't trust the client, need to worry about bandwidth, synchronization issues, interpolation on the client etc.
I've done some rather simple 2D games in the past, most of them are not in JavaScript but they should give you some hints:
http://github.com/BonsaiDen/Norum
(Platformer engine demo in C, camera zones, moving platforms)
http://github.com/BonsaiDen/Tuff
(2D Platformer in Java, got never finished, powerups and some cool stuff)
http://github.com/BonsaiDen/NodeGame-Shooter
(2D multiplayer space shooter written in JS, using Node.js for the server and WebSockets for communication)
For some final words I'd say that you should start small, like for example just do a scrolling tile map first, then add a player, then rewrite the whole thing. You want write the perfect engine just from scratch it will take many iterations until you find out all the quirks and tricks.
If you want more precise answers you should open questions on the single components you run into troubles with.
while playing to this game I wondered how an AI controlling either the detectives either the criminal could work.
For lazy people the aim of the game is simple:
the board game is an undirected graphs that has 4 kinds of edges (that can also overlap for same pair or vertices), each kind is a type of transport that requires a specific kind of ticket
detectives have a bunch of tickets to move around this graph, one move per turn (which means from a node to another node). The criminal can do the same set of moves (plus 3 exclusive paths) but with no limits on tickes
the criminal is usually hidden to detectives but it has to show up himself in 5 specific turns (and then hide again)
if detectives are able to catch him (one of them must occupy the same cell of the criminal) before 24 moves then they win, otherwise the criminal wins
the criminal has to show which ticket he uses each turn but he also has 1 black ticket per detective (let's assume 5) that can be used to vanify this thing
the criminal also has two 2x tickets that allow him to use two tickets (and so two movements) in the same turn
I can think effectively about an AI for the criminal that it would be just a minmax tree that tries to choose movements that maximize the number of moves needed by detectives to reach him (it seems to be a good metric) but I cannot think anything enough cool for detectives which should cooperate and try to guess where the criminal can be by looking at tickets it uses.
It's just for fun but do you now any cool ideas to work out something quite clever?
You've asked how to model this, not how to solve this efficiently:
It can be easily modeled as a partially observable markov decision process (wiki link). This works both for the detectives and the criminal. POMDPs are a very generic model.
I love this game, and I think for the detectives you want to model the probability that the criminal is at each location. Every once in a while you know the exact position of the criminal, and then you can take into account the following moves he makes to determine which spots he could possibly be at.
Once you have this, I'm not quite sure how to optimize the detectives moves. You can move the detectives to reduce the set of possibilities, effectively corraling the criminal. But I'm sure there is also some higher level strategy needed surrounding the tickets and not running out of them.
I'd imagine some kind of a monte carlo implementation would be an excellent candidate for this, ie. simulating thousands of combinations and choosing the one that ends with the best result most of the time. Since the criminal has to be visible for 5 turns, the branching factor should stay well under control, although MC has also been shown to be a very good technique in games of high branching factor, ie. Go.
In order to get teamwork going between the detectives you need to model them as a team rather than as individuals. Minimax is still a good way to go but (sadly) your branching factor is going to soar.
Instead of stepping through all the detectives making what appears to be the best for each instead for your team of detectives you work out each permutation of moves they could make. If teamwork helps in this game then the minimax will favour the permutations in which the detectives are working together.
I'm not sure if it will be practical, 5 detectives for 24 ply might be too much work but it'd be fun to try and that's the point right?