I've been looking around, trying to find out how to get the normal of a line segment. This has caused me quite a lot of trouble.

Every single time I've come across this stuff, I get something like:

Line1 = vector(x,y)(yes, because lines are usually defined by a single point)Line1.normal = vector(-y,x)(again, the normal [which I've always seen represented as a ray or line perpendicular to the original line segment] defined magically by a single vector)

This all seems to be perfectly normal to everyone but me...so I fear I'm just being a massively dense dunderbum, but I can't find anything suggesting that this isn't how it appears.

Sorry if I sound a little frustrated, but I am. I guess it's just because it seems so incredibly simple, and yet fundamentally takes a neat little origami-crap on what I know of geometry. ( an origami-crap juuust big enough to keep me from doing what I need to do )

I really, really didn't want to resort to asking this here, but I'm about to flip my wig. Quick and easy answer? Anyone?

Thanks in advance.

______________I am the Lorax. I speak for the trees. I speak for the trees for the trees have no tongues.

A vector can be visualized as the line connecting the origin (0,0) and the co-ordinates specified by the vector.

So, if you have a line segment, then you need to use the 'slope' of the segment to calculate the normal. A normal is a single vector because its position doesn't matter; only its direction matters. If you want to draw the normal (N), choose any starting point you want, say P, and draw a line from P to P+N.

I thought this would fix my problems, but it hasn't... I think my problem is that I need the dot product of N (normal) and V (movement vector of a point colliding with the line segment), but the issue is that I'm not using vectors for anything. Can I do this with normal floats?

[edit]I'm working from the bottom of this page. All of the (simple) math is using vectors, and I'm having a hard time working through them with floats.

______________I am the Lorax. I speak for the trees. I speak for the trees for the trees have no tongues.

This seems to be a problem you have with vector math in general, right? The page you linked would have left me totally blank, hadn't I already known all the vector stuff, so there's no need to reference to yourself as "massively dense dunderbum". I recommend catching up to the basics of vector math before even trying to understand the article. When you've got the basics down, return to it.

No. That's a normalized vector, not a normal vector. Not the same thing. It's often handy to keep your normals normalized, but they don't have to be.

I stand corrected.

The website you are using, Anomie, is wrong (they never mentioned what type of a normal vector they seek directly) so technically it wasn't your mistake... but still if you knew how vectors work you'd see this error rather quickly.

With regards to collisions, there are two totally different ways of modeling them:

The first is with a single instantaneous contact. You determine when and where the collision happened, and you place the point accordingly with its velocity reflected about the surface normal. You can make this more realistic by artificially adding a contact time, friction, spin etc. This is probably the wrong method for your purposes if you're attempting what I think you are...

The second method (which I consider far more elegant) is to model the collision as an acceleration of the point along the normal of the line segment. You're effectively creating a little spring during the contact time. The beauty of this approach is that rebound (reflection about the normal) is a natural consequence of the fact that you're only accelerating the point in the direction of the normal. The difficulty, however, is that if you're using a point (instead of a circle), the point will have to pass through the line segment (imagine the line segment is elastic, and the point stretches it a bit before rebounding). You can set the acceleration to something like if you want the line segment to be a hard surface (where x is the displacement of the point from the line along the line segment normal).

I did write a little demo many years ago which might be handy for you if I could just find it...

[edit]

Hehe, that's cute. I couldn't find it, but it seems someone cloned it for me, which is definitely a good thing if you knew what my code looked like back then SnookerClone.

I'm trying to do the 'Vn = [N.V]N' part of what's on that Gamasutra page, without any vectors. The idea was to break it into x_vel and y_vel...but I sure wouldn't bet money that I'm doing it right.

I'm all about elegance. The Gamasutra article was the only information I could find on collision response that wasn't specific to polygons or spheres, so I went with it. So how would I go about implementing your second method there? (all of my line segments are totally rigid, when it comes to collision)

[edit]Waithuh... Accelerate the particle by some degree in the direction of the normal... Of course![edit2] Okay...not as simple as I thought... Help?

______________I am the Lorax. I speak for the trees. I speak for the trees for the trees have no tongues.

Looking at it now, I think my problems might be from my collision detection stuff... As the particle's velocity decreases, it's more and more likely to pass through the line segment. (which is the problem I'm having, sorry for not mentioning that before)

Attached Win32 binary, for your viewing pleasure.

______________I am the Lorax. I speak for the trees. I speak for the trees for the trees have no tongues.

Since when does a dot product return a vector? Pseudo-code or not, that is completely wrong.

They are not vectors, they are the magnitude of the vectors resolved in the directions u and v (sorry, there was an error in my code).

Quote:

Aside from their normal vector gaffe, their formulas are fine

Yeah true, "The relative velocity of the two bodies is checked by calculating N • V" was a bit misleading though, but I suppose the wording is actually correct since it's referring to a plane and not a line segment (relative velocity of a point with a stationary line segment would just be the magnitude of the velocity of the point). So yeah, it's exactly the same as my code, except that I waste time calculating two dot products (more intuitive) instead of one.

[edit]

Quote:

Looking at it now, I think my problems might be from my collision detection stuff... As the particle's velocity decreases, it's more and more likely to pass through the line segment. (which is the problem I'm having, sorry for not mentioning that before)

Are you applying gravity before or after the collision? - because if you're doing the collisions first, then eventually it's going to fall through.

Otherwise you can just make it impossible for the point to ever cross the line: if it does, place it on the line (you should know how to check if it has crossed the line).

I'm applying gravity before the collision stuff, but...I think it's important that I work out what's wrong, rather than brute-force my way around the problem... All I'm doing is your direction test, and if it changes sign, register a collision. (also making sure the point lies within the area of the line)

______________I am the Lorax. I speak for the trees. I speak for the trees for the trees have no tongues.

All I'm doing is your direction test, and if it changes sign, register a collision.

So, before moving a point, you are checking if its new location cases a sign change. If it does, you're not moving it forward but instead registering a collision?

Quote:

I think it's important that I work out what's wrong

You're trying to find the equilibrium of a point (infinitely small) resting on a line (infinitely thin) - it's not exactly the most robust thing for a numerical integrator to model. Think about when the point is exactly on the line and stationary (this is what it's going to tend towards not counting floating point errors and the application of gravity with each step). As it reaches this equilibrium, it just needs a tiny floating point rounding error for the point to end up on the wrong side of the line.

You'll need to build in some sort of robustness yourself, or change what you are modeling (a circle colliding with a line, or a point colliding with a polygon).