I've been working on a simple space shooter, and have gotten to the point in the project where my terribly written code is actually slowing things down. After running EQATEC, I can see that the majority of the problem is in the icky check everything on everything collision detection. I was considering putting in a QuadTree, but the majority of the collisions are on asteroids, which do move around a lot (would require a lot of updating). My next alternative was micro-optimizing the collision check itself. Here it is:
public bool IsCircleColliding(GameObject obj) //simple bounding circle collision detection check
{
float distance = Vector2.Distance(this.WorldCenter, obj.WorldCenter);
int totalradii = CollisionRadius + obj.CollisionRadius;
if (distance < totalradii)
return true;
return false;
}
I've heard that Vector2.Distance involves a costly Sqrt, so is there any way to avoid that? Or is there a way to approximate the distance using some fancy calculation? Anything for more speed, essentially.
Also, slightly unrelated to the actual question, is there a good method (other than QuadTrees) for spatial partitioning of fast-moving objects?
Compute the square of the distance instead of the actual distance, and compare that to the square of the collision threshold. That should be a bit faster. If most asteroids are the same size, you can reuse the same value for the collision threshold without recomputing it.
Another useful trick is to first do a simple check based on bounding boxes, and compute the distance only if the bounding boxes intersect. If they don't, then you know (for cheap) that the two objects aren't colliding.
Related
I'm doing research on generating planets for a game engine I'm planning to code, and I was wondering what would be the best approach to procedurally generate a planet. (In terms of performance.) So far I've seen the Icosphere and Cubemapped Sphere pop up the most, but I was wondering which of the two is faster to generate. My question is particularly aimed at LOD, since I hope to have gameplay similar to No Man's Sky.
Thanks in advance.
I would say a octahedron sphere would be best, but since they are all Platonic Solids, they will be similar, so the premature optimization might not be worth it. (Here's a tutorial in Unity)
The possible advantages of the octahedron are that the faces are triangles (unlike the cube) and there is one triangle for each quadrant in 3d space (unlike the icosphere and cube).
My rationale behind octahedrons (and icospheres) being faster than cubes lies in the fact that the face is already a triangle (whereas the cube has a square face). Adding detail for an octahedron, icosahedron, or cube usually means turning each triangle into four smaller triangles. During this generation, you create three new vertices whose positions will need to be normalized so that the mesh is still properly inscribed in a unit-sphere.
Tessellating a Cube
Octahedron and icosahedron can use a lookup table that fetches this normalization factor (as opposed to the cube) because the number is consistent for each iteration.
Assuming you can write a custom mesh format, you might store the mesh for a given planet through an array (size 4, 8, or 20) of quad-trees (because each triangle is optionally tessellated into four additional triangles). (This is essentially a LOD system, but you need to periodically determine whether or not to tessellate or reduce a portion of the mesh based on the distance from the camera.) This system will likely be the bottleneck since meshes have to be recalculated at runtime.
I'm currently writing a game (2D with OpenTK) in which there is a lot of rotation, and with it comes that I sometimes need to get the intersection between these lines/shapes:
Two quadrangles http://files.myopera.com/antonijn/albums/12693002/TwoQuadrangles.png
I know the rotation (in degrees) of both of them, and therefore I know the position of all the vertices in both shapes.
The algorithm needs to give me a bool on whether they intersect, or better yet, the coordinates of the intersections.
I have written my own algorithm, which scrolls through the sides of the first box, gets the formula for each side and compares them to the formulas of the lines of the second box. Now, this doesn't work when the lines are upright (slope of float.Infinity or float.NegativeInfinity), is a pain to debug and is far from fast, so I need a better one!
Any suggestions?
I ended up using the SAT method, as suggested by Nickon, thanks a bunch mate!
Sorry if this question is a bit open ended, but I'm pretty new to C# and XNA... and this forum in fact!
I'm creating a game and require a beam of light to emit from a fixed point (bottom left in attached screen capture, belonging to class named PowerStation) and reflect from mirrors which can be moved and rotated by the user. I've added a per-pixel collision detection method, as can be seen working in the attached capture (Mirror turns red).
Currently I've been trying to test for obstacles to the beam's path by creating a Point and moving it along the path of the light until a collision is detected; from there recording the distance travelled and then stretching the Beam sprite in a non-uniform way by the required amount. This is proving difficult already and I think there's still a long way to go with this method.
I was just wondering if anyone has any advice as to the best method to go about detecting obstacles, their rotation, and determining the direction to reflect the Beam (by which side of Mirror is hit), before I fully commit to something that might get really complicated or never even work?
Here is what my Beam class looks like currently... all but one classes inherit from one base class called Object and Objects are all declared in a static objectList belonging to a separate class Items. Apologies if this is bad, messy coding!
class Beam : Object
{
private Vector2 start;
private double length;
private Vector2 POC;
public Beam(Vector2 pos)
: base(pos)
{
spriteName = "beam";
depth = 0.2f;
solid = true;
foreach (Object o in Items.objectList)
{
if (o.GetType() == typeof(PowerStation))
{
start = o.Origin;
}
}
}
public override void Update()
{
Point newPoint = new Point((int)Origin.X, (int)Origin.Y);
while ((!(collision(new Mirror(new Vector2(0, 0))))) && (newPoint.X > 0) && (newPoint.Y > 0)) // && boundaries of window
{
newPoint.Y--; //will be changed to a Vector
}
POC = PointOfCollision(new Mirror(new Vector2(0, 0))); // Need to make it do POC of newPoint, not just the Beam Object!
length = FindLength(start, new Vector2(50, 50));
//Scale = new Vector2( , ); //amount to scale sprite
base.Update();
}
private double FindLength(Vector2 pos1, Vector2 pos2)
{
return (Math.Sqrt(Math.Pow(Math.Abs(pos2.X - pos1.X), 2.0f) + Math.Pow(Math.Abs(pos2.Y - pos1.Y), 2.0f)));
}
}
Any help would be greatly appreciated! Thanks in advance
Forget pixels--since the mirrors apparently can be at any angle you'll certainly have places where you intersect a mirror not on an even pixel. While you could simply count the impact point as the even pixel this will produce a slightly wrong path for the beam.
Instead, take your beam and iterate over all the mirrors, compute the intersection of the beam and the plane of the mirror (handle the case where there is no intersection), then check the intersection to make sure it's within the physical mirror. Record the match that occurs within the shortest distance.
You can almost certainly speed this calculation by figuring bounding boxes for all the mirrors in advance and when checking a beam note what quadrant it's heading towards from the current point--you can reject at least half (and usually 3/4) of all the mirrors with two integer comparisons each.
Repeat until there is either no intersection (the beam escapes) or it hits something that stops it rather than reflects it.
If there are a LOT of mirrors you could take this even farther and chop the screen up into sectors, each of which has a list of mirrors in it. Check only the mirrors in the current sector, if you don't get a hit figure out what sector it enters next and repeat. This is a bit more math casting the ray of the beam in exchange for excluding most of the mirrors without a single instruction. If you are dealing with user-placed mirrors I doubt there would be enough of them to be worth doing it.
Represent everything as vectors: your light beams and the sides of the shapes they bounce upon. Then it's very simple algebra to detect intersections and reflection angles. It'll also be infinitely faster than any pixel-based detection.
I've got two polygons defined as a list of Vectors, I've managed to write routines to transform and intersect these two polygons (seen below Frame 1). Using line-intersection I can figure out whether these collide, and have written a working Collide() function.
This is to be used in a variable step timed game, and therefore (as shown below) in Frame 1 the right polygon is not colliding, it's perfectly normal for on Frame 2 for the polygons to be right inside each other, with the right polygon having moved to the left.
My question is, what is the best way to figure out the moment of intersection? In the example, let's assume in Frame 1 the right polygon is at X = 300, Frame 2 it moved -100 and is now at 200, and that's all I know by the time Frame 2 comes about, it was at 300, now it's at 200. What I want to know is when did it actually collide, at what X value, here it was probably about 250.
I'm preferably looking for a C# source code solution to this problem.
Maybe there's a better way of approaching this for games?
I would use the separating axis theorem, as outlined here:
Metanet tutorial
Wikipedia
Then I would sweep test or use multisampling if needed.
GMan here on StackOverflow wrote a sample implementation over at gpwiki.org.
This may all be overkill for your use-case, but it handles polygons of any order. Of course, for simple bounding boxes it can be done much more efficiently through other means.
I'm no mathematician either, but one possible though crude solution would be to run a mini simulation.
Let us call the moving polygon M and the stationary polygon S (though there is no requirement for S to actually be stationary, the approach should work just the same regardless). Let us also call the two frames you have F1 for the earlier and F2 for the later, as per your diagram.
If you were to translate polygon M back towards its position in F1 in very small increments until such time that they are no longer intersecting, then you would have a location for M at which it 'just' intersects, i.e. the previous location before they stop intersecting in this simulation. The intersection in this 'just' intersecting location should be very small — small enough that you could treat it as a point. Let us call this polygon of intersection I.
To treat I as a point you could choose the vertex of it that is nearest the centre point of M in F1: that vertex has the best chance of being outside of S at time of collision. (There are lots of other possibilities for interpreting I as a point that you could experiment with too that may have better results.)
Obviously this approach has some drawbacks:
The simulation will be slower for greater speeds of M as the distance between its locations in F1 and F2 will be greater, more simulation steps will need to be run. (You could address this by having a fixed number of simulation cycles irrespective of speed of M but that would mean the accuracy of the result would be different for faster and slower moving bodies.)
The 'step' size in the simulation will have to be sufficiently small to get the accuracy you require but smaller step sizes will obviously have a larger calculation cost.
Personally, without the necessary mathematical intuition, I would go with this simple approach first and try to find a mathematical solution as an optimization later.
If you have the ability to determine whether the two polygons overlap, one idea might be to use a modified binary search to detect where the two hit. Start by subdividing the time interval in half and seeing if the two polygons intersected at the midpoint. If so, recursively search the first half of the range; if not, search the second half. If you specify some tolerance level at which you no longer care about small distances (for example, at the level of a pixel), then the runtime of this approach is O(log D / K), where D is the distance between the polygons and K is the cutoff threshold. If you know what point is going to ultimately enter the second polygon, you should be able to detect the collision very quickly this way.
Hope this helps!
For a rather generic solution, and assuming ...
no polygons are intersecting at time = 0
at least one polygon is intersecting another polygon at time = t
and you're happy to use a C# clipping library (eg Clipper)
then use a binary approach to deriving the time of intersection by...
double tInterval = t;
double tCurrent = 0;
int direction = +1;
while (tInterval > MinInterval)
{
tInterval = tInterval/2;
tCurrent += (tInterval * direction);
MovePolygons(tCurrent);
if (PolygonsIntersect)
direction = +1;
else
direction = -1;
}
Well - you may see that it's allways a point of one of the polygons that hits the side of the other first (or another point - but thats after all almost the same) - a possible solution would be to calculate the distance of the points from the other lines in the move-direction. But I think this would end beeing rather slow.
I guess normaly the distances between frames are so small that it's not importand to really know excactly where it hit first - some small intersections will not be visible and after all the things will rebound or explode anyway - don't they? :)
I am creating a CAD like program, creating modelvisual3D objects. How do i do collision detection between my objects(modelvisual3d) using MeshGeometry3D. Do i have to compare every triangle in the moving object against the still standing objects?
What will be my best way to do collision detection?
It depends on how precise your collision detection needs to be.
There is no built-in collision detection in WPF's 3D library. If you need high precision, you'll need to compare every triangle.
That being said, you can start with comparing bounding boxes and/or bounding spheres. This is always a good first step, since it can quickly eliminate most cases. If you don't need precision collision detection, this alone may be fine.
To add to Reed's answer (based on my answer here):
After you've eliminated most of your objects via the bounding box/sphere to bounding box/sphere test you should test the triangles of your test object(s) against the other object's bounding box/sphere first before checking triangle/triangle collisions. This will eliminate a lot more cases.
To rule out a collision you'll have to check all the triangles in the test object, but to find a case where you'll need to go down to the triangle/triangle case you only need to find the first triangle that interacts with the bounding box/sphere of the other object.
Look at the SAT theorem (Separating Axes Theorem), it's the fastest and easiest one out there.
The theory about this is that if you can draw a line which separates the triangles, then they're not colliding.
As is said, first do an AABB earlier detection, and when two objects collide, test each polygon of object A against each polygon of object B.
Starting in 2D, to test if two polygons collide, you get the extents of them in the possible axes (in this case X and Y), if those extents intersect, then the poligons are colliding.
On this page you can find a very good explanation on how it works and how to apply it:
http://www.metanetsoftware.com/technique/tutorialA.html
To apply it to 3D simply use the edges of each polygon as the separating axes.
If the extents on those axes intersect, then the polygons are colliding.
Also, this method resolves collission for moving objects, giving also the momentum of collision (resolve the relative angular velocity, substracting velocity B from velocity A, this way the problem is reduced to a moving object and a static one, and add the velocity in the axis you are testing to the extent of the polygon A, if they intersect, rest the original extent of the polygon and you will get the momentum of collission).
Another option would be to use BulletSharp, a C# wrapper of the well-known Bullet Physics Engine. In this case, you would need to write functions to create a (concave) collision shape from a MeshGeometry3D.
In my experience, it works pretty well, even though dynamic collision between concave shapes is not supported. You'll need to use convex decompsition, as a workaround.