Octagonal hitbox
Hey devs, I have question for you: Is the current hitbox smaller
than old 0.6's one?
Here is 2 pics explaining what I mean. 1st one shows my guess (by the feeling of the game), where octagonal hitbox has the same width as an old wsw's hitbox. 2nd shows another guess, which is 1.1~1.2 wider than the square hitbox.


(updated 2012-08-14 09:26:07)
Here is 2 pics explaining what I mean. 1st one shows my guess (by the feeling of the game), where octagonal hitbox has the same width as an old wsw's hitbox. 2nd shows another guess, which is 1.1~1.2 wider than the square hitbox.
(updated 2012-08-14 09:26:07)
>2nd shows the QL's implementation of the octagonal hitbox,
which is 1.1~1.2 (don't remember exatly) wider than the square
hitbox.
I think you're wrong
As I remember in QL it was like 0.8 and then they changed it to something like 0.9. And hitbox in ql is cylindrical, and separated from collision box which is the same as in q3 what makes sence since they didnt want to ruin maps
(updated 2012-08-14 09:17:51)
I think you're wrong
As I remember in QL it was like 0.8 and then they changed it to something like 0.9. And hitbox in ql is cylindrical, and separated from collision box which is the same as in q3 what makes sence since they didnt want to ruin maps
(updated 2012-08-14 09:17:51)
Why are you bringing Quakelive to the discussion about our
hitboxes? They have nothing to do with our implementation.
Quakelive has cylindrical hitboxes which is totally different implementation, both technically and mathematically. Our implementation uses normal axis-aligned box brush that has additional bevel planes to make the box octagonal.
If we have changed the size of the collision box, it has nothing to do with being octagonal or not, since like I said, is just matter of adding few additional clippings to the original box. So the box itself stays as wide and tall as before adding 4 additional sides to it.
I remember crizis and Vic discussing about changing the size of the hitbox generally, but I can't recall the details if they ever changed it and if they did, then how much.
Quakelive has cylindrical hitboxes which is totally different implementation, both technically and mathematically. Our implementation uses normal axis-aligned box brush that has additional bevel planes to make the box octagonal.
If we have changed the size of the collision box, it has nothing to do with being octagonal or not, since like I said, is just matter of adding few additional clippings to the original box. So the box itself stays as wide and tall as before adding 4 additional sides to it.
I remember crizis and Vic discussing about changing the size of the hitbox generally, but I can't recall the details if they ever changed it and if they did, then how much.
extone, thanks, you are right =) i've found some post on esr about
it: 1st from the DECEMBER 8TH 2009 update, second from the MARCH 16 2011.
toukkapoukka wrote:
Why are you bringing Quakelive to the discussion about our hitboxes? They have nothing to do with our implementation.
sorry, my mistake, fixed =)
toukkapoukka wrote:
So the box itself stays as wide and tall as before adding 4 additional sides to it.
thanks!
(updated 2012-08-14 09:27:06)
I'm wondering. How much is one side of the hitbox in units? Not the
width between 2 opposite sides, but the length of 1 of the 8 sides.
That's some basic trig if you know the width.
(updated 2012-08-14 22:22:28)
(updated 2012-08-14 22:22:28)
Not really, since I should know something else too to be able to
solve it.
here
and the bbox sizes (mins/maxs)
(updated 2012-08-16 21:56:38)
cmodel_t *CM_OctagonModelForBBox( cmodel_state_t *cms, vec3_t mins, vec3_t maxs )
{
int i;
float a, b, d, t;
float sina, cosa;
vec3_t offset, size[2];
for( i = 0; i < 3; i++ ) {
offset = ( mins + maxs ) * 0.5;
size[0] = mins - offset;
size[1] = maxs - offset;
}
VectorCopy( offset, cms->oct_cmodel->cyl_offset );
VectorCopy( size[0], cms->oct_cmodel->mins );
VectorCopy( size[1], cms->oct_cmodel->maxs );
cms->oct_planes[0].dist = size[1][0];
cms->oct_planes[1].dist = -size[0][0];
cms->oct_planes[2].dist = size[1][1];
cms->oct_planes[3].dist = -size[0][1];
cms->oct_planes[4].dist = size[1][2];
cms->oct_planes[5].dist = -size[0][2];
a = size[1][0]; // halfx
b = size[1][1]; // halfy
d = sqrt( a * a + b * b ); // hypothenuse
cosa = a / d;
sina = b / d;
// swap sin and cos, which is the same thing as adding pi/2 radians to the original angle
t = sina;
sina = cosa;
cosa = t;
// elleptical radius
d = a * b / sqrt( a * a * cosa * cosa + b * b * sina * sina );
//d = a * b / sqrt( a * a + b * b ); // produces a rectangle, inscribed at middle points
// the following should match normals and signbits set in CM_InitOctagonHull
VectorSet( cms->oct_planes[6].normal, cosa, sina, 0 );
cms->oct_planes[6].dist = d;
VectorSet( cms->oct_planes[7].normal, -cosa, sina, 0 );
cms->oct_planes[7].dist = d;
VectorSet( cms->oct_planes[8].normal, -cosa, -sina, 0 );
cms->oct_planes[8].dist = d;
VectorSet( cms->oct_planes[9].normal, cosa, -sina, 0 );
cms->oct_planes[9].dist = d;
return cms->oct_cmodel;
}
and the bbox sizes (mins/maxs)
vec3_t playerbox_stand_mins = { -16, -16, -24 };
vec3_t playerbox_stand_maxs = { 16, 16, 40 };
int playerbox_stand_viewheight = 30;
vec3_t playerbox_crouch_mins = { -16, -16, -24 };
vec3_t playerbox_crouch_maxs = { 16, 16, 16 };
int playerbox_crouch_viewheight = 12;
(updated 2012-08-16 21:56:38)
No. That doesn't help. I do the trig to find out the actual
octagonal hitbox in my head every time I see the enemy. Then I
promptly discard it and shoot at walls.
(updated 2012-08-17 07:08:33)
(updated 2012-08-17 07:08:33)
jihnsius wrote:
No. That doesn't help. I do the trig to find out the actual octagonal hitbox in my head every time I see the enemy. Then I promptly discard it and shoot at walls.
yes but not everyone is at good at math as you =)

