Planes and Point-Plane Collision

[Baker]

I've been reading up on plane math lately (watching YouTube vids, reading web sites). The collision parts in the engine with dist < 0 and such are beginning to make a lot of sense.

This one I've found has been the most helpful: http://gamedeveloperjourney.blogspot.co ... ction.html And in particular I love this part. Killer!



I find the above priceless because I understand 2D math, 2D circles (sin/cos/tangents/chords), 2D polygons rather well from some exhaustive reading and maybe 30 sheets of paper working out problems earlier in the year. The sum of all the angles in any concave polygon is 360 degrees and the above uses this to detect if point x, y, z lies inside a polygon.

[Spike]

distancefromplane = dotproduct(planenormal, point) - planedist;
if (distancefromplane < 0)
pointisbehindtheplane();

nothing to do with angles.
works in 2d and 1d too, of course (though in 1d, your plane normal is either 1 or -1, and the dotproduct comes out as basically 'point').

[Baker]

[andrewj]

That piece of code figures out the texture coordinate of a point on a polygon.

What's that got to do with collisions?

I wanna say something helpful, but I don't know what you're trying to do.

[Baker]

[Spike]

the texture vectors are basically just more planes. each gives the 'normal' of a plane upon the previous plane, where the central texture coord is 0. Texture scaling is given by the scale of the normal. The texture extents then give the minimum and maximum bounds of the actual rectangle of the surface.
(Actually, this is a somewhat simplistic view, as the texinfo is not guarenteed to be aligned to the surface, only that the x/y relative to the surface is the same, the z value can be quite different, depending on scale, however that's not relevent as the deviation to the side is effectively nullified by the dotproduct).
This is all 'simple' plane equations, nothing to do with sin or cos or any angles. Its just across the plane rather than infront of the plane. Hence the use of the tangent/bitangent, and yes, combined with the normal, you have a 3d box region and can work out the exact corners of the potentially visible surface, by using its extents.

[Baker]

[Spike]

well that is basically what its doing.

my earlier point was more that with your earlier chunk of code, trying to think of it in terms of angles is just going to confuse you - dotproducts can yield an angle when combined with normalised vectors and acos, but for this case, everything is kept purely as directions. Angles are only meaningful when you're comparing two directions (aka: 3 points), while this is a point and a plane.
But yeah, the texture vectors are two planes that state the direction in which the s+t coords increase, with the dist moving 0 away from the origin.
Of course, the texture vectors are shared between multiple surfaces, so the distance value is generally lower than abs(texturesize), so you need the mins+extents to check if the point being tested against these planes is within the quad.

if the point is outside the surface but within the triangle, you'll probably hit redundant info sticking out into space, yes. I guess the chances are that the light values in the non-existant part of the surface are more accurate than those on the ground below.
the leafs are all convex regions, so you'll not find a surface randomly jutting out of nowhere.
If you really want to constrain the samples to the region of the poly, you'll have to generate a plane from the edge lists and verify that the point is within ALL edge planes.
But really, that should be overkill as you know that you hit a solid, and that the other side of the node is solid, and that your current leaf is empty.
I suppose its possible that you get a single leaf with a diagonal v-shaped bottom, in which case yes you'll sample black from the cut surface half the time (depends on the qbsp). You can probably mitigate that by ensuring that the impact point ('mid') is within an epsilon of the surface plane, which should reject the bad plane (if they're co-planer, they should both have correct light samples).

[Baker]

[andrewj]

[taniwha]

[Spike]

the texture vectors are axial. a floor polygon 64*64 with a slight incline at one side will be ANYZ. this means that the slope tiles correctly with respect to its neighbouring (flat) floor polygons upon the same grid. The same is true for beveled corners on walls, etc.
If it wasn't like that, you'd need to consider the length of the hypotenuse when texturing. Yes, this means angled surfaces have slightly lower texture resolution in at least one axis. This is of course what makes texture locking when rotating quite so painful.
There's no boxonplaneside advantage to ANYX etc. Its really only worth optimising only the major axis, and possibly their negatives, but as negatives are implemented using a 'planeback' flag instead, those do not need to be optimised for.

[mh]

Just to elaborate further on how the dotproduct shortcut works:

If the normal is 1|0|0 then point dot normal is point.x * 1 + point.y * 0 + point.z * 0, which comes out as point.x; likewise for 0|1|0 and 0|0|1, so this is calculated in advance and the shortcut used if appropriate.

I haven't benched this but my gut feeling is that with a reasonably modern CPU the cost of the branch is going to be more expensive than the cost of just doing the calculation anyway, so it's most likely a case of an optimization that was valid in 1996 but is not any more.

[Baker]

Just want to say I understand all of this now. I really was making it too hard. I worked through several formulae and scenarios and it finally all made sense.

And some of the explanations above proved invaluable, more or less to reinforce that I was on the right track as I worked through the equations and what they meant. And some of the above posts give some added depth to how to apply/use the infos usefully.

[MH's dynamic light on brush models tutorial oddly enough is going to prove to be useful for some of the experimentation I may end up doing with this stuff.]