How do I find the great circle that:
intersects the most land, or
whose longest leg over water is the shortest possible, or
intersects the fewest countries?
Is there any app or available code that can answer questions of this type?
Related
I've been reading a book called "iOS Games by Tutorials" (recommend it to anyone interested in making iPhone games) & I'm learning how to make Tiled Maps with Sprite Kit with an overhead view (like the legend of zelda link's awakening). So far, I have made a tiled map using tiles that are 32x32, placed the player character & several NPC's into the world. Even made the NPC's randomly move around the map, though the way it teaches in the book is having them move from tile to tile (any of the 8 tiles surrounding the NPC at any time - if a tile has some property such as categoryBitMask then it won't move to that tile).
I am going to change NPC movement to physics-based (which is its own problem) just like the player character has right now (which means NPC's will collide with objects that have a physicsBody like the player character does). It's more fluid & dynamic.
But here is where the question begins. I want to implement Pathfinding (such as the A* algorithm) into the NPC & player character movement due to the map containing buildings, water, trees, etc. with their own physicsBodies. It's one thing to limit NPC's random movement or to force them to walk a predetermined path (which will kill the point of this game), but it's another to have to tap the screen very often to have the player character avoid all the buildings/trees he has to walk past. I don't want to use a grid system. Is it possible to implement some pathfinding algorithm into x,y coordinates? Is this more resource intensive? Could you share your thoughts about this?
Thank you.
This is a very interesting topic.
There are algorithms for finding paths in continuous spaces. For example, you can use a potential based method with the objective having a very low potential and obstacles being "hills" (perhaps infinitely high, although this requires a bit of care). The downside of potential methods is that you have to take special precautions to keep them from getting stuck at a local minimum. Situations like this
P
+----+
| M|
| |
+ ---+
Where M is a monster trying to get to the player, P can occur. In the example, the monster is at a local minimum, and it would have to go to a higher potential in order to get out the door at the lower left of the building. A variant of potential algorithms (in fact, it's often useful to reduce it to one), is to assign anti-gravity to obstacles and gravity to objectives. This is also somewhat non-deterministic and requires special precautions to avoid getting "stuck".
As #rickster points out, SpriteKit provides an SKFieldNode class that can help you implement a potential based solution.
Other approaches include "wall following" (for example, Pledge's algorithm) and are useful for finding your way around in a maze like environment.
One drawback to continuous methods is that NPC movement will often seem a bit unnatural -- for example, even if our monster in the example above is able to decide that it's at a local minimum and increase the "temperature" of it's search (that is, make larger moves, perhaps at random, against the potential gradient), it will bounce around instead of going straight for the door.
An alternative to searching in continuous spaces is to quantize the space. A simple method is to tile it, cover it with polygons, or represent it as a quadtree. Essentially, you want to have a way of mapping every point in the continuous space to a vertex on a graph representing the quantized space. At this point, graph search algorithms like A* and friends are applicable.
Graph search is somewhat resource intensive, but for a 2d zelda like game, it should be doable on a mobile device, especially with various optimizations like only "waking up" NPCs that are within a certain distance of the player (think aggro).
This page is a bit thin on implementation details, but it'll give you the right terms to google.
As always, start simple and iterate. Tiling is incredibly easy, and will let you experiment with the graph search method before optimizing.
This is a simple question that I would have rather chatted with someone about but here it is:
How is heading calculated? I can't figure it out visually.
If the heading is calculated in regards to the Earth's Geographic North, does that mean a top view of the Earth? So when you are standing on top of the surface of the Earth somewhere, how can you get a heading direction on a digital device? What are the calculations? Does it involve the sphere at all or does the device ignore the existence of the sphere and simply keep in mind a simple coordinate eg. 90.000 N and 0.000 W?
I don't know why I can't seem to grasp the concept of heading mathematically...
Edit: I think I figured it out. You are treated as a point, on the surface; north is always directly above you figuratively- you may deviate from this point 360 degrees potentially, that's as you as a point on the surface of the Earth.
Precisly a GPS receiver does not calculate heading.
heading is the direction where you are looking to.
The more correct term is course or course over ground.
But modern APIs often intermix heading, course and bearing.
heading and course is the same for a vehicle,
But not for a ship (due drift).
But the main point is that one could think a GPS chip calculates the course/heading by evaluiating old and new position. But this is not true. This would be by far to inaccurate.
GPS receiver use Doppler Shift for speed and probably also for heading calculation.
And yes course and heading is the angle clockwise measured from geographical north (0°)
There's no concept of "heading" in a coordinate, only in a procession of coordinates generated as something moves, in which case the heading is calculated based on the differences between the coordinates.
So if your first coordinate was at 10N50E and the second at 11N50E your device calculates you as traveling due north, thus on a northerly heading.
More than one question on this one :)
The heading (or yaw angle, in aeronautics), is defined as the angle between the North and the direction faced by the nose of the plane, when the plane is horizontal (pitch and roll angle at zero).
This is also what you could read on a compass (North = 0°, East = 90°, etc.)
Wherever you are on the globe, you should be able to lay on the ground a protractor whose 0° is aligned with your current meridian, pointing north, and the 90° is aligned on the local parallel, toward the east. Hence you can read your heading everywhere (except on poles)
In a car, the heading is deduced from the trajectory, by looking at the previously recorded points (Doppler based speed measurement is not widespread on cheap devices). And, as stated in other answers, this is not the heading but the track which is displayed (the direction you are moving to, compared to the direction you are facing). Luckily, cars don't drift (most of the time) and so, the track is equal to the heading.
In a smartphone, the display of the heading may be assisted by the internal compass.
So a GPS, as this, is not able to assess your heading, unless you use more than one antenna, like in this device. Where the phase difference measured between the two antennas enable the device to deduce a pure, GPS based, heading.
Similar to the method suggested in another answer - One way would be to have 2 GPS antennas and knowing their relative position to each other. Then you have the location of a straight line on the earth and you have a solid direction (perpendicular to this straight line). You can now calculate your orientation with respect to any datum (e.g. true north, or a reference GPS location).
I figured someone probably asked this question before but I wasn't able to find an answer.
I'm writing a physics library for my game engine (2d, currently in actionscript3, but easily translatable to C based languages).
I'm having problems finding a good formula to calculate the inertia of my game objects.
The thing is, there are plenty of proven formulas to calculate inertia around a centroid of a convex polygon, but my structure is slightly different: I have game-objects with their own local space. You can add convex shapes such as circles and convex polygons to this local space to form complex objects. The shapes themselves again have their own local space. So there are three layers: World, object & shape space.
I would have no problems calculating the inertia of each individual polygon in the shape with the formulas provided on the moments of inertia Wikipedia article.
or the ones provided in an awesome collision detection & response article.
But I'm wondering how to relate this to my object structure, do I simply add all the inertia's of the shapes of the object? That's what another writer uses to calculate the inertia of triangulated polygons, he adds all the moments of inertia of the triangles. Or is there more to it?
I find this whole inertia concept quite difficult to understand as I don't have a strong physics background. So if anyone could provide me with an answer, preferably with the logic behind inertia around a given centroid, I would be very thankful. I actually study I.T. - Game development at my university, but to my great frustration none of the teachers in their ranks are experienced in the area of physics.
Laurens, the physics is much simpler if you stay in two dimensional space. In 2D space, rotations are described by a scalar, resistance to rotation (moment of inertia) is described by a scalar, and rotations are additive and commutative. Things get hairy (much, much hairier) in three dimensional space.
When you connect two objects, the combined object has its own center of mass. To calculate the moment of inertia of this combined object, you need to sum the moments of inertia of the individual objects and also add on offset term given by the Steiner parallel axis theorem for each individual object. This offset term is the mass of the object times the square of the distance to the composite center of mass.
The primary reason you need to know the moment of inertia is so that you can simulate the response to torques that act on your object. This is fairly straightforward in 2D physics. Rotational behavior is an analog to Newton's second law. Instead of F=ma you use T=Iα. (Things once again are much hairier in 3D space.) You need to find the external forces and torques, solve for linear acceleration and rotational acceleration, and then integrate numerically.
A good beginner's book on game physics is probably in order. You can find a list of recommended texts in this question at the gamedev sister site.
For linear motion you can just add them. Inertia is proportional to mass. Adding the masses of your objects and calculating the inertia of the sum is equivalent to adding their individual inertias.
For rotation it gets more complicated, you need to find the centre of mass.
Read up on Newton's laws of motion. You'll need to understand them if you're writing a physics engine. The laws themselves are very short but understanding them requires more context so google around.
You should specifically try to understand the concepts: Mass, Inertia, Force, Acceleration, Momentum, Velocity, Kinetic energy. They're all related.
I have some way points with longitudes and latitudes which builds a trajectory and I want to calculate a parallel trajectory at a specific distance!
I would appreciate any help!
Best regards,
Tara
You can use the Dijkstra's algorithm.
More explanation here:
http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm
If you want that both the trajectory and the parallel trajectory will be composed of geodesics - you can't.
The path between two points is usually defined by a geodesic. Geodesic is a generalization of the notion of a straight line, or a straight line segment to curved spaces. Geodesic is the shortest route between two points on the Earth's surface, namely, a segment of a great circle.
Great circles divide the sphere in two equal hemispheres and all great circles intersect each other. Therefore, there are no parallel geodesics.
I am writing a physics simulation using Ogre and MOC.
I have a sphere that I shoot from the camera's position and it travels in the direction the camera is facing by using the camera's forward vector.
I would like to know how I can detect the point of collision between my sphere and another mesh.
How would I be able to check for a collision point between the two meshes using MOC or OGRE?
Update: Should have mentioned this earlier. I am unable to use a 3rd party physics library as we I need to develop this myself (uni project).
The accepted solution here flat out doesn't work. It will only even sort of work if the mesh density is generally high enough that no two points on the mesh are farther apart than the diameter of your collision sphere. Imagine a tiny sphere launched at short range on a random vector at a huuuge cube mesh. The cube mesh only has 8 verts. What are the odds that the cube is actually going to hit one of those 8 verts?
This really needs to be done with per-polygon collision. You need to be able to check intersection of polygon and a sphere (and additionally a cylinder if you want to avoid tunneling like reinier mentioned). There are quite a few resources for this online and in book form, but http://www.realtimerendering.com/intersections.html might be a useful starting point.
The comments about optimization are good. Early out opportunities (perhaps a quick check against a bounding sphere or an axis aligned bounding volume for the mesh) are essential. Even once you've determined that you're inside a bounding volume, it would probably be a good idea to be able to weed out unlikely polygons (too far away, facing the wrong direction, etc.) from the list of potential candidates.
I think the best would be to use a specialized physics library.
That said. If I think about this problem, I would suspect that it's not that hard:
The sphere has a midpoint and a radius. For every point in the mesh do the following:
check if the point lies inside the sphere.
if it does check if it is closer to the center than the previously found point(if any)
if it does... store this point as the collision point
Of course, this routine will be fairly slow.
A few things to speed it up:
for a first trivial reject, first see if the bounding sphere of the mesh collides
don't calc the squareroots when checking distances... use the squared lengths instead.(much faster)
Instead of comparing every point of the mesh, use a dimensional space division algorithm (quadtree / BSP)for the mesh to quickly rule out groups of points
Ah... and this routine only works if the sphere doesn't travel too fast (relative to the mesh). If it would travel very fast, and you sample it X times per second, chances are the sphere would have flown right through the mesh without every colliding. To overcome this, you must use 'swept volumes' which basically makes your sphere into a tube. Making the math exponentially complicated.