Re: [hlcoders] Creating a Sphere Trace
-- [ Picked text/plain from multipart/alternative ] I just noticed that HL1 has a TraceSphere function available. Did this function become flawed once the Physics system was entered in the the scene equation? Just wondering why it was removed from HL2. On Sep 29, 2007 4:50 PM, Daniel Menard <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > Not having a method of tracing a VCollide to the world really limits what > we > can do with prediction, especially when talking about vehicles. Since > VPhysics is essentially unpredictable in the networking sense, we can't > run > the collision code client-side (unless we limit ourselves to an AABB, > which > really won't work for proned players, cars, trucks, planes etc..). The > ability to sweep a collidable and implement our own physics in game code > would fix this... There is a SweepCollideable function in the physics > interface, but it is stubbed. > > We've found a happy medium, which is to have predictable simulation code > much like the players and having a Physics Shadow follow the object server > side. This works for flying vehicles (since most of the time they don't > hit > stuff). Any mod working with ground vehicles has a huge problem though, > since they're always colliding. Not predicting vehicles is an option, but > expect your player base to complain about laggy controls... > > On 9/29/07, John Sheu <[EMAIL PROTECTED]> wrote: > > > > Jay Stelly wrote: > > > But it's not a framework that lets you sweep a > > > vcollide against the entire scene - which is probably what you want > (and > > > what John wanted as I recall). In fact it's pretty straightforward to > > > extend vphysics to do this, but the current implementation would be > > > incredibly slow if you used any displacements at all because it would > > > have to consider each triangle separately. > > > > > > > That would be really nice. Or actually, would have been really nice. > > And kinda overdue, since the SDK-side framework is there > > > d) "physics tests only happen once per frame in static positions" - > not > > > exactly sure what you are trying to say here but it sounds incorrect > to > > > me. The movement in vphysics though not described as sweeps/traces is > > > still computed as continuous motion. It's not like all of the objects > > > move and then do a static test to see if they are inside another > object > > > or have passed through another object. The collisions are computed > > > continuously along the path of translation/rotation. It may still be > a > > > pain for your player movement strategy, but it certainly isn't > evaluated > > > in "static positions" if that helps to understand it better. > > > > > > > I realize that VPhysics fundamentally does continuous collisions. I've > > played around some with the Bullet physics library some, and an idea of > > how things work. (Whether this is a correct "idea" or not is another > > question.) What I mean was that from game code, you cannot evaluate > > collisions on a collideable from more than one position in a given > > frame, or move/sweep them during the frame for movement tests. > > > > -John Sheu > > > > ___ > > 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
Re: [hlcoders] Creating a Sphere Trace
-- [ Picked text/plain from multipart/alternative ] Not having a method of tracing a VCollide to the world really limits what we can do with prediction, especially when talking about vehicles. Since VPhysics is essentially unpredictable in the networking sense, we can't run the collision code client-side (unless we limit ourselves to an AABB, which really won't work for proned players, cars, trucks, planes etc..). The ability to sweep a collidable and implement our own physics in game code would fix this... There is a SweepCollideable function in the physics interface, but it is stubbed. We've found a happy medium, which is to have predictable simulation code much like the players and having a Physics Shadow follow the object server side. This works for flying vehicles (since most of the time they don't hit stuff). Any mod working with ground vehicles has a huge problem though, since they're always colliding. Not predicting vehicles is an option, but expect your player base to complain about laggy controls... On 9/29/07, John Sheu <[EMAIL PROTECTED]> wrote: > > Jay Stelly wrote: > > But it's not a framework that lets you sweep a > > vcollide against the entire scene - which is probably what you want (and > > what John wanted as I recall). In fact it's pretty straightforward to > > extend vphysics to do this, but the current implementation would be > > incredibly slow if you used any displacements at all because it would > > have to consider each triangle separately. > > > > That would be really nice. Or actually, would have been really nice. > And kinda overdue, since the SDK-side framework is there > > d) "physics tests only happen once per frame in static positions" - not > > exactly sure what you are trying to say here but it sounds incorrect to > > me. The movement in vphysics though not described as sweeps/traces is > > still computed as continuous motion. It's not like all of the objects > > move and then do a static test to see if they are inside another object > > or have passed through another object. The collisions are computed > > continuously along the path of translation/rotation. It may still be a > > pain for your player movement strategy, but it certainly isn't evaluated > > in "static positions" if that helps to understand it better. > > > > I realize that VPhysics fundamentally does continuous collisions. I've > played around some with the Bullet physics library some, and an idea of > how things work. (Whether this is a correct "idea" or not is another > question.) What I mean was that from game code, you cannot evaluate > collisions on a collideable from more than one position in a given > frame, or move/sweep them during the frame for movement tests. > > -John Sheu > > ___ > 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
Re: [hlcoders] Creating a Sphere Trace
Jay Stelly wrote: But it's not a framework that lets you sweep a vcollide against the entire scene - which is probably what you want (and what John wanted as I recall). In fact it's pretty straightforward to extend vphysics to do this, but the current implementation would be incredibly slow if you used any displacements at all because it would have to consider each triangle separately. That would be really nice. Or actually, would have been really nice. And kinda overdue, since the SDK-side framework is there d) "physics tests only happen once per frame in static positions" - not exactly sure what you are trying to say here but it sounds incorrect to me. The movement in vphysics though not described as sweeps/traces is still computed as continuous motion. It's not like all of the objects move and then do a static test to see if they are inside another object or have passed through another object. The collisions are computed continuously along the path of translation/rotation. It may still be a pain for your player movement strategy, but it certainly isn't evaluated in "static positions" if that helps to understand it better. I realize that VPhysics fundamentally does continuous collisions. I've played around some with the Bullet physics library some, and an idea of how things work. (Whether this is a correct "idea" or not is another question.) What I mean was that from game code, you cannot evaluate collisions on a collideable from more than one position in a given frame, or move/sweep them during the frame for movement tests. -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Creating a Sphere Trace
I have a few comments on this thread: a) The proposed algorithm for RecursiveHullTrace won't work. You can't just expand a fixed set of planes to produce a swept sphere vs. polyhedron test. The number of planes you'd need would be infinite because the surface of the expanded polyhedron (you're expanding the polyhedron by the sphere to reduce the swept sphere to a swept point) will be curved. Intuitively, it seems possible to reduce that to a small finite number if you dynamically calculate some of the planes (but you might have to know the set of all edges and vertices on the polyhedron in order to do this). These are effectively what people refer to as the "bevel" planes. They are the planes along the potential separating axes that are not on the surface of the polyhedron already. If it's possible to do this I'm sure there's some existing research around; google it. Anyway, it's definitely possible to write a sphere tracer against brushes if you consider the edges and verts as separate features. I'm just not sure you can express that as a fixed set of ray/plane tests since it seems like it will have some second order equations in it somewhere. So what I'm suggesting above is that those sqrt()s (to solve the second order equation) can be done in a prepass that computes some of the planes. b) This is kind of a dead-end anyway unless all you care about are brushes. This won't give you a true sphere trace in the sense that engine->TraceRay() does a trace against everything in the scene (displacements, vcollides, bboxes, hitboxes, custom traces, etc). c) I think (b) is what John means below when he says swept vcollides don't work. Swept vcollides work just fine in the sense that you can use vphysics to compute sweeps of vcollides against other vcollides or boxes vs. vcollides. But it's not a framework that lets you sweep a vcollide against the entire scene - which is probably what you want (and what John wanted as I recall). In fact it's pretty straightforward to extend vphysics to do this, but the current implementation would be incredibly slow if you used any displacements at all because it would have to consider each triangle separately. d) "physics tests only happen once per frame in static positions" - not exactly sure what you are trying to say here but it sounds incorrect to me. The movement in vphysics though not described as sweeps/traces is still computed as continuous motion. It's not like all of the objects move and then do a static test to see if they are inside another object or have passed through another object. The collisions are computed continuously along the path of translation/rotation. It may still be a pain for your player movement strategy, but it certainly isn't evaluated in "static positions" if that helps to understand it better. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Sheu Sent: Wednesday, September 26, 2007 3:35 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Creating a Sphere Trace Joel R. wrote: > -- > [ 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. The last time I was into this, the Source SDK as we have it has no support for sweeping anything other than AABBs. Swept "VCollides" don't work (I forgot the name exactly), and physics tests only happen once per frame in static positions. Really a PITA when you're trying to do anything with unusual player movement (read: proning, vehicles). -John Sheu ___ 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
Re: [hlcoders] Creating a Sphere Trace
Joel R. wrote: -- [ 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. The last time I was into this, the Source SDK as we have it has no support for sweeping anything other than AABBs. Swept "VCollides" don't work (I forgot the name exactly), and physics tests only happen once per frame in static positions. Really a PITA when you're trying to do anything with unusual player movement (read: proning, vehicles). -John Sheu ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Creating a Sphere Trace
-- [ 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 *pOutput, int iContentsMask = 0x ) > > bool GetBrushInfo( int iBrush, CUtlVector *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
Re: [hlcoders] Creating a Sphere Trace
-- [ 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 *pOutput, int iContentsMask = 0x ) > bool GetBrushInfo( int iBrush, CUtlVector *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
Re: [hlcoders] Creating a Sphere Trace
--
[ Picked text/plain from multipart/alternative ]
I think you misunderstood what I'm attempting. I'm trying to create a
Sphere Trace against the map planes, not entities. I probably should of put
that in the subject.
On 9/25/07, Ben Everett <[EMAIL PROTECTED]> wrote:
>
> CEntitySphereQuery.
>
> Example:
> CBaseEntity *ent = NULL;
>
> for (CEntitySphereQuery sphere(GetAbsOrigin(),
> FORSAKEN_SPAWN_RADIUS);
> (ent = sphere.GetCurrentEntity()) != NULL;
> sphere.NextEntity())
> {
> CBaseEntity *plent = ent;
>
> if ( plent && plent->IsPlayer() && plent !=
> pPlayer
> )
> return false;
> }
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Joel R.
> Sent: Tuesday, September 25, 2007 5:40 PM
> To: hlcoders
> Subject: [hlcoders] Creating a Sphere Trace
>
> --
> [ 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 *pOutput, int iContentsMask = 0x )
> bool GetBrushInfo( int iBrush, CUtlVector *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
>
>
> __ NOD32 2550 (20070925) Information __
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>
>
> ___
> 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
RE: [hlcoders] Creating a Sphere Trace
CEntitySphereQuery.
Example:
CBaseEntity *ent = NULL;
for (CEntitySphereQuery sphere(GetAbsOrigin(),
FORSAKEN_SPAWN_RADIUS);
(ent = sphere.GetCurrentEntity()) != NULL;
sphere.NextEntity())
{
CBaseEntity *plent = ent;
if ( plent && plent->IsPlayer() && plent != pPlayer
)
return false;
}
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joel R.
Sent: Tuesday, September 25, 2007 5:40 PM
To: hlcoders
Subject: [hlcoders] Creating a Sphere Trace
--
[ 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 *pOutput, int iContentsMask = 0x )
bool GetBrushInfo( int iBrush, CUtlVector *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
__ NOD32 2550 (20070925) Information __
This message was checked by NOD32 antivirus system.
http://www.eset.com
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
