Complete Explanation of trap_Trace Results...

[JaedenRuiner]

Okay,

 

I've been working on a mode for some time now, and it is almost ready to be published. The biggest problem i have is that occasionally while moving an item with the force it gets stuck inside the floor or the wall, and my trap_Trace() function is not determining the correct result, thus the sound engine keeps playing the *bounce* sound as if the item is bouncing, but it isn't, it ricocheting back and forth off the top and bottom of the inside of the map face.

 

So. I would like it if someone could explain in full detail the results of the trap_Trace function (basically what is stored in the trace_t structure)

 

Like for example:

My predictive trap_trace looks forward along the movement trajectory 24 units. i set the mins to -ITEM_RADIUS and the maxs to ITEM_RADIUS

 

trap_Trace(&tr, oldOrigin, mins, maxs, compareOrigin, movingEntityNum, MASK_PLAYERSOLID);

 

in this i check for tr.Fraction !=1 || tr.startsolid || tr.allsolid

however, in some circumstances the startsolid is ill-flagged in this attempts so I do a second trace:

trap_Trace(&tr, oldOrigin, NULL, NULL, compareOrigin, movingEntityNum, MASK_PLAYERSOLID);

 

If the tr.startsolid is still true, i should cancel the move, meaning i've hit something.

 

However, this code is not working very well, as you can tell by my posting here and asking about this function. So, could anyone please provide a clear explanation of the results of trap_Trace so that I can understand exactly how to set the mins,maxs bounding boxes for the trace, as well as interpreting:

 

My object will hit a wall, the floor, the ceiling, a box, a crate, a ledge, a mover, a player, a vehicle, a you-name-it-something-can-not-move-through-this. *smile*

 

Thanks

Jaeden "Sifo Dyas" al'Raec Ruiner

[-=*Raz0r*=-]

You could try poking in the Q3 engine source as it has the same trace function. It's not too hard to find.

[XycaleTh]

Let's start with the function definition first:

trap_Trace (result, startpos, mins, maxs, endpos, skipnumber, collisionflags)

result: the trace_t - this is how the function returns the results of the trace.

startpos: where you want to start tracing from.

mins and maxs: like the mins/maxs of a player's bounding box. In your case, you want them to be the same as your item's bounding box.

endpos: where you want the trace to finish.

skipentity: the entity number you want to avoid collision detection against.

collisionflags: tells the function what sort of collision boxes you want to collide against.

 

Then we want to determine the result of this trace (I've taken this from q_shared.h):

typedef struct {
byte		allsolid;	// if true, plane is not valid
byte		startsolid;	// if true, the initial point was in a solid area
short		entityNum;	// entity the contacted sirface is a part of

float		fraction;	// time completed, 1.0 = didn't hit anything
vec3_t		endpos;		// final position
cplane_t	plane;		// surface normal at impact, transformed to world space
int			surfaceFlags;	// surface hit
int			contents;	// contents on other side of surface hit
} trace_t;

Each of the fields are explained in the code already, but I can add a bit more information:

 

allsolid: true if the object you were testing was inside a solid the entire trace.

startsolid: true if the object you were testing started inside another object.

entityNum: the entity number of the object that was collided against - this will be ENTITYNUM_WORLD for something that's not linked to an entity, e.g. a plain brush.

fraction: will be in the range 0.0 - 1.0, and indicates how far along the trace a collision took place (if any). obviously if fraction == 1.0, then the trace reached the end point without any collision.

endpos: the point of collision (if any)

plane: information about the plane which the collision took place against - this holds information such as the plane's equation.

surfaceFlags: the surface flags of the object collided against - I think this is for testing air-water/lava transitions?

conents: the colliding object's contents flags, e.g. MASK_PLAYERSOLID, MASK_SHOT, etc.

 

The biggest problem i have is that occasionally while moving an item with the force it gets stuck inside the floor or the wall, and my trap_Trace() function is not determining the correct result, thus the sound engine keeps playing the *bounce* sound as if the item is bouncing, but it isn't, it ricocheting back and forth off the top and bottom of the inside of the map face.....however, in some circumstances the startsolid is ill-flagged in this attempts

It might be that because it's touching the ground, it's registering as starting in a solid. I'm not sure what the trace function would do this in case - whether it detects the first collision AFTER the starting point, regardless of if it's already colliding with something, or whether it takes the first collision to be the result. If it's the first case (and you would be able to test it, just check if tr.fraction is 0.0 when tr.startsolid is true), then you could only check for tr.fraction != 1.0.

[JaedenRuiner]

It might be that because it's touching the ground, it's registering as starting in a solid. I'm not sure what the trace function would do this in case - whether it detects the first collision AFTER the starting point, regardless of if it's already colliding with something, or whether it takes the first collision to be the result. If it's the first case (and you would be able to test it, just check if tr.fraction is 0.0 when tr.startsolid is true), then you could only check for tr.fraction != 1.0.

 

Hrm. Okay, First, that was very helpful in explaining what the parts of the trajectory_t structure mean. i've looked at the inline documentation and figured it was like that, but it isn't, as one might say, accurate in its determination. Often times things are flagged when they shouldn't be or the trace hiccups, with minutia that wouldn't normally be a factor.

 

So I will list out my code and then list the results:

 

My code is implementing a force grab, like a pull/push on items, but instead of just moving them, it grabs them and they subsequently can become a bludgeoning weapon. in my think() method for the item, i am moving it around until it hits something, which cancels the grab and the item bounces away. pretty straight forward.

 

first I do a trap_trace() starting at the object's current location with an end position about 24 units further along the current trajectory. my trap_Trace() uses the mins, maxs set to vectors at -ITEM_RADIUS and +ITEM_RADIUS for each item. this is the tricky part.

 

Yes, when the item, say a weapon, is floating on top its little hover thing where one can pick up the items, it works fine until i hit something. however, when it is lying on the ground, i can grab it, but the moment i move, it falls back down again. I noticed at this time startsolid was true. So i thought about doing another test, but my only theory for the second test was to remove the mins,maxs, or the bounding box around the item. The trap_Trace() seems to detect collisions for any area around the origin that is contained within the boudnign box. So, for the second trap_trace() with NULL instead of min and max, i get different values. I had the system Com_Printf() out the values and these are my results:

 

1. Tr = Start: 1, All: 1, Fract: 0.000, Ent: 1022, Pos(140.597, 20.730, -8.756)

2. Tr = Start: 0, All: 0, Fract: 1.000, Ent: 1023, Pos(140.597, 20.730, -8.756)

 

1. Tr = Start: 0, All: 0, Fract: 0.774, Ent: 1022, Pos(18.527, -6.771, -0.875)

 

1. Tr = Start: 1, All: 1, Fract: 0.000, Ent: 1022, Pos(154.887, 28.865, -7.479)

2. Tr = Start: 0, All: 0, Fract: 1.000, Ent: 1023, Pos(154.887, 28.865, -7.479)

 

1. Tr = Start: 1, All: 0, Fract: 1.000, Ent: 1023, Pos(159.430, 25.361, 14.508)

 

1. Tr = Start: 1, All: 0, Fract: 1.000, Ent: 1023, Pos(47.179, -63.674, 14.925)

 

1. Tr = Start: 1, All: 1, Fract: 0.000, Ent: 1022, Pos(25.908, -113.040, -4.655)

2. Tr = Start: 0, All: 0, Fract: 1.000, Ent: 1023, Pos(51.164, -122.102, -4.655)

 

1. Tr = Start: 1, All: 0, Fract: 1.000, Ent: 1023, Pos(62.883, -127.932, 10.647)

 

1. Tr = Start: 1, All: 1, Fract: 0.000, Ent: 1022, Pos(21.971, -109.270, -10.904)

2. Tr = Start: 0, All: 0, Fract: 1.000, Ent: 1023, Pos(42.560, -124.218, -10.904)

 

1. Tr = Start: 1, All: 1, Fract: 0.000, Ent: 1022, Pos(29.604, -115.936, -9.992)

2. Tr = Start: 0, All: 0, Fract: 1.000, Ent: 1023, Pos(62.724, -138.012, -7.349)

 

the 1. tagged lines are the values from the first trap trace with the mins and maxs, the 2. tagged lines are from when i have NULL instead.

 

Occasionally when i pick up the item, startsolid and allsolid are true and fraction is 0. other times when i pick up the item, startsolid is true and fraction is 1. I need to find the pattern in this that helps me determine that the trap_trace is ill-legitimately pegging the min,max as starting solid when it is right above the ground, and thus which values i can use to make sure the second trap_trace() verifies the actual collision. I'm thinking using the entitynum to help to a degree, but even that isn't perfect. the problem is the bounding box intersects with the current plane the item is resting on, so it is detecting a startsolid collision, when it shouldn't. this is what i'm trying to compensate for, so that when the object is moving through the air, the bounding box helps to predict an actual collision, but when i'm picking it up from the ground the bounding box doesn't cause a false positive.

Thanks

J"SD"a'RR