For Operating Systems class I'm going to write a scheduling simulator entitled "Jurrasic Park".
The ultimate goal is for me to have a series of cars following a set path and passengers waiting in line at a set location for those cars to return to so they can be picked up and be taken on the tour. This will be a simple 2d, top-down view of the track and the cars moving along it.
While I can code this easily without having to visually display anything I'm not quite sure what the best way would be to implement a car moving along a fixed track.
To start out, I'm going to simply use OpenGL to draw my cars as rectangles but I'm still a little confused about how to approach updating the car's position and ensuring it is moving along the set path for the simulated theme park.
Should I store vertices of the track in a list and have each call to update() move the cars a step closer to the next vertex?
If you want curved track, you can use splines, which are mathematically defined curves specified by two vector endpoints. You plop down the endpoints, and then solve for a nice curve between them. A search should reveal source code or math that you can derive into source code. The nice thing about this is that you can solve for the heading of your vehicle exactly, as well as get the next location on your path by doing a percentage calculation. The difficult thing is that you have to do a curve length calculation if you don't want the same number of steps between each set of endpoints.
An alternate approach is to use a hidden bitmap with the path drawn on it as a single pixel wide curve. You can find the next location in the path by matching the pixels surrounding your current location to a direction-of-travel vector, and then updating the vector with a delta function at each step. We used this approach for a path traveling prototype where a "vehicle" was being "driven" along various paths using a joystick, and it works okay until you have some intersections that confuse your vector calculations. But if it's a unidirectional closed loop, this would work just fine, and it's dead simple to implement. You can smooth out the heading angle of your vehicle by averaging the last few deltas. Also, each pixel becomes one "step", so your velocity control is easy.
In the former case, you can have specially tagged endpoints for start/stop locations or points of interest. In the latter, just use a different color pixel on the path for special nodes. In either case, what you display will probably not be the underlying path data, but some prettied up representation of your "park".
Just pick whatever is easiest, and write a tick() function that steps to the next path location and updates your vehicle heading whenever the car is in motion. If you're really clever, you can do some radius based collision handling so that cars will automatically stop when a car in front of them on the track has halted.
I would keep it simple:
Run a timer (every 100msec), and on each timer draw each ones of the cars in the new location. The location is read from a file, which contains the 2D coordinates of the car (each car?).
If you design the road to be very long (lets say, 30 seconds) writing 30*10 points would be... hard. So how about storing at the file the location at every full second? Then between those 2 intervals you will have 9 blind spots, just move the car in constant speed (x += dx/9, y+= dy/9).
I would like to hear a better approach :)
Well you could use some path as you describe, ether a fixed point path or spline. Then move as a fixed 'velocity' on this path. This may look stiff, if the car moves at the same spend on the straight as cornering.
So you could then have speeds for each path section, but you would need many speed set points, or blend the speeds, otherwise you'll get jerky speed changes.
Or you could go for full car simulation, and use an A* to build the optimal path. That's over kill but very cool.
If there is only going forward and backward, and you know that you want to go forward, you could just look at the cells around you, find the ones that are the color of the road and move so you stay in the center of the road.
If you assume that you won't have abrupt curves then you can assume that the road is directly in front of you and just scan to the left and right to see if the road curves a bit, to stay in the center, to cut down on processing.
There are other approaches that could work, but this one is simple, IMO, and allows you to have gentle curves in your road.
Another approach is just to have it be tile-based, so you just look at the tile before you, and have different tiles for changes in road direction an so you know how to turn the car to stay on the tile.
This wouldn't be as smooth but is also easy to do.
Related
I read through the forum and as I am sure this question has been asked before, but I couldn't really find what I was looking for.
My problem is the following:
I have an AI-Character moving along a spline. Should that path be blocked, the character should move in an arc around it and then continue on it's path.
For arguments sake lets assume that the spline has a length of 7000 units.
Therefore, I have two 3D (x,y,z) vectors. The first vector is the current position of the AI-bot and the second vector the position past the obstacle. For the time being lets just say: current spline position + 400 units; later on I could do a line trace to get the dimension of the obstacle etc. but for now I don't care about it.
Now I would like to compute an alternative path to avoid aforementioned obstacle - hence compute the arc between these two points - How do I do this?
I am really terrible at maths but looked at projectile trajectory because I thought that it would be sort of the same, just was unable to really understand it :<
It doesn't have to be an arc. You can solve this problem recursively in a very simple way.
Consider you're at position A, and the obstacle is at position B. You can do the following moves:
From current position to A+V(B[x]+height(B),0,0)
From current position to A+V(0,B[y]+width(B),0)
From current position to A+V(B[x]-height(B),0,0)
where V is a vector with components V(x,y,z), width(B) is the width of the obstacle and B[x] is the x component of the position of B. This way you moved around it along a rectangle. You can now smoothen the path by subdividing that rectangle in halves. 3 subdivisions are enough to make this smooth enough. To subdivide, take the middle point the first path, and draw a line to the middle of the second path. The same you do from the second path to the third one, and now your rectangle becomes an octagon. If that's not smooth enough, do a few more steps. This will create a new spline that you can use.
I would look at a combination of splines and the EQS system. The spline defines the ideal path to follow. The EQS system finds locations near or on the path, while still doing obstacle avoidance. EQS can return all valid destinations so you can manually order them by custom critera.
Actors set on a spline do work, but there's a whole bunch o' mess when making them stop following a spline, creating a new one at the correct point, attaching the actor the new spline, and so on.
I arrived at this conclusion yesterday after exactly going the messy way of adding spline points etc. The only problem i see is that I find the EQS system very difficult to understand. Not following the examples as such, but modifying it in the way I need it. Lets see, i keep you posted.
I work on a project which demands to use A* algorithm. In this project you select your player with the left click and you guide him in the map with the right click, like the gameplay of thousand strategy game. The graphics are 2D, a little like the game Don't Starve and the game is developped with SFML / C++.
I need to use A* for the deplacement of the player, indeed if an obstacle appears on his road he has to avoid it. But for the moment, i don't know how to apply a grid to the map, i want to place any tree / rocks and other stuff anywhere in order not to see the grid cells. For now the open list is only composed of pixels, which is not the good solution I think ^^, the algorithm is pretty slow. If you have any solution for a realistic rendering while keeping a fast algorithm I'd be happy to hear it. :)
Thank you in advance,
Do you have a screenshot?
The pathfinding grid, and rendering grid can be different. Zelda used different sized tiles for movement and rendering.
navigation mesh
This may be overkill for your map structure, but you may use a navigation mesh.
,
edit: If you haven't read it, Amit has a great resource: http://theory.stanford.edu/~amitp/GameProgramming/
What you're looking for is discretization. Behind this obscene name stands a simple principle : you can't deal with an infinite amount of data.
You need then to perform a transformation on your world : instead of allowing your character/unit to go at any location (x and y being real numbers), you can divide your world into some sort of a grid (this is what the navigation mesh and waypoints are doing), and only allow your char to go on these cells (or points, you can see it as you want). This is discretising : you are going from continuous values (real coordinates) to discrete values (integer coordinates / point). The more precise you go, the nicer it'll look.
After doing this, assigning moving costs between cells/points is rather simple, and performing A* on it as well.
I am at the start of developing a software using OpenCV in Microsoft Visual 2010 Express. Now what I need to know before i get into coding is the procedures i have to follow.
Overview:
I want to develop software that detects simple boxing moves such as (Left punch, right punch) and outputs the results.
Now where am struggling is what approach should i take how should i tackle this development i.e.
Capture Video Footage and be able to extract lets say every 5th frame for processing.
Do i have to extract and store this frame perhaps have a REFERENCE image to subtract the capture frame from it.
Once i capture a frame what would be the best way to process it:
* Threshold it, then
* Detect the edges, then
* Smooth the edges using some filter, then
* Draw some BOUNDING boxes....?
What is your view on this guys or am i missing something or are there better simpler ways...? Any suggestions...?
Any answer will be much appreciated
Ps...its not my homework :)
I'm not sure if analyzing only every 5th frame will be enough, because usually punches are so fast that they could be overlooked.
I assume what you actually want to find is fast forward (towards camera) movements of fists.
In case of OpenCV I would first start off with such movements of faces, since some examples are already provided on how to do that in software package.
To detect and track faces you can use CvHaarClassifierCascade, but since this won't be fast enough for runtime detection, continue tracking such found face with Lukas-Kanade. Just pick some good-to-track points inside previously found face, remember their distance from arbitrary face middle, and at each frame update it. See this guy http://www.youtube.com/watch?v=zNqCNMefyV8 - example of just some random points tracked with Lukas-Kanade. Note that unlike faces, fists may not be so easy to track since their surface is rather uniform, better check Lukas-Kanade demo in OpenCV.
Of course with each frame actual face will drift away, once in a while re-run CvHaarClassifierCascade and interpolate to it your currently held face position.
You should be able to do above for fists also, but that will require training classifier with pictures of fists (classifier trained with faces is already provided in OpenCV).
Now having fists/face tracked you may try observing what happens to the points - when someone punches they move rapidly in some direction, while on the fist that remains still they don't move to much. And so, when you calculate average movement of single points in recent frames, the higher the value, the bigger chance that there was a punch. Alternatively, if somehow you've managed to track them accurately, if distance between each of them increases, that means object is closer to camera - and so a likely punch.
Note that without at least knowing change of a size of the fist in picture, it might be hard to distinguish if a movement of hand was forward or backward, or if the user was faking it by moving fists left or right. You may have to come up with some specialized algorithm (maybe with trial and error) to detect that, like say, increase a number of screen color pixels in location that previously fist was found.
What you are looking for is the research field of action recognition e.g. www.nada.kth.se/cvap/actions/ or an possible solution is e.g the STIP ( Space-time interest points) method www.di.ens.fr/~laptev/actions/ . But finally this is a tough job if you have to deal with occlusion or different point of views.
I'm currently making a game in the DirectX engine in c++. I'm using path-finding to guide an army of soldiers to a specific location. the problem is that I use raycasts to see if there is nothing in the way of my path, and this slows down the speed of the game. Is there a better way to do pathfinding?
I also have a problem with the moving of my army. Right now i'm using the average of soldiers' positions as the start point, which means all the soldiers need to go there first before moving to the end point. Is there a way to make them go to the end point without going to the startpoint?
Thanks for the help.
Have you tried something like A-Star? to navigate via nodes, or some sort of 2d-array representation of your map? written good it could possible be faster aswell as easier to do with jobs ( multithreaded ).
if you have a solider, who is at postion A, and needs to get to B.
just calulate the path from C(the avrage position what ever) to B. get the direction from a to b and do some sort of interpolation. ( havent done this, or tried it, but it could probablt work out pretty well!)
Are you hit-testing every object when you are raycasting?
That can be very expensive when you have many objects and soldiers.
A common solution is to divide your world into square grid cells, and put each object in a list of objects for that grid.
Then you draw an imaginary line from the soldier to the destination and check each cell what objects you need to hit test against. This way you will evaluate only objects close to the straight path and ignore all others.
I'm trying to develop a game where cars move along roads and stop according to the signal of the traffic lights. They've got different velocities. Sometimes cars need to decelerate in order to not hit the leading car. They need to stop at the red lights. They have to make turns and etc. This is all relatively easy when working with straight intersecting roads. But how can I move a car/cars along a curved path? So far it was easy because I was just using either x or y of a car's position. But this time it's not the case, both coordinates seem to be necessary for moving it ahead. With straight roads I can just give a car an arbitrary speed and it will move along x or y axis with that speed. But how can I determine the velocity, if both coordinates have to be taken into account? Acceleration and decelerations are also mistery to me in this case. Thanks ahead.
Although this is about moving a train over a freeform track, the same issues and principles apply to cars moving across freeform roads. Actually, cars may be easier because they don't need to stick to their track 100% accurately.
In short: it's not easy, but doable. How hard it is going to be depends on how realistic you want your cars to look and finding corners to cut.
In your case the cars should simply follow a path (series of points). Since CCActions are bad for frequent direction/velocity changes, you should use your own system of detecting path points and heading to the next. Movement along a bezier curve is not going to have your cards move at constant speed, that rules out the CCBezier* actions.