-- [ Picked text/plain from multipart/alternative ] I really don't like the Physics system due to the many limitations we have with it, including tracing. Which is why I want to build my own trace.
I took a quick look at the Quake2 source code and they do a RecursiveHullTrace which I believe HL/HL2 uses, maybe if I mimic it and take into account the radius of my sphere I could get the trace I'm looking for. I'll have to test this method out and see how it pans out. If I do happen to get this trace working I'll be glad to share my results with the everyone. On 9/26/07, Paul Peloski <[EMAIL PROTECTED]> wrote: > > -- > [ Picked text/plain from multipart/alternative ] > Does physenv->CreateSphereObject do what you want? Check out CPhysSphere, > which creates a sphere instead of using the models physics data. I'm > assuming that, internally, creating a physics sphere this way will use > fast > sphere/plane intersection but Jay would know for sure. > > This way, you can make a spherical entity and handle collisions in > VPhysicsCollision. It's not a trace but it might work for you depending on > what you wanted to do with the trace. > > Regards, > > Paul > > On 9/25/07, Joel R. <[EMAIL PROTECTED]> wrote: > > > > -- > > [ Picked text/plain from multipart/alternative ] > > I've been attempting to create my own sphere trace using 2 engine > > functions. > > > > void GetBrushesInAABB( const Vector &vMins, const Vector &vMaxs, > > CUtlVector<int> *pOutput, int iContentsMask = 0xFFFFFFFF ) > > bool GetBrushInfo( int iBrush, CUtlVector<const cplane_t *> *pPlanesOut, > > int > > *pContentsOut ) > > > > I had 2 theories to go about doing this using a start/end point and a > > radius. > > > > First theory was to create a box around my start/end positions and grab > > all > > plane data within the confines of this box. > > I'd do something like so: > > > > float d1 = (plane.dist - radius) - start; > > float d2 = (plane.dist - radius) - end; > > > > and using that to determine for a hit/miss based on the positive and > > negative values of the distance. However surrounding a box around my > > start/end would give me extra planes that'll give me a bunch of false > > positives on planes that are very tiny, since this algorithm is used for > > infinite sized planes.. > > > > Second theory was to slide the box in intervals and check for planes at > > each > > interval with a mins/max box the size of my radius. Then back checking > the > > distance to see if I hit or penetrated any planes within. > > > > Both of these methods seem to not work after thinking about different > > possibilities that could arise due to the infinite sized plane > algorithm. > > I > > then noticed there was extra values in the cplane_t structure that I'm > not > > very familiar with: cplane_t::signbit and cplane_t::type. What purpose > > do > > these serve for the plane? Do they help determine if I'm within the > > planes > > constrictions for a collision? > > > > Anyone out there familiar with collision detection could help me out? > I'd > > really like to have a sphere trace. > > -- > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > -- > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
