weird traceline behavior

Discuss programming topics for the various GPL'd game engine sources.
Post Reply
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

weird traceline behavior

Post by frag.machine »

I am not sure if this is a bug or not.
Consider the situation in the image below, illustrating 2 tracelines fired against 2 different planes (A and B are the origins, and A' and B' the respective end positions set in trace_endpos):

Image

At least in DP, I observed that for sky brushes, the trace_endpos vector is set in the exterior face of the brush! (which AFAIK shouldn't exist at all in a Q1BSP because it was supposed to be discarded since wasn't visible).
BTW the map in question was fully compiled and VISed with Bengt Jardrup's ports of QBSP and VIS, which AFAIK are reasonably updated and bug-free.
Now, this is not only weird, but goes against what I learned about Q1BSP's.
Can anyone explain me WTF is going on here ?
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: weird traceline behavior

Post by Spike »

solid > sky > outside > water > empty
(earlier versions of qbsp prioritised outside over sky)

impacts happen when it crosses nodes into a volume that is solid. sky is non-solid, so that's where it impacts, on the boundary between the sky and the outside/solid.
the qc can then use pointcontents to see if the impact happened within the sky volume, assuming the outside didn't flood into and consume the sky.
Cobalt
Posts: 445
Joined: Wed Jun 10, 2009 2:58 am
Location: New England, USA
Contact:

Re: weird traceline behavior

Post by Cobalt »

Even though the point A' I guess is beyond the skybox, the traceline still considers that area not brushed with anything to be a solid? I believe watertype is -1 in those boundaries.
r00k
Posts: 1111
Joined: Sat Nov 13, 2004 10:39 pm

Re: weird traceline behavior

Post by r00k »

I have these

Code: Select all

// point content values

float   CONTENT_EMPTY                   = -1;
float   CONTENT_SOLID                   = -2;
float   CONTENT_WATER                   = -3;
float   CONTENT_SLIME                   = -4;
float   CONTENT_LAVA                    = -5;
float   CONTENT_SKY                     = -6;
I guess the engine gets points content collision differently

Code: Select all

void () T_HookTouch =
{
	if (clanring_state & CLANRING_MATCH_PAUSED)
	return;

	if ((other != self.owner))
	{
		if ((pointcontents (self.origin) == CONTENT_SKY) || (gameover))
		{
			HookVanish ();
			return;
		}
		else
		{
that will detect the brush at the front...
im not sure what frag.machine is testing or just noticed something odd with traceline...
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: weird traceline behavior

Post by frag.machine »

r00k wrote:im not sure what frag.machine is testing or just noticed something odd with traceline...
This odd behavior was the cause of a bug in my procedural map code. As a temporary workaround, I am ensuring in my maps that I will always fire traceline() against solid walls. Maybe later I'll deal with this special case scenario, but for now this is good enough.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
Post Reply