like many others before, I'm coding a 2D platformer at the moment, or more precise on an Engine for that. My question is about collision detection and especially the reactions to collision.
It's vital to me to have surfaces that are NOT tile based, because the world of the platformer has urgend need of surfaces that are not straight.
What do you think is the best approach for implementing such?
I've already come to a solution, but I'm only about 95% satisfied with it.
My Entity is component based so at first it calculates all the movement. Horizontal position change. Falling. Jumping speed; all that. Then it stores these values temporarily; accessible to the Collision component.
This one adds 4 hitpoints to the entity. Two for the floor collision and two for the wall collision.
Like this
(source: fux-media.com)
I first check against the floor. When there IS collision, I iterate collision detections upwards until there is no more collision.
The I reset the Entity to this point. If both ground hitpoints collide, I reset the Entity to the lowest point to avoid the Entity floating in the air.
Then I check against the wall with the upper hitpoints. Basically, if it collides, I do the same thing as above, just horizontally.
If works quite well. Very heavy ascensions are treated like a wall and very low ascensions are just climbed. But in between, when the ascensions are around 45 degree, it behaves strange. It does not quite feel right.
Now, I could just avoid implementing 45 degree walls in my game, but that would just not be clean, as I'm programming an engine that is supposed to work right no matter what.
So... how would you implement this, algorithmically?
I think you're on the right track with the points. You could combine those points to form a polygon, and then use the resulting polygon to perform collision detection.
Phys2D is a library that happens to be in Java that does collision between several types of geometric primitives. The site includes downloadable/runnable demos on what the library is capable of.
If you look around, you can find 2D polygon collision detection implementations in most common languages. With some study, an understanding of the underlying geometry calculations, and some gusto, you could even write your own if you like.
Related
I hope that this is the correct place to ask this kind of question. I am developing a web app to design garden ponds and I need to calculate the shape and size of the foil needed to cover that pond. The pond will provided as a 3D model (threeJS). The shape of the pond will be relatively simple (think one or more rectangular boxes potentially with some stairs).
I am considering folding out the surface of the 3D model into a flat shape, but I do not know how to do that in a generic way. And even if a could od that it would not be the complete solution (but potentially it would be a starting point) I have been searching for a generic algorithm to do this, but so far have not found anything. Does anyone know of an algorithm that I could use for this, or at least something that I could start with.
Some additonal information:
this will be a browser based solution which should show the pool; one option would be ThreeJS since I am somewhat familiar with it
the foil that should cover the pond needs to watertight, so it needs to be one piece. That means that when your put it in the pool, it form rinkle, especially in the corners.
Using spherical nodes, cylindrical bones, and cone-twist constraints, I've managed to create a simple skeleton in 3 dimensions. I'm using an offshoot of the bullet physics library (physijs by #chandlerprall, along with threejs).
Now I'd like to add muscles. I've been trying for the last two days to get some sort of sliding constraint or generic 6-DOF constraint to get the muscle to be able to contract and pull its two nodes towards one another.
I'm getting all sorts of crazy results, and I'm beginning to think that I'm going about this in the wrong way. I don't think I can simply use two cone twist constraints and then scale the muscle along its length-wise axis, because scaling collision meshes is apparently fairly expensive.
All I need is a 'muscle' which can attach to two nodes and 'contract' to pull in both its nodes.
Can anyone provide some advice on how I might best approach this using the bullet engine (or really, any physics engine)?
EDIT: What if I don't need collisions to occur for the muscle? Say I just need a visual muscle which is constrained to 2 nodes:
The two nodes are linearly constrained to the muscle collision mesh, which instead of being a large mesh, is just a small one that is only there to keep the visual muscle geometry in place, and provide an axis for the nodes to be constrained to.
I could then use the linear motor that comes with the sliding constraint to move the nodes along the axis. Can anyone see any problems with this? My initial problem is that the smaller collision mesh is a bit volatile and seems to move around all over the place...
I don't have any experience with Bullet. However, there is a large academic community that simulates human motion by modeling the human as a system of rigid bodies. In these simulations, the human is actuated by muscles.
The muscles used in such simulations are modeled to generate force in a physiological way. The amount of force a muscle can produce at any given instant depends on its length and the rate at which its length is changing. Here is a paper that describes a fairly complex muscle model that biomechanists might use: http://nmbl.stanford.edu/publications/pdf/Millard2013.pdf.
Another complication with modeling muscles that comes up in biomechanical simulations is that the path of a muscle must be able to wrap around joints (such as the knee). This is what you are trying to get at when you mention collisions along a muscle. This is called muscle wrapping. See http://www.baylor.edu/content/services/document.php/41153.pdf.
I'm a graduate student in a lab that does simulations of humans involving many muscles. We use the multibody dynamics library (physics engine) Simbody (http://github.com/simbody/simbody), which allows one to define force elements that act along a path. Such paths can be defined in pretty complex ways: they could wrap around many different surfaces. To simulate muscle-driven human motion, we use OpenSim (http://opensim.stanford.edu), which in turn uses Simbody to simulate the physics.
I have a general questions regarding techniques, or approaches used in computer games to detect particles (or objects collisions). Even in a smiple examples, like currently popular angry birds, how is it programmetically achieved that the game knows that an object hits another one and works out it trajectory, while this object can hit others etc. I presume it is not constantly checking states of ALL the objects in the game map...
Thanks for any hints/answers and sorry for a little dummy/general question.
Games like Angry Birds use a physics engine to move objects around and do collision detection. If you want to learn more about how physics engines work, a good place to start is by reading up on Box2D. I don't know what engine Angry Birds uses, but Box2D is widely used and open-source.
For simpler games however you probably don't need a physics engine, and so the collision detection is fairly simple to do and involves two parts:
First is determining which objects to test collision between. For many small games it is actually not a bad idea to test every single object against every other object. Although your question is leery of this brute-force approach, computers are very fast at routine math like that.
For larger scenes however you will want to cull out all the objects that are too far away from the player to matter. Basically you break up the scene into zones and then first test which zone the character is in, then test for collision with every object in that zone.
One technique for doing this is called "quadtree". Another technique you could use is Binary Space Partitioning. In both cases the scene is broken up into a lot of smaller pieces that you can use to organize the scene.
The second part is detecting the collision between two specific objects. The easiest way to do this is distance checks; just calculate how far apart the two objects are, and if they are close enough then they are colliding.
Almost as easy is to build a bounding box around the objects you want to test. It is pretty easy to check if two boxes are overlapping or not, just by comparing their coordinates.
Now bounding boxes are just rectangles; this approach could get more complex if the shapes you want to collide are represented by arbitrary polygons. Some basic knowledge of geometry is usually enough for this part, although full-featured physics engines can get into a lot more detail, telling you not just that a collision has happened, but exactly when and how it happened.
This is one of those hard to answer questions here, but here's a very basic example in 2D as a very basic example, in pseudo-code.
for-each sprite in scene:
for-each othersprite in scene:
if sprite is not othersprite & sprite.XY = othersprite.XY
collision = true;
else
collision = false;
Hopefully that should be enough to get your thought muscles working!
Addendum: Other improvements would be to assume an area around the XY instead of a precise location, which then gives you a sort of support for sprites with large areas.
For 3D theory, I'll give you the article I read a while ago:
http://www.euclideanspace.com/threed/animation/collisiondetect/index.htm
num1's answer covers most of what I would say and so I voted it up. But there are a few modifications/additional points I would make:
1) Bounding boxes are actually the second easiest way to test collision. The easiest way is distance checks; just calculate how far apart the two objects are, and if they are close enough then they are colliding.
2) Another common way of organizing the scene in order to optimize collision tests (ie. an alternative to BSP) is quadtrees. In either case, basically you break up the scene into zones and then first test which zone the character is in, then test for collision with every object in that zone. That way if the level is huge you don't test against every single object in the level; you can cull out all the objects that are too far away from the player to matter.
3) I would emphasize more that Angry Birds uses a physics engine to handle its collisions. While distance checks and bounding boxes are fine for most 2D games, Angry Birds clearly did not use either of those simple methods and instead relied on collision detection from their physics engine. I don't know what physics engine is used in that game, but Box2D is widely used and open-source.
Ok so I have bunch of balls:
What I'm trying to figure out is how to make these circles:
Rotate based on the surfaces they are touching
Fix collision penetration when dealing with multiple touching objects.
EDIT: This is what I mean by rotation
Ball 0 will rotate anti-clockwise as it's leaning on Ball 3
Ball 5 will rotate clockwise as it's leaning on Ball 0
Even though solutions to this are universal, just for the record I'm using Javascript and SVG, and would prefer implementing this myself rather than using a library.
Help would be very much appreciated. Thanks! :)
Here are a few links I think would help you out on your quest:
Box2D
Advanced Character Physics
Javascript Ball Simulation
Box2D has what your looking for, and its open source I believe. You can download the files and see how they do what they do in order to achieve your effect.
Let me know if this helps, trying to get better at answering questions on here. :)
EDIT:
So I went ahead and thought this out just a bit more to give some insight as far as how I would approach it. Take a look at the image below:
Basically, compare the angles on a grid, if the ball is falling +30 degrees compared to the ball it falls on then rotate the ball positively. If its falling -30 degrees compared to the ball it fall on then rotate the ball negatively. Im not saying this is the correct solution, but just thinking about it, this is the way I would approach the problem off the bat.
From a physics standpoint it sounds like you want to conserve both linear and angular momentum.
As a starting point, you'll want establish ODE matrices that model both and then perform some linear algebra to solve them. I personally would use Numpy/Scipy (probably using a sparse array) for that solution. But there are many approaches (sympy comes to mind). What modules do you want to use?
You'll want to familiarize yourself with coefficient of restitution and coefficient of friction and decide if you want to conserve kinetic energy too. (do you want/care if they keep bouncing and rolling around forever?) (you'll probably need energy matrices as well)
You'll be solving these matrices every timestep all the while checking the condition that no two ball centers are closer than the sum of the two radii. (..and if they do, you adjust the momentum and energy terms for a post-collision condition)
This is just the barest of beginnings to a big project. Can I ask why you want to do this from scratch?
I would recommend checking out game physics simulation books and articles. See O'Reilly's Physics for Game Developers and the Gamasutra website, for example.
I'v always wondered this. In a game like GTA where there are 10s of thousands of objects, how does the game know as soon as you're on a health pack?
There can't possibly be an event listener for each object? Iterating isn't good either? I'm just wondering how it's actually done.
There's no one answer to this but large worlds are often space-partitioned by using something along the lines of a quadtree or kd-tree which brings search times for finding nearest neighbors below linear time (fractional power, or at worst O( N^(2/3) ) for a 3D game). These methods are often referred to as BSP for binary space partitioning.
With regards to collision detection, each object also generally has a bounding volume mesh (set of polygons forming a convex hull) associated with it. These highly simplified meshes (sometimes just a cube) aren't drawn but are used in the detection of collisions. The most rudimentary method is to create a plane that is perpendicular to the line connecting the midpoints of each object with the plane intersecting the line at the line's midpoint. If an object's bounding volume has points on both sides of this plane, it is a collision (you only need to test one of the two bounding volumes against the plane). Another method is the enhanced GJK distance algorithm. If you want a tutorial to dive through, check out NeHe Productions' OpenGL lesson #30.
Incidently, bounding volumes can also be used for other optimizations such as what are called occlusion queries. This is a process of determining which objects are behind other objects (occluders) and therefore do not need to be processed / rendered. Bounding volumes can also be used for frustum culling which is the process of determining which objects are outside of the perspective viewing volume (too near, too far, or beyond your field-of-view angle) and therefore do not need to be rendered.
As Kylotan noted, using a bounding volume can generate false positives when detecting occlusion and simply does not work at all for some types of objects such as toroids (e.g. looking through the hole in a donut). Having objects like these occlude correctly is a whole other thread on portal-culling.
Quadtrees and Octrees, another quadtree, are popular ways, using space partitioning, to accomplish this. The later example shows a 97% reduction in processing over a pair-by-pair brute-force search for collisions.
A common technique in game physics engines is the sweep-and-prune method. This is explained in David Baraff's SIGGRAPH notes (see Motion with Constraints chapter). Havok definitely uses this, I think it's an option in Bullet, but I'm not sure about PhysX.
The idea is that you can look at the overlaps of AABBs (axis-aligned bounding boxes) on each axis; if the projection of two objects' AABBs overlap on all three axes, then the AABBs must overlap. You can check each axis relatively quickly by sorting the start and end points of the AABBs; there's a lot of temporal coherence between frames since usually most objects aren't moving very fast, so the sorting doesn't change much.
Once sweep-and-prune detects an overlap between AABBs, you can do the more detailed check for the objects, e.g. sphere vs. box. If the detailed check reveals a collision, you can then resolve the collision by applying forces, and/or trigger a game event or play a sound effect.
Correct. Normally there is not an event listener for each object. Often there is a non-binary tree structure in memory that mimics your games map. Imagine a metro/underground map.
This memory strucutre is a collection of things in the game. You the player, monsters and items that you can pickup or items that might blowup and do you harm. So as the player moves around the game the player object pointer is moved in the game/map memory structure.
see How should I have my game entities knowledgeable of the things around them?
I would like to recommend the solid book of Christer Ericson on real time collision detection. It presents the basics of collision detection while providing references on the contemporary research efforts.
Real-Time Collision Detection (The Morgan Kaufmann Series in Interactive 3-D Technology)
There are a lot of optimizations can be used.
Firstly - any object (say with index i for example) is bounded by cube, with center coordinates CXi,CYi, and size Si
Secondly - collision detection works with estimations:
a) Find all pairs cubes i,j with condition: Abs(CXi-CXj)<(Si+Sj) AND Abs(CYi-CYj)<(Si+Sj)
b) Now we work only with pairs got in a). We calculate distances between them more accurately, something like Sqrt(Sqr(CXi-CXj)+Sqr(CYi-CYj)), objects now represented as sets of few numbers of simple figures - cubes, spheres, cones - and we using geometry formulas to check these figures intersections.
c) Objects from b) with detected intersections are processed as collisions with physics calculating etc.