Re: [hlcoders] Player HULL vs HIT BOXES
I just realized pre-defining them wouldn't help, because of the 9 way
blending stuff.
So scratch that horrible idea.
trepid_jon
- Original Message -
From: Ben Everett [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Thursday, January 18, 2007 11:41 PM
Subject: RE: [hlcoders] Player HULL vs HIT BOXES
Memory and CPU cycles are cheap ;)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jon Day
Sent: Thursday, January 18, 2007 10:29 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Player HULL vs HIT BOXES
I'm very interested in finding out how well Dystopia performs with the
USE_HITBOXES system as that really does seem like a good way to do it.
Could save CPU cycles if the bbox that USE_HITBOXES would compute was
instead pre-defined for each animation frame in the actual model/animation
files (or a new file for each model created by some new program), so the
game wouldn't have to go through each hitbox to create a bbox in
real-time.
I guess there would then be a tradeoff for memory, since there is an
insane
amount of animations as well as an insane amount of different hitboxes for
different models. But still, it might be worth it.
trepid_jon
- Original Message -
From: Teddy [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Thursday, January 18, 2007 9:48 PM
Subject: Re: [hlcoders] Player HULL vs HIT BOXES
Thanks Jay! The hacky workaround fixed the triggers through doors bug,
now i can have the best of both worlds. For anyone who's interested,
here's the code snippet:
void CDYSPlayer::PhysicsTouchTriggers( const Vector *pPrevAbsOrigin )
{
CollisionProp()-SetSurroundingBoundsType( USE_OBB_COLLISION_BOUNDS );
BaseClass::PhysicsTouchTriggers( pPrevAbsOrigin );
CollisionProp()-SetSurroundingBoundsType( USE_HITBOXES );
}
On 1/18/07, Jay Stelly [EMAIL PROTECTED] wrote:
Players touching triggers through thin doors is a bug. It will be fixed
a future version of the engine, but that's not going to help you now.
The important thing to know is the SolidMoved() is using surrounding
bounds to intersect with triggers rather than the bbox for SOLID_BBOX
objects like the player. You could do a bbox vs. trigger test in the
game DLL to fix it when the engine calls back to mark the ents as
touching and one is a FSOLID_TRIGGER and the other is SOLID_BBOX. A
hacky workaround would be switching to USE_SPECIFIED_BOUNDS or
USE_GAME_CODE just before the call to engine-SolidMoved() when the
solid entity moving is a player and then switching back to hitbox after.
The second issue is supposed to happen though - I mean either you want
it to hit the hitboxes outside the hull or you don't. If you only want
to hit them when they aren't protruding through some geometry you'll
have to add some kind of code to detect that condition and account for
it. As a heuristic you could trace a ray back from the impact point to
the center of the player (ignoring the player) and make sure it makes it
and filter out the hit if it doesn't...
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Teddy
Sent: Wednesday, January 17, 2007 8:35 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Player HULL vs HIT BOXES
Some major issues have appeared as a result of this change,
I've had to revert it unfortunately. Players were able to
touch triggers through thin doors, and get shot if any part
of their model was protruding through a brush/prop/etc.
I looked into setting the surrounding bounds before any
weapons ray trace runs, but this eats up alot of CPU time,
and doesn't work with projectile weapons anyways..
So the only solution I've got now is to modify all the player
model animations so they don't stray outside the movement
collision bounds,
-or- increase the size of the movement collision bounds. Our
mappers will kill me if i do that (especially this close to
release)!!!
Anyone got any advice or a workaround for this problem?
Cheers,
Teddy
On 1/17/07, Teddy [EMAIL PROTECTED] wrote:
Thanks Jay,
I did some measuring, and it had very little impact on
performance. It
turns out, near misses are pretty frequent (must be those 30
raytrace/sec weapons)!
Nic2:
Try putting the call to SetSurroundingBoundsType at the end of the
spawn function, just in case something in the baseclass is
overriding
it
-Teddy
On 1/16/07, Jay Stelly [EMAIL PROTECTED] wrote:
I tried to answer this in the wiki page:
USE_SPECIFIED_BOUNDS could also be used to solve this problem by
specifying a constant box that is always larger than the space
occupied by hitboxes in any animation. As a tradeoff,
this will be
cheaper than USE_HITBOXES as the player animates and
moves, but more
a conservative boundary resulting in more hitbox queries
happening
against ray tests that miss. The highest performance method will
depend on the mod's
Re: [hlcoders] Player HULL vs HIT BOXES
Thanks Jay! The hacky workaround fixed the triggers through doors bug,
now i can have the best of both worlds. For anyone who's interested,
here's the code snippet:
void CDYSPlayer::PhysicsTouchTriggers( const Vector *pPrevAbsOrigin )
{
CollisionProp()-SetSurroundingBoundsType( USE_OBB_COLLISION_BOUNDS );
BaseClass::PhysicsTouchTriggers( pPrevAbsOrigin );
CollisionProp()-SetSurroundingBoundsType( USE_HITBOXES );
}
On 1/18/07, Jay Stelly [EMAIL PROTECTED] wrote:
Players touching triggers through thin doors is a bug. It will be fixed
a future version of the engine, but that's not going to help you now.
The important thing to know is the SolidMoved() is using surrounding
bounds to intersect with triggers rather than the bbox for SOLID_BBOX
objects like the player. You could do a bbox vs. trigger test in the
game DLL to fix it when the engine calls back to mark the ents as
touching and one is a FSOLID_TRIGGER and the other is SOLID_BBOX. A
hacky workaround would be switching to USE_SPECIFIED_BOUNDS or
USE_GAME_CODE just before the call to engine-SolidMoved() when the
solid entity moving is a player and then switching back to hitbox after.
The second issue is supposed to happen though - I mean either you want
it to hit the hitboxes outside the hull or you don't. If you only want
to hit them when they aren't protruding through some geometry you'll
have to add some kind of code to detect that condition and account for
it. As a heuristic you could trace a ray back from the impact point to
the center of the player (ignoring the player) and make sure it makes it
and filter out the hit if it doesn't...
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Teddy
Sent: Wednesday, January 17, 2007 8:35 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Player HULL vs HIT BOXES
Some major issues have appeared as a result of this change,
I've had to revert it unfortunately. Players were able to
touch triggers through thin doors, and get shot if any part
of their model was protruding through a brush/prop/etc.
I looked into setting the surrounding bounds before any
weapons ray trace runs, but this eats up alot of CPU time,
and doesn't work with projectile weapons anyways..
So the only solution I've got now is to modify all the player
model animations so they don't stray outside the movement
collision bounds,
-or- increase the size of the movement collision bounds. Our
mappers will kill me if i do that (especially this close to
release)!!!
Anyone got any advice or a workaround for this problem?
Cheers,
Teddy
On 1/17/07, Teddy [EMAIL PROTECTED] wrote:
Thanks Jay,
I did some measuring, and it had very little impact on
performance. It
turns out, near misses are pretty frequent (must be those 30
raytrace/sec weapons)!
Nic2:
Try putting the call to SetSurroundingBoundsType at the end of the
spawn function, just in case something in the baseclass is
overriding
it
-Teddy
On 1/16/07, Jay Stelly [EMAIL PROTECTED] wrote:
I tried to answer this in the wiki page:
USE_SPECIFIED_BOUNDS could also be used to solve this problem by
specifying a constant box that is always larger than the space
occupied by hitboxes in any animation. As a tradeoff,
this will be
cheaper than USE_HITBOXES as the player animates and
moves, but more
a conservative boundary resulting in more hitbox queries
happening
against ray tests that miss. The highest performance method will
depend on the mod's number of players moving vs. number
of ray/box
traces computed against players (and how many of those
queries actually miss).
It really depends on several variables (like how many
rays are near
misses, the number of hitboxes and the complexity of the player
skeleton). The only way to determine exactly how much is to
measure it in your mod. HL2 uses this method for
striders' bounds
so it's not insanely expensive or anything, just more
expensive when
you have only a few ray traces nearly missing players in
a frame.
It may be less expensive if you have a enough rays being
rejected as
a result or less expensive if the animation of the player varies
enough to require a large enough USE_SPECIFIED_BOX.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Teddy
Sent: Monday, January 15, 2007 7:29 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Player HULL vs HIT BOXES
Exactly how much more load does USE_HITBOXES put on the server,
say for a 16 player with a similar amout of raycasts as
counterstrike (for example)?
I've found it gives much more accurate reg on player's
extremities, but i wonder at what cost? Would it be cheaper to
make an exagerated bbox using USE_SPECIFIED_BOUNDS (considering
all the extra ray casts that may
Re: [hlcoders] Player HULL vs HIT BOXES
I'm very interested in finding out how well Dystopia performs with the
USE_HITBOXES system as that really does seem like a good way to do it.
Could save CPU cycles if the bbox that USE_HITBOXES would compute was
instead pre-defined for each animation frame in the actual model/animation
files (or a new file for each model created by some new program), so the
game wouldn't have to go through each hitbox to create a bbox in real-time.
I guess there would then be a tradeoff for memory, since there is an insane
amount of animations as well as an insane amount of different hitboxes for
different models. But still, it might be worth it.
trepid_jon
- Original Message -
From: Teddy [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Thursday, January 18, 2007 9:48 PM
Subject: Re: [hlcoders] Player HULL vs HIT BOXES
Thanks Jay! The hacky workaround fixed the triggers through doors bug,
now i can have the best of both worlds. For anyone who's interested,
here's the code snippet:
void CDYSPlayer::PhysicsTouchTriggers( const Vector *pPrevAbsOrigin )
{
CollisionProp()-SetSurroundingBoundsType( USE_OBB_COLLISION_BOUNDS );
BaseClass::PhysicsTouchTriggers( pPrevAbsOrigin );
CollisionProp()-SetSurroundingBoundsType( USE_HITBOXES );
}
On 1/18/07, Jay Stelly [EMAIL PROTECTED] wrote:
Players touching triggers through thin doors is a bug. It will be fixed
a future version of the engine, but that's not going to help you now.
The important thing to know is the SolidMoved() is using surrounding
bounds to intersect with triggers rather than the bbox for SOLID_BBOX
objects like the player. You could do a bbox vs. trigger test in the
game DLL to fix it when the engine calls back to mark the ents as
touching and one is a FSOLID_TRIGGER and the other is SOLID_BBOX. A
hacky workaround would be switching to USE_SPECIFIED_BOUNDS or
USE_GAME_CODE just before the call to engine-SolidMoved() when the
solid entity moving is a player and then switching back to hitbox after.
The second issue is supposed to happen though - I mean either you want
it to hit the hitboxes outside the hull or you don't. If you only want
to hit them when they aren't protruding through some geometry you'll
have to add some kind of code to detect that condition and account for
it. As a heuristic you could trace a ray back from the impact point to
the center of the player (ignoring the player) and make sure it makes it
and filter out the hit if it doesn't...
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Teddy
Sent: Wednesday, January 17, 2007 8:35 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Player HULL vs HIT BOXES
Some major issues have appeared as a result of this change,
I've had to revert it unfortunately. Players were able to
touch triggers through thin doors, and get shot if any part
of their model was protruding through a brush/prop/etc.
I looked into setting the surrounding bounds before any
weapons ray trace runs, but this eats up alot of CPU time,
and doesn't work with projectile weapons anyways..
So the only solution I've got now is to modify all the player
model animations so they don't stray outside the movement
collision bounds,
-or- increase the size of the movement collision bounds. Our
mappers will kill me if i do that (especially this close to
release)!!!
Anyone got any advice or a workaround for this problem?
Cheers,
Teddy
On 1/17/07, Teddy [EMAIL PROTECTED] wrote:
Thanks Jay,
I did some measuring, and it had very little impact on
performance. It
turns out, near misses are pretty frequent (must be those 30
raytrace/sec weapons)!
Nic2:
Try putting the call to SetSurroundingBoundsType at the end of the
spawn function, just in case something in the baseclass is
overriding
it
-Teddy
On 1/16/07, Jay Stelly [EMAIL PROTECTED] wrote:
I tried to answer this in the wiki page:
USE_SPECIFIED_BOUNDS could also be used to solve this problem by
specifying a constant box that is always larger than the space
occupied by hitboxes in any animation. As a tradeoff,
this will be
cheaper than USE_HITBOXES as the player animates and
moves, but more
a conservative boundary resulting in more hitbox queries
happening
against ray tests that miss. The highest performance method will
depend on the mod's number of players moving vs. number
of ray/box
traces computed against players (and how many of those
queries actually miss).
It really depends on several variables (like how many
rays are near
misses, the number of hitboxes and the complexity of the player
skeleton). The only way to determine exactly how much is to
measure it in your mod. HL2 uses this method for
striders' bounds
so it's not insanely expensive or anything, just more
expensive when
you have only a few ray traces nearly missing players in
a frame.
It may be less expensive if you have
RE: [hlcoders] Player HULL vs HIT BOXES
Memory and CPU cycles are cheap ;)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jon Day
Sent: Thursday, January 18, 2007 10:29 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Player HULL vs HIT BOXES
I'm very interested in finding out how well Dystopia performs with the
USE_HITBOXES system as that really does seem like a good way to do it.
Could save CPU cycles if the bbox that USE_HITBOXES would compute was
instead pre-defined for each animation frame in the actual model/animation
files (or a new file for each model created by some new program), so the
game wouldn't have to go through each hitbox to create a bbox in real-time.
I guess there would then be a tradeoff for memory, since there is an insane
amount of animations as well as an insane amount of different hitboxes for
different models. But still, it might be worth it.
trepid_jon
- Original Message -
From: Teddy [EMAIL PROTECTED]
To: hlcoders@list.valvesoftware.com
Sent: Thursday, January 18, 2007 9:48 PM
Subject: Re: [hlcoders] Player HULL vs HIT BOXES
Thanks Jay! The hacky workaround fixed the triggers through doors bug,
now i can have the best of both worlds. For anyone who's interested,
here's the code snippet:
void CDYSPlayer::PhysicsTouchTriggers( const Vector *pPrevAbsOrigin )
{
CollisionProp()-SetSurroundingBoundsType( USE_OBB_COLLISION_BOUNDS );
BaseClass::PhysicsTouchTriggers( pPrevAbsOrigin );
CollisionProp()-SetSurroundingBoundsType( USE_HITBOXES );
}
On 1/18/07, Jay Stelly [EMAIL PROTECTED] wrote:
Players touching triggers through thin doors is a bug. It will be fixed
a future version of the engine, but that's not going to help you now.
The important thing to know is the SolidMoved() is using surrounding
bounds to intersect with triggers rather than the bbox for SOLID_BBOX
objects like the player. You could do a bbox vs. trigger test in the
game DLL to fix it when the engine calls back to mark the ents as
touching and one is a FSOLID_TRIGGER and the other is SOLID_BBOX. A
hacky workaround would be switching to USE_SPECIFIED_BOUNDS or
USE_GAME_CODE just before the call to engine-SolidMoved() when the
solid entity moving is a player and then switching back to hitbox after.
The second issue is supposed to happen though - I mean either you want
it to hit the hitboxes outside the hull or you don't. If you only want
to hit them when they aren't protruding through some geometry you'll
have to add some kind of code to detect that condition and account for
it. As a heuristic you could trace a ray back from the impact point to
the center of the player (ignoring the player) and make sure it makes it
and filter out the hit if it doesn't...
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Teddy
Sent: Wednesday, January 17, 2007 8:35 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] Player HULL vs HIT BOXES
Some major issues have appeared as a result of this change,
I've had to revert it unfortunately. Players were able to
touch triggers through thin doors, and get shot if any part
of their model was protruding through a brush/prop/etc.
I looked into setting the surrounding bounds before any
weapons ray trace runs, but this eats up alot of CPU time,
and doesn't work with projectile weapons anyways..
So the only solution I've got now is to modify all the player
model animations so they don't stray outside the movement
collision bounds,
-or- increase the size of the movement collision bounds. Our
mappers will kill me if i do that (especially this close to
release)!!!
Anyone got any advice or a workaround for this problem?
Cheers,
Teddy
On 1/17/07, Teddy [EMAIL PROTECTED] wrote:
Thanks Jay,
I did some measuring, and it had very little impact on
performance. It
turns out, near misses are pretty frequent (must be those 30
raytrace/sec weapons)!
Nic2:
Try putting the call to SetSurroundingBoundsType at the end of the
spawn function, just in case something in the baseclass is
overriding
it
-Teddy
On 1/16/07, Jay Stelly [EMAIL PROTECTED] wrote:
I tried to answer this in the wiki page:
USE_SPECIFIED_BOUNDS could also be used to solve this problem by
specifying a constant box that is always larger than the space
occupied by hitboxes in any animation. As a tradeoff,
this will be
cheaper than USE_HITBOXES as the player animates and
moves, but more
a conservative boundary resulting in more hitbox queries
happening
against ray tests that miss. The highest performance method will
depend on the mod's number of players moving vs. number
of ray/box
traces computed against players (and how many of those
queries actually miss).
It really depends on several variables (like how many
rays are near
misses, the number of hitboxes
Re: [hlcoders] Player HULL vs HIT BOXES
Some major issues have appeared as a result of this change, I've had to revert it unfortunately. Players were able to touch triggers through thin doors, and get shot if any part of their model was protruding through a brush/prop/etc. I looked into setting the surrounding bounds before any weapons ray trace runs, but this eats up alot of CPU time, and doesn't work with projectile weapons anyways.. So the only solution I've got now is to modify all the player model animations so they don't stray outside the movement collision bounds, -or- increase the size of the movement collision bounds. Our mappers will kill me if i do that (especially this close to release)!!! Anyone got any advice or a workaround for this problem? Cheers, Teddy On 1/17/07, Teddy [EMAIL PROTECTED] wrote: Thanks Jay, I did some measuring, and it had very little impact on performance. It turns out, near misses are pretty frequent (must be those 30 raytrace/sec weapons)! Nic2: Try putting the call to SetSurroundingBoundsType at the end of the spawn function, just in case something in the baseclass is overriding it -Teddy On 1/16/07, Jay Stelly [EMAIL PROTECTED] wrote: I tried to answer this in the wiki page: USE_SPECIFIED_BOUNDS could also be used to solve this problem by specifying a constant box that is always larger than the space occupied by hitboxes in any animation. As a tradeoff, this will be cheaper than USE_HITBOXES as the player animates and moves, but more a conservative boundary resulting in more hitbox queries happening against ray tests that miss. The highest performance method will depend on the mod's number of players moving vs. number of ray/box traces computed against players (and how many of those queries actually miss). It really depends on several variables (like how many rays are near misses, the number of hitboxes and the complexity of the player skeleton). The only way to determine exactly how much is to measure it in your mod. HL2 uses this method for striders' bounds so it's not insanely expensive or anything, just more expensive when you have only a few ray traces nearly missing players in a frame. It may be less expensive if you have a enough rays being rejected as a result or less expensive if the animation of the player varies enough to require a large enough USE_SPECIFIED_BOX. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Teddy Sent: Monday, January 15, 2007 7:29 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Player HULL vs HIT BOXES Exactly how much more load does USE_HITBOXES put on the server, say for a 16 player with a similar amout of raycasts as counterstrike (for example)? I've found it gives much more accurate reg on player's extremities, but i wonder at what cost? Would it be cheaper to make an exagerated bbox using USE_SPECIFIED_BOUNDS (considering all the extra ray casts that may collide)? On 1/11/07, Jay Stelly [EMAIL PROTECTED] wrote: Hitboxes are only tested when the ray/box trace intersects the surrounding bounds of the entity. For players the surrounding bounds are simply the collision hull in world space. In your case that won't work so you'll need to modify the surrounding bounds. I just wrote a page on the wiki that should answer your question: http://developer.valvesoftware.com/wiki/CollisionProperty Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Minh Sent: Wednesday, January 10, 2007 11:01 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Player HULL vs HIT BOXES I believe any hitbox that lies outside of the player's hull cannot be hit. I am pretty sure you must keep your hitboxes inside of the hull. So you cannot make your hull too small or else the traceline will not detect the hitbox. - Original Message - From: Niclas [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, January 10, 2007 2:44 AM Subject: [hlcoders] Player HULL vs HIT BOXES -- [ Picked text/plain from multipart/alternative ] I changed the player hull and view to very low and now it seems like I cant hit the model over that hull (projectiles go right through) even though that the hitboxes cover the whole model (custom model). - Nic2 -- ___ 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] Player HULL vs HIT BOXES
Players touching triggers through thin doors is a bug. It will be fixed a future version of the engine, but that's not going to help you now. The important thing to know is the SolidMoved() is using surrounding bounds to intersect with triggers rather than the bbox for SOLID_BBOX objects like the player. You could do a bbox vs. trigger test in the game DLL to fix it when the engine calls back to mark the ents as touching and one is a FSOLID_TRIGGER and the other is SOLID_BBOX. A hacky workaround would be switching to USE_SPECIFIED_BOUNDS or USE_GAME_CODE just before the call to engine-SolidMoved() when the solid entity moving is a player and then switching back to hitbox after. The second issue is supposed to happen though - I mean either you want it to hit the hitboxes outside the hull or you don't. If you only want to hit them when they aren't protruding through some geometry you'll have to add some kind of code to detect that condition and account for it. As a heuristic you could trace a ray back from the impact point to the center of the player (ignoring the player) and make sure it makes it and filter out the hit if it doesn't... Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Teddy Sent: Wednesday, January 17, 2007 8:35 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Player HULL vs HIT BOXES Some major issues have appeared as a result of this change, I've had to revert it unfortunately. Players were able to touch triggers through thin doors, and get shot if any part of their model was protruding through a brush/prop/etc. I looked into setting the surrounding bounds before any weapons ray trace runs, but this eats up alot of CPU time, and doesn't work with projectile weapons anyways.. So the only solution I've got now is to modify all the player model animations so they don't stray outside the movement collision bounds, -or- increase the size of the movement collision bounds. Our mappers will kill me if i do that (especially this close to release)!!! Anyone got any advice or a workaround for this problem? Cheers, Teddy On 1/17/07, Teddy [EMAIL PROTECTED] wrote: Thanks Jay, I did some measuring, and it had very little impact on performance. It turns out, near misses are pretty frequent (must be those 30 raytrace/sec weapons)! Nic2: Try putting the call to SetSurroundingBoundsType at the end of the spawn function, just in case something in the baseclass is overriding it -Teddy On 1/16/07, Jay Stelly [EMAIL PROTECTED] wrote: I tried to answer this in the wiki page: USE_SPECIFIED_BOUNDS could also be used to solve this problem by specifying a constant box that is always larger than the space occupied by hitboxes in any animation. As a tradeoff, this will be cheaper than USE_HITBOXES as the player animates and moves, but more a conservative boundary resulting in more hitbox queries happening against ray tests that miss. The highest performance method will depend on the mod's number of players moving vs. number of ray/box traces computed against players (and how many of those queries actually miss). It really depends on several variables (like how many rays are near misses, the number of hitboxes and the complexity of the player skeleton). The only way to determine exactly how much is to measure it in your mod. HL2 uses this method for striders' bounds so it's not insanely expensive or anything, just more expensive when you have only a few ray traces nearly missing players in a frame. It may be less expensive if you have a enough rays being rejected as a result or less expensive if the animation of the player varies enough to require a large enough USE_SPECIFIED_BOX. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Teddy Sent: Monday, January 15, 2007 7:29 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Player HULL vs HIT BOXES Exactly how much more load does USE_HITBOXES put on the server, say for a 16 player with a similar amout of raycasts as counterstrike (for example)? I've found it gives much more accurate reg on player's extremities, but i wonder at what cost? Would it be cheaper to make an exagerated bbox using USE_SPECIFIED_BOUNDS (considering all the extra ray casts that may collide)? On 1/11/07, Jay Stelly [EMAIL PROTECTED] wrote: Hitboxes are only tested when the ray/box trace intersects the surrounding bounds of the entity. For players the surrounding bounds are simply the collision hull in world space. In your case that won't work so you'll need to modify the surrounding bounds. I just wrote a page on the wiki that should answer your question: http://developer.valvesoftware.com/wiki
Re: [hlcoders] Player HULL vs HIT BOXES
Thanks Jay, I did some measuring, and it had very little impact on performance. It turns out, near misses are pretty frequent (must be those 30 raytrace/sec weapons)! Nic2: Try putting the call to SetSurroundingBoundsType at the end of the spawn function, just in case something in the baseclass is overriding it -Teddy On 1/16/07, Jay Stelly [EMAIL PROTECTED] wrote: I tried to answer this in the wiki page: USE_SPECIFIED_BOUNDS could also be used to solve this problem by specifying a constant box that is always larger than the space occupied by hitboxes in any animation. As a tradeoff, this will be cheaper than USE_HITBOXES as the player animates and moves, but more a conservative boundary resulting in more hitbox queries happening against ray tests that miss. The highest performance method will depend on the mod's number of players moving vs. number of ray/box traces computed against players (and how many of those queries actually miss). It really depends on several variables (like how many rays are near misses, the number of hitboxes and the complexity of the player skeleton). The only way to determine exactly how much is to measure it in your mod. HL2 uses this method for striders' bounds so it's not insanely expensive or anything, just more expensive when you have only a few ray traces nearly missing players in a frame. It may be less expensive if you have a enough rays being rejected as a result or less expensive if the animation of the player varies enough to require a large enough USE_SPECIFIED_BOX. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Teddy Sent: Monday, January 15, 2007 7:29 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Player HULL vs HIT BOXES Exactly how much more load does USE_HITBOXES put on the server, say for a 16 player with a similar amout of raycasts as counterstrike (for example)? I've found it gives much more accurate reg on player's extremities, but i wonder at what cost? Would it be cheaper to make an exagerated bbox using USE_SPECIFIED_BOUNDS (considering all the extra ray casts that may collide)? On 1/11/07, Jay Stelly [EMAIL PROTECTED] wrote: Hitboxes are only tested when the ray/box trace intersects the surrounding bounds of the entity. For players the surrounding bounds are simply the collision hull in world space. In your case that won't work so you'll need to modify the surrounding bounds. I just wrote a page on the wiki that should answer your question: http://developer.valvesoftware.com/wiki/CollisionProperty Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Minh Sent: Wednesday, January 10, 2007 11:01 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Player HULL vs HIT BOXES I believe any hitbox that lies outside of the player's hull cannot be hit. I am pretty sure you must keep your hitboxes inside of the hull. So you cannot make your hull too small or else the traceline will not detect the hitbox. - Original Message - From: Niclas [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, January 10, 2007 2:44 AM Subject: [hlcoders] Player HULL vs HIT BOXES -- [ Picked text/plain from multipart/alternative ] I changed the player hull and view to very low and now it seems like I cant hit the model over that hull (projectiles go right through) even though that the hitboxes cover the whole model (custom model). - Nic2 -- ___ 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 ___ 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] Player HULL vs HIT BOXES
Exactly how much more load does USE_HITBOXES put on the server, say for a 16 player with a similar amout of raycasts as counterstrike (for example)? I've found it gives much more accurate reg on player's extremities, but i wonder at what cost? Would it be cheaper to make an exagerated bbox using USE_SPECIFIED_BOUNDS (considering all the extra ray casts that may collide)? On 1/11/07, Jay Stelly [EMAIL PROTECTED] wrote: Hitboxes are only tested when the ray/box trace intersects the surrounding bounds of the entity. For players the surrounding bounds are simply the collision hull in world space. In your case that won't work so you'll need to modify the surrounding bounds. I just wrote a page on the wiki that should answer your question: http://developer.valvesoftware.com/wiki/CollisionProperty Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Minh Sent: Wednesday, January 10, 2007 11:01 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Player HULL vs HIT BOXES I believe any hitbox that lies outside of the player's hull cannot be hit. I am pretty sure you must keep your hitboxes inside of the hull. So you cannot make your hull too small or else the traceline will not detect the hitbox. - Original Message - From: Niclas [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, January 10, 2007 2:44 AM Subject: [hlcoders] Player HULL vs HIT BOXES -- [ Picked text/plain from multipart/alternative ] I changed the player hull and view to very low and now it seems like I cant hit the model over that hull (projectiles go right through) even though that the hitboxes cover the whole model (custom model). - Nic2 -- ___ 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Player HULL vs HIT BOXES
I tried to answer this in the wiki page: USE_SPECIFIED_BOUNDS could also be used to solve this problem by specifying a constant box that is always larger than the space occupied by hitboxes in any animation. As a tradeoff, this will be cheaper than USE_HITBOXES as the player animates and moves, but more a conservative boundary resulting in more hitbox queries happening against ray tests that miss. The highest performance method will depend on the mod's number of players moving vs. number of ray/box traces computed against players (and how many of those queries actually miss). It really depends on several variables (like how many rays are near misses, the number of hitboxes and the complexity of the player skeleton). The only way to determine exactly how much is to measure it in your mod. HL2 uses this method for striders' bounds so it's not insanely expensive or anything, just more expensive when you have only a few ray traces nearly missing players in a frame. It may be less expensive if you have a enough rays being rejected as a result or less expensive if the animation of the player varies enough to require a large enough USE_SPECIFIED_BOX. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Teddy Sent: Monday, January 15, 2007 7:29 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Player HULL vs HIT BOXES Exactly how much more load does USE_HITBOXES put on the server, say for a 16 player with a similar amout of raycasts as counterstrike (for example)? I've found it gives much more accurate reg on player's extremities, but i wonder at what cost? Would it be cheaper to make an exagerated bbox using USE_SPECIFIED_BOUNDS (considering all the extra ray casts that may collide)? On 1/11/07, Jay Stelly [EMAIL PROTECTED] wrote: Hitboxes are only tested when the ray/box trace intersects the surrounding bounds of the entity. For players the surrounding bounds are simply the collision hull in world space. In your case that won't work so you'll need to modify the surrounding bounds. I just wrote a page on the wiki that should answer your question: http://developer.valvesoftware.com/wiki/CollisionProperty Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Minh Sent: Wednesday, January 10, 2007 11:01 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Player HULL vs HIT BOXES I believe any hitbox that lies outside of the player's hull cannot be hit. I am pretty sure you must keep your hitboxes inside of the hull. So you cannot make your hull too small or else the traceline will not detect the hitbox. - Original Message - From: Niclas [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, January 10, 2007 2:44 AM Subject: [hlcoders] Player HULL vs HIT BOXES -- [ Picked text/plain from multipart/alternative ] I changed the player hull and view to very low and now it seems like I cant hit the model over that hull (projectiles go right through) even though that the hitboxes cover the whole model (custom model). - Nic2 -- ___ 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 ___ 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] Player HULL vs HIT BOXES
I believe any hitbox that lies outside of the player's hull cannot be hit. I am pretty sure you must keep your hitboxes inside of the hull. So you cannot make your hull too small or else the traceline will not detect the hitbox. - Original Message - From: Niclas [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, January 10, 2007 2:44 AM Subject: [hlcoders] Player HULL vs HIT BOXES -- [ Picked text/plain from multipart/alternative ] I changed the player hull and view to very low and now it seems like I cant hit the model over that hull (projectiles go right through) even though that the hitboxes cover the whole model (custom model). - Nic2 -- ___ 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] Player HULL vs HIT BOXES
Hitboxes are only tested when the ray/box trace intersects the surrounding bounds of the entity. For players the surrounding bounds are simply the collision hull in world space. In your case that won't work so you'll need to modify the surrounding bounds. I just wrote a page on the wiki that should answer your question: http://developer.valvesoftware.com/wiki/CollisionProperty Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Minh Sent: Wednesday, January 10, 2007 11:01 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Player HULL vs HIT BOXES I believe any hitbox that lies outside of the player's hull cannot be hit. I am pretty sure you must keep your hitboxes inside of the hull. So you cannot make your hull too small or else the traceline will not detect the hitbox. - Original Message - From: Niclas [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Wednesday, January 10, 2007 2:44 AM Subject: [hlcoders] Player HULL vs HIT BOXES -- [ Picked text/plain from multipart/alternative ] I changed the player hull and view to very low and now it seems like I cant hit the model over that hull (projectiles go right through) even though that the hitboxes cover the whole model (custom model). - Nic2 -- ___ 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
