• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!

About angles and reflection

Status
Not open for further replies.
I have a small problem regarding calculating a "bounce".

In order to calculate a reflection, you need to have a normal.
In order to get a normal, you need to know where the wall is. Like this: -|

Now, when i check for colission, i pick a point in front of the projectiles path, and checks if it's pathable. This gives me two points, the origin, and the destination. But in the event that i do collide, i dont know how the projectile should bounce, since all i have is a line between two points in space!

How do i know in wich direction the projectile should bounce?

And also, what is the best method for checking pathability?
 
Level 8
Joined
Feb 15, 2009
Messages
463
i would say the opposite angle then coming in
e.g.
go to the wall with an angle of 30 - leave it with -30


:fp: -30
:fp: \ |
:fp: / |
:fp: 30

just an example bad painted =D
for the path thing try to find the IsTerrainWalkable function (or sth. like that here in the forum i saw it sometimes[or maybe on WC3C])
 
Level 29
Joined
Jul 29, 2007
Messages
5,174
This might help you. It's about light, but the same rules apply for objects too. Check this out too.

All the point of this thread is that there is no way (at least not an easy and straightforward way) to know the angle of the wall.
Read posts, darn it.

Anyhow, a solution might be to check a few lines of locations near the collision point to determine the angle. It will probably be very slow and lame though.
Of course, if all your walls are straight, you don't need all this.
 
Level 11
Joined
Feb 22, 2006
Messages
752
There's no way to know with arbitrary precision the angle and curvature of the wall. The best you can do is estimate. To do this you will need to poll a series of points around your object when you detect a collision and see if those points are pathable as well. How many points you poll determines how precise your bounce will be.

The points being polled should lie on a circle with a fixed radius equal to the distance the object has moved since the last collision check. You can already assume you poll at least one point (specifically, the point directly in front of the object, because otherwise how would you know you've collided with something?). The angular offset of the other points from the position of the object should be in regular intervals. For example, if we wanted to poll 4 points (including the point directly in front), and we arbitrarily define the current heading of the object as theta = 0, the points we poll have angular offsets of pi/2, pi, and 3pi/2. Polling 8 points means we check points at pi/4, pi/2, 3pi/4...7pi/4. Technically we don't need to poll the point at pi because that is directly behind the object. But I've included it to illustrate the method.

Once you've polled the points, you can keep track of which points are pathable and which aren't and based on that, determine the angle of the wall you've just hit. For example, if you poll 4 points and see that points at 0 and pi/2 are unpathable, you can assume that the normal angle of the wall is ABOUT 7pi/4.

Like I said, the precision of this method depends on the points polled. Polling 1 point (i.e. solely relying on the fact that you've detected a collision) gives you a precision of +/-pi (180 degrees), which is another way of saying no precision at all, so you can only assume the wall is perpendicular and set the new heading of the object to be offset by pi (180 degrees) from its original heading. If you poll 4 points, you are now precise to within +/- pi/4 (45 degrees). Polling 8 brings it to +/- pi/8, etc.

Issues with this method:

-Inefficient with large number of polls, imprecise with small number of polls
-Assumes only straight walls and moreover that all polygons that create collision are convex
-Can bug with very small collision sizes (those that are around the same size as or smaller than the distance the object can move between collision checks)
 
Thank you ricepuff! I will take a closer look at that when i have better time, but i must say it sounds promising. One smaller issue i'm struggeling with is that i want to check for colission every 32 units to make sure it wont bug through, but that would call for awfully long timers with fast bullet speeds. I will propably precalculate the path instead.
Most of my walls are actually pretty straight, but i'm planning to make a system based on locations having a predefined lowest and highest value to check for bullet col.
 
Status
Not open for further replies.
Top