2D Raycasting

Started by
6 comments, last by jwezorek 10 years, 11 months ago

I'm working on the code design/layout/architecture/whatever for a game I'm making. I want to implement line of sight so that things the player can't see won't be drawn on the screen. I found an example that is pretty much what I want. It uses ray casting and I haven't been able to find much on the subject outside of using it in 3D to render a scene.

I have some ideas on the matter that I'll share and maybe I'm on the right path already. If anyone could help me out by explaining it or showing me a good tutorial or some such I would appreciate it.

My world is pretty empty as far as most games go. Essentially, the player is flying around a ship in space and there are asteroid type objects in space. These are the only objects that block line of sight so far, everything else can be seen through.

An asteroid is a simple polygon consisting of points and the lines those points make.

My first thought, which I'm sure is terrible, was iterating along a vector in a loop and seeing what it hit. I won't be doing that lol.

My second thought a few seconds later was to test against the points and lines of the asteroid objects. I would determine open fields of view by testing the points of the asteroid objects and seeing where they intercepted lines of other asteroids. I would create a line function by going from the player's origin of view, the center of the screen, and going to the point in question. Then, using the formula for that line, test it against lines of asteroid objects (after running some yet to be determined algorithm to occlude asteroids that aren't even in the direction the ray is going). This will find the point of intersection between the ray and the line being tested again. I would then take the x value of the point and put it into the formula for the line being tested. If the resulting y value is between the y values of each endpoint of the line segment, then I would know that the ray is intersecting that line and that line is going to block line of sight all the way from one end point to the other end point. This would give me fields to test and see if enemies are within and if so draw them.

I also plan to use this same algorithm for AI navigation. Each area is created procedural during the game, so using navigation nodes is out of the question. I would use this same algorithm for determining areas that are safe to fly in if the AI were to travel in a straight line and whether or not the AI could see the player so they could shoot at them.

Is this a smart way to go about casting the rays? I've got a number of ideas for simplifying the algorithm as a whole (for instance checking if there is even an enemy on the screen to see if it should even determine player LOS and what not), but its the actual testing of the rays themselves and seeing what they hit that I want to make sure I'm on the right track for. It seems like it would be pretty darn fast to me, but my inexperience might hide something from me.

Advertisement
Sounds like you are talking about calculating a visibility polygon which is a good way to do fog of war type things.

How many kinds of asteroids will there be? How close are they to being circular? Can you approximate them as circles?

Will the asteroids move by translation or by translation and rotation?

At first it looked like you want to do a 2D game, but later it appeared to me that it is a 3D game with Asteroids - sort-of an Privateer/X-Com-like ?

In that case it might prove beneficial to look into Octrees, since you can reuse the nodes for multiple processes in the game, not just Frustum Culling.

I would also propose using the Sphere bounding boxes - the calculations are almost nonexistant and those few corner cases are not important from the gameplay/engine perspective anyway - even if the sphere itself partially intersects the frustum (and mesh not), the gfx card will discard processing those tris pretty early in the gfx pipeline anyway (and way, way faster than you can do on CPU anyway).

VladR My 3rd person action RPG on GreenLight: http://steamcommunity.com/sharedfiles/filedetails/?id=92951596

I want to implement line of sight so that things the player can't see won't be drawn on the screen.

for fog of war in a 2d game?

or for occlusion culling, collision avoidance, etc, in a 3d game?

they are somewhat different things.

2d fog of war involves los/lof (line-of-sight/line-of-fine) calculations.

occlusion culling is a method to cull distant objects which are behind a large object nearby (such as a building), when drawing 3d scenes.

for targeting and navigation in a 3d game where you don't fly, you can usually just use 2d targeting and navigation. so your question of who can see what and who for purposes of targeting and collision avoidance reverts back to 2d lof/lof calculations, and 2d obstacle detection/pathfinding, etc.

2d los/lof is probably done fastest using raycasting, and bressingham's line drawing algo, which is essentially iterating your vector:

"My first thought, which I'm sure is terrible, was iterating along a vector in a loop and seeing what it hit. I won't be doing that lol."

ironic, eh? great minds think alike.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

The game is 2D top down. The asteroids can be of any shape. It's not for occlusion for rendering purposes for performance, but more fog of war. It is also going to be used for navigation for AI and targeting for AI to determine if they should/can shoot at the player.

hi there

I am working on similar game and im allready made such effect on explosions

sea algorithm demo on

http://serumas.gamedev.lt/index.php?id=visibility&sid=

and game video and demo binary on

http://serumas.gamedev.lt/index.php?id=survival1&sid=

algorithm is sweep and prune style, not yet optimized greatly but it works

I could share it. it on c++.

But for targetting I think that would be to much calculations and in your case I would do collision brouadphase routine.

Or angle sweap and prune.

The game is 2D top down. The asteroids can be of any shape. It's not for occlusion for rendering purposes for performance, but more fog of war. It is also going to be used for navigation for AI and targeting for AI to determine if they should/can shoot at the player.

So if I were you I'd actually read the literature on 2D ray casting i.e. use Google...

But off the top of my head if you can't approximate with circles I think the next best thing would be to use the convex hull of each polygon for ray-casting rather than the polygon itself. I believe that this would not be an approximation as far as whether or not things behind the asteroid are visible goes; further, for each asteroid type until its shape changes you only need to compute the convex hull once.

This topic is closed to new replies.

Advertisement