[Chdata]

PHP Code:

/**
 * Starts up a new trace hull using a global trace result.
 *
 * @param pos            Starting position of the ray.
 * @param vec            Ending position of the ray.
 * @param mins            Hull minimum size.
 * @param maxs            Hull maximum size.
 * @param flags            Trace flags.
 * @noreturn
 */
native TR_TraceHull(const Float:pos[3],
                    const Float:vec[3],
                    const Float:mins[3],
                    const Float:maxs[3],
                    flags); 


This is what I think TraceHull does:

vPos is the "center of the box"

vMin and vMax are points that define the "bottom corner" and "opposite upper corner" of the box, offset from vPos

vVec an angle of rotation for the box and the documentation is really weird for mentioning the raytype

(Yes I know it's an old include, API says it's the endpoint of the ray, but afaik hulls are boxes instead of rays)

What I'm really unclear of is vVec.

[Mitchell]

uh i think trace hull works just like a trace line, pos is the start, vec is the end. Then mins and maxs extends the line into a prism.

[asherkin]

It's a box swept along a ray, vPos/vVec define the ray, vMin/vMax define the box.

[Blowst]

[h3bus]

Also note that the position returned when you retreive the hit position is where the center of the hull was along vVec when hit occured, and not the actual hit position inside the hull.

[Chdata]

And the box is rotated the same way as (parallel to) the ray, correct?

[Miu]

Originally Posted by Chdata And the box is rotated the same way as (parallel to) the ray, correct?

no

[Chdata]

So if you trace hull with the mins/maxs of a player with start/end vec of the player's position, regardless of - okay I think I see it.

Because the hull is defined by the min/max points, those can never be rotated and will always match the XYZ directions of the world origins.

That is weird. I wonder if hulls in Unity are like this.

I guess that explains pyro's airblasting hitbox.

[friagram]

it takes way too much cpu to calculate and index stuff like that. For optimization everything is broken down to the simplest rectangular volumes. All coordinates, and calculations are done relative to the origin. These boxes are basic volumes which encapsulate objects.

For very complex or highly accurate calculations, you will use a finer set of boxes, or possibly vertex data. A good example is with prop traces. First it tests the maximum rectangular bounds of the object, then it will test each individual rectangular hotbox inside of that volume if it hits.

For things like physics, it will test the vertex data to determine where on the model (plane of the environment or model) the collision takes place. Using vertex data is extremely math intensive, and is used only when required to get a result (where object a hits object b, like a ball bouncing or projectile hit). Much of this data is produced by the client, for example, the server may say x bullet along y vector hits z model. The client must then calculate further where on the model that exactly hits, to leave a bullet decal. So the server can do minimal work.

Realize that the engine takes snapshots of every frame for x frames of all entity props, which is a lot of data. This is then used for lag compensation. Bounds, vertex and hitbox positions are not stored iirc, but are reconstructed when required based on the requested frame each time, which is calculated based off of various network timing settings.