I've got a problem with my javascript collision detection function. Whenever a collision occurs a fixed object should not move and the player should continue but in other direction so he would go around it. It is hard to describe, so I've prepared some examples:
red arrow represents the original direction of movement. Green arrow represents a new direction - I need the angle of that direction (on the picture, it is 90 degrees)
here is an another example: http://jsfiddle.net/kukas/xnB2M/3/ you can see there my collision detection function. Green squares represents a solution and the red one is problem. :)
Bonus: I would be grateful, if you solved an another problem - collisions are not pixel perfect. But that is not that important.
Related
In short what i want is to follow a line like the guy in this video:
https://www.youtube.com/watch?v=iHiasfAE63k
In the comment section he said:
"I get the array of values from my ROI, one per degree. I then set a threshold level and turn these values into binary values. In my direction of travel I set a region (30 degrees) either side of that point and disregard anything outside of it. I find the centre value of the binary array representing line. This gives me an angle to drive to. I then turn this into a x and y velocity using sin cos functions. I feed the x any velocity into the stepper drives and the camera closes the loop."
And i didn't understand a thing from his explanation? can you guys shed some light on this algorithm?
What I get from the info is that this guy is using a binarization algorithm to only have an image with pure black and pure white, then you can represent each pixel using only a bit (0 for black, 1 for white; and sometimes in the most common way using a byte 0 for black, 255 for white). So you need to apply this algorithm first to generate an image to work with.
After that this guy chose a direction of travel and search for that pixels that are in this direction and belongs to a region of interest of +/- 15 grades of the traveling direction. He obtains the points that are in this direction and compute a value which tells him where to go and translates this value to the movement of the motors.
I have a shape (in black below) and a point inside the shape (red below). What's the algorithm to find the closest distance between my red point and the border of the shape (which is the green point on the graph) ?
The shape border is not a series of lines but a randomly drawn shape.
Thanks.
So your shape is defined as bitmap and you can access the pixels.
You could scan ever growing squares around your point for border pixels. First, check the pixel itself. Then check a square of width 2 that covers the point's eight adjacent pixels. Next, width 4 for the next 16 pixels and so on. When you find a border pixel, record its distance and check against the minimum distance found. You can stop searching when half the width of the square is greater than the current minimum distance.
An alternative is to draw Bresenham circles of growing radius around the point. The method is similar to the square method, but you can stop immediately when you have a hit, because all points are supposed to have the same distance to your point. The drawback is that this method is somewhat inaccurate, because the circle is only an approximation. You will also miss some pixels along the disgonals, because Bresenham circles have artefacts.
(Both methods are still quite brute-force and in the worst case of a fully black bitmap will visit every node.)
You need a criterion for a pixel on the border. Your shape is antialiassed, so that pixels on the border are smoothed by making them a shade of grey. If your criterion is a pixel that isn't black, you will chose a point a bit inside the shape. If you cose pure white, you'll land a bit outside. Perhaps it's best to chose a pixel with a grey value greater than 0.5 as border.
If you have to find the closest border point to many points for the same shape, you can preprocess the data and use other methods of [nearest-neighbour serach].
As always, it depends on the data, in this case, what your shapes are like and any useful information about your starting point (will it often be close to a border, will it often be near the center of mass, etc).
If they are similar to what you show, I'd probably test the border points individually against the start. Now the problem is how you find the border without having to edge detect the entire shape.
The problem is it appears you can have sharply concave borders (think of a circle with a tiny spike-like sliver jutting into it). In this case you just need to edge detect the shape and test every point.
I think these will work, but don't hold me to it. Computational geometry seems to be very well understood, so you can probably find a pro at this somewhere:
Method One
If the shape is well behaved or you don't mind being wrong try this:
1- Draw 4 lines (diving the shape into four quandrants). And check the distance to each border. What i mean by draw is keep going north until you hit a white pixel, then go south, west, and east.
2- Take the two lines you have drawn so far that have the closest intersection points, bisect the angle they create and add the new line to your set.
3- keep repeating step two until are you to a tolerance you can be happy with.
Actually you can stop before this and on a small enough interval just trace the border between two close points checking each point between them to refine the final answer.
Method Two (this wil work with the poorly behaved shapes and plays well with anti-aliasing):
1- draw a line in any direction until he hit the border (black to white). This will be your starting distance.
2- draw a circle at this distance noting everytime you go from black to white or white to black. These are your intersection points.
As long as you have more than two points, divide the radius in half and try again.
If you have no points increase your radius by 50% and try again (basically binary search until you get to two points - if you get one, you got lucky and found your answer).
3- your closet point lies in the region between your two points. Run along the border checking each one.
If you want to, to reduce the cost of step 3 you can keep doing step 2 until you get a small enough range to brute force in step 3.
Also to prevent a very unlucky start, draw four initial lines (also east, south, and west) and start with the smallest distance. Those are easy to draw and greatly reduce your chance of picking the exact longest distance and accidentally thinking that single pixel is the answer.
Edit: one last optimization: because of the symmetry, you only need to calculate the circle points (those points that make up the border of the circle) for the first quadrant, then mirror them. Should greatly cut down on computation time.
If you define the distance in terms of 'the minimum number of steps that need to be taken to reach from the start pixel to any pixel on the margin', then this problem can be solved using any shortest path search algorithm like bread first search or even better if you use A* search algorithm.
I am planning on making a game that utilizes light (and shadows) as part of the gameplay, however I can't think of an efficient algorithm to implement them and I'm sure there is an elegant solution.
The white area is directly illuminated by light, light grey is illuminated by the walls that are directly illuminated and dark grey is darkness.
I wish to find those areas in an efficient manner. (real time, with the light being able to move)
Although not realistic, that is the simplest way I could think of my problem, any other implementation that includes direct light and reflected light is welcome.
...
My first attempt would be to draw lines from the light to the perimeter of the screen and find the first wall they intersect. But repeating this algorithm for every illuminated part of the wall to mark "ambient" light is not feasible.
Also note, the game is in Flash so I don't think I can utilize the gpu.
Inspired by Ryan's answer.
In a 2d grid, mark every point of the screen as lit. Then for every wall on the screen (in order of closeness to point) draw a shadow behind them as such: Before going to the next wall, first check which parts of it are lit and which are not, as to not draw the shadow twice. Mark all the walls for which the shadow was drawn for the next step, as these are the probably lit walls. (we should check again before the next part)
For every lit line segment (wall) first check if any wall intersect the segment. For every intersection split the lit segment in 2 at the intersection.
For the end points of every line segment, repeat the first part in a temporary array, and at the end add all the lit points into the final array.
The first part should go over all the points on the screen and all the points on the walls once. So O(area+length of walls), and depending on the complexity of the scene (number of walls, and interesections the second part should apply the first part about 20 times.
This may work in real time, however make sure to store the lit areas while the lights are not moving.
You don't need to draw all light lines, just the important ones. For example, with one point light source and one line, you only need to solve two intersections.
For reflected lighting, you would start with a point light of intensity n, then every time this light intersects a wall, you split the wall into smaller segments, and add a linear light source of intensity n-1 on the illuminated segment. You can do this as many times as you liked.
I am working on a project where I have a rolling marble in 2D. I can detect when the marble hits the corner of a box but I can't figure out what behavior it should have when it hits the corner. I need to figure out how to reposition the ball so it doesn't overlap the box. With a box to box collision it is as easy as setting the boxes right next to each other but for a circle and box I don't know where to move the marble to so it looks realistic.
I am not asking how it bounces off. I do have a good understanding of trig. As you move the marble towards the box it will, at some point, come to overlap with the box. I need to know how to make it so they don't overlap anymore but so it still looks realistic. It does not need to bounce off (like assuming infinite mass on part of marble).
Take a good look at this article on Wikipedia: Elastic Collision.
You will need to create surface normals for your 2D objects at any given surface point, which will be problematic if your boxes are perfectly square, as sharp edges don't have normals. You will have to give the corner cases (no pun intended) special treatment and give them surface normals that are the average of the normals of the two lines that join at the corner.
Basically, use vectors.
I'm working on a 3D tile based game and I'm using AABB collision detection. For every cube that the player is intersecting, I find the axis along which the player is intersecting the cube the least, and push the player out of the cube along that axis.
Depending on the order that the cubes are checked in, this can cause problems when sliding along the edge of multiple cubes. I have created a diagram that should explain the problem:
http://imgur.com/mmK0W.png
Arrow #1 is the attempted movement of the player. The other arrows are the collision response.
In the left diagram, collision is tested against the right cube first, causing the player to be pushed to the left, and then upwards. (bad)
In the right diagram, collision is tested against the left cube first, causing the player to be pushed upwards, at which point the player is no longer intersecting the other cube. (good)
Any ideas on what the most efficient way to solve this might be? Or any better ways to handle the collision response?
Thank you.
A discrete implementation forces you to inject some continuous math in the system, only when required (cubes / directions overlap).
For each cube c1, c2 ... ci with which the user cube (uc) intersects at the time of the check, you want to find out which cube was "touched" first - there is only one, as in real life. Consider the direction d of uc, and, taking the amount of uc in ci (overlapping) find the position of cu at the time it "touched" ci.
Determine which cube was "touched" first cj (the one that required the most rollback on the d axis - the sooner in time) and use only this one to calculate the collision reaction.
Not only you'll reach accuracy. but it will help if all cubes are moving, have different speeds etc...
From your diagram, it seems you want the smallest move that minimises the overlap between the player and the cubes. Each cube with overlap will try to "push" the player in two orthogonal directions. Can you do something like pick the minimum push of the maximum pushes in each direction?
You might implement a kind of hybrid broad phase when your two (or more) stationary cubes in a row can be combined into one larger rectangle. Test against the larger rectangle first. It will give you the results of your green check mark and be faster than checking each cube anyway. Then, after that, only if you need to, check against the individual cubes.
A collision can push an object on 1 axis only. To determine the axis to push:
else -- not this
elseif -- change to this
if w > h then
push x
elseif h > w then
push y
end
This works if your tiles are aligned.
Use circles to avoid the stick on unaligned tiles