Inside3D!
     

Couple of questions (auto aim, collision detection)

 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> Engine Programming
View previous topic :: View next topic  
Author Message
MDave



Joined: 17 Dec 2007
Posts: 75

PostPosted: Thu Feb 28, 2008 10:42 pm    Post subject: Couple of questions (auto aim, collision detection) Reply with quote

Posting another few questions here since it seems to be the best place to ask questions about anything code related to quake Smile I'm a bit of a noob when it comes to programming (slowly teaching myself) and I've been trying to understand how the PF_aim function works in pr_cmds.c

What I want to change, if this is the right function, is to enable auto aim for the horizontel axis which already works for the vertical axis. Now I noticed a function below that one called PF_changeyaw, and one below that ifdef'd out, PF_changepitch. At first glance that seems related to it? But I'd just like to make sure it isn't so I don't trial and error for a week just to find out it isn't related Razz

Note, I don't mind breaking compatability with quake since I'm doing this for my own total conversion using quake as its base, but keeping compatability would be nice Smile Reason I want full auto aim functionality is because the platform I'm working on is the PSP Smile

Now for the collision detection question.

Would it be possible to modifiy the quake engine to use per poly collision detection for players and enemies, for weapon attacks (and not the world, don't think thats possible or wise Razz) ?

One last one I'll sneak in here.

Any idea how I'll be able to make the view model face the direction of the auto aimed target, so it looks more realistic instead of the bullets and nails etc. veering off at an odd angle compared to the guns actual direction? Razz

This place rocks. Thanks for reading this far.
Back to top
View user's profile Send private message
FrikaC
Site Admin


Joined: 08 Oct 2004
Posts: 947

PostPosted: Mon Mar 03, 2008 4:40 pm    Post subject: Reply with quote

Quote:
What I want to change, if this is the right function, is to enable auto aim for the horizontel axis which already works for the vertical axis. Now I noticed a function below that one called PF_changeyaw, and one below that ifdef'd out, PF_changepitch. At first glance that seems related to it? But I'd just like to make sure it isn't so I don't trial and error for a week just to find out it isn't related


Those are unrelated and deal with the AI. Changeyaw is an engine side implementation of the changeyaw in ai.qc (iirc) for performance reasons.

As for the rest of your questions, I'm sure someone with the source in front of them could help.
Back to top
View user's profile Send private message Send e-mail
RenegadeC



Joined: 15 Oct 2004
Posts: 370
Location: The freezing hell; Canada

PostPosted: Mon Mar 03, 2008 6:16 pm    Post subject: Reply with quote

Horizontal aiming can be implemented by using the FrikBots AIM(); function and slightly modifying it, I did it in Codename Corporal's Dreamcast release. I'll find the code today if I have time.
Back to top
View user's profile Send private message AIM Address MSN Messenger
MDave



Joined: 17 Dec 2007
Posts: 75

PostPosted: Thu Mar 06, 2008 12:56 am    Post subject: Reply with quote

Thanks for the replies! Smile

Glad to know the changeyaw and pitch functions are not related to the aim function Smile

RenegadeC, would that mean I would have to modifiy and add it to the engine code, or the progs code? I think it'd be harder to somehow make the view gun angle change direction to adjust where its actually aiming at with auto aim turned on. Surely theres *something* in the below code I only have to add or tweak to enable horizontal auto aim? Heres the unchanged pr_aim function:

Code:


/*
=============
PF_aim

Pick a vector for the player to shoot along
vector aim(entity, missilespeed)
=============
*/
cvar_t   sv_aim = {"sv_aim", "0.93"};
void PF_aim (void)
{
   edict_t   *ent, *check, *bestent;
   vec3_t   start, dir, end, bestdir;
   int      i, j;
   trace_t   tr;
   float   dist, bestdist;
   float   speed;
   
   ent = G_EDICT(OFS_PARM0);
   speed = G_FLOAT(OFS_PARM1);

   VectorCopy (ent->v.origin, start);
   start[2] += 20;

// try sending a trace straight
   VectorCopy (pr_global_struct->v_forward, dir);
   VectorMA (start, 2048, dir, end);
   tr = SV_Move (start, vec3_origin, vec3_origin, end, false, ent);
   if (tr.ent && tr.ent->v.takedamage == DAMAGE_AIM
   && (!teamplay.value || ent->v.team <=0 || ent->v.team != tr.ent->v.team) )
   {
      VectorCopy (pr_global_struct->v_forward, G_VECTOR(OFS_RETURN));
      return;
   }


// try all possible entities
   VectorCopy (dir, bestdir);
   bestdist = sv_aim.value;
   bestent = NULL;
   
   check = NEXT_EDICT(sv.edicts);
   for (i=1 ; i<sv.num_edicts ; i++, check = NEXT_EDICT(check) )
   {
      if (check->v.takedamage != DAMAGE_AIM)
         continue;
      if (check == ent)
         continue;
      if (teamplay.value && ent->v.team > 0 && ent->v.team == check->v.team)
         continue;   // don't aim at teammate
      for (j=0 ; j<3 ; j++)
         end[j] = check->v.origin[j]
         + 0.5*(check->v.mins[j] + check->v.maxs[j]);
      VectorSubtract (end, start, dir);
      VectorNormalize (dir);
      dist = DotProduct (dir, pr_global_struct->v_forward);
      if (dist < bestdist)
         continue;   // to far to turn
      tr = SV_Move (start, vec3_origin, vec3_origin, end, false, ent);
      if (tr.ent == check)
      {   // can shoot at this one
         bestdist = dist;
         bestent = check;
      }
   }
   
   if (bestent)
   {
      VectorSubtract (bestent->v.origin, ent->v.origin, dir);
      dist = DotProduct (dir, pr_global_struct->v_forward);
      VectorScale (pr_global_struct->v_forward, dist, end);
      end[2] = dir[2];
      VectorNormalize (end);
      VectorCopy (end, G_VECTOR(OFS_RETURN));   
   }
   else
   {
      VectorCopy (bestdir, G_VECTOR(OFS_RETURN));
   }
}


It be handy to get the crosshair to move to where the weapon is autoaiming at too, hopefully that won't be too dissimilar to the weapon angle view modification.

Oh, thought I'd show what it is I'm working on exactly, screenshots taken directly off the PSP Smile

http://bladebattles.com/kurok/kurok_screenshots/

Maps, models (minus the Raptors dino model, borrowing that until I make my own Razz), sprites and HUD mine, except for the health and ammo boxes I've yet to replace. Fully functional bow and arrow, god coding that so it behaves accurately was a pain.
Back to top
View user's profile Send private message
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Thu Mar 06, 2008 2:42 pm    Post subject: Reply with quote

regarding aim. dotproduct between two vectors as in PF_Aim gives the 'angle' between two normalised vectors (in 1 to -1 range).

Code:

   if (bestent)
   {
      VectorSubtract (bestent->v.origin, ent->v.origin, dir);
      dist = DotProduct (dir, pr_global_struct->v_forward);
      VectorScale (pr_global_struct->v_forward, dist, end);
      end[2] = dir[2];
      VectorNormalize (end);
      VectorCopy (end, G_VECTOR(OFS_RETURN));   
   }

See how it changes end[2] but not end[0] or end[1]? that's what makes it aim in only the vertical direction. (thus you can get rid of the dotproduct and vectorscale there).
_________________
What's a signature?
Back to top
View user's profile Send private message Visit poster's website
MDave



Joined: 17 Dec 2007
Posts: 75

PostPosted: Thu Mar 06, 2008 9:17 pm    Post subject: Reply with quote

Ahh cheers for that explanation! I think I'm just about understanding how vector functions work. Works a charm Smile Need to have sv_aim at 0.99 though or else its too easy, even for a handheld with an analog stick as a means to aim. Now all thats left is a way to link that up with the function to CalcGunAngle in view.c and the crosshair (or maybe not the crosshair, I'll show the crosshair only if the fov is greater then 90 for zooming in, and also disable auto aim for the client somehow, until he/she zooms back out).

Is this a pretty fast per-poly collision solution by any chance? And does it work ok with model animation transform and frame interpolation?

http://www.telefragged.com/thefatal/q_tutorials/quake_perpoly_collision.txt

If thats not a wise idea for a handheld that sports a 333mhz processor (but a pretty powerful for a handheld 3d accelerated graphics chip), whats the best way to size down the width and depth of the player bounding box's? Currently, they seem pretty big except in height with, compared to quake's soldier and player model's, my more proportionate human models?

Sorry for all the questions Razz
Back to top
View user's profile Send private message
RenegadeC



Joined: 15 Oct 2004
Posts: 370
Location: The freezing hell; Canada

PostPosted: Fri Mar 07, 2008 1:29 am    Post subject: Reply with quote

Guess you don't need me anymore, my method was done using QuakeC which would probably not be the best way to do it if you wanted the viewmodel weapon to move also.
Back to top
View user's profile Send private message AIM Address MSN Messenger
MDave



Joined: 17 Dec 2007
Posts: 75

PostPosted: Fri Mar 07, 2008 3:56 pm    Post subject: Reply with quote

Actually, your help could very well be needed Razz hehe.

Since auto aim in the engine is server side (from the looks of it) that could be a problem for turning it on/off for each client that uses zoom. As for the viewmodel weapon to move also, I could probably get away with using stuffcmds to client side cvars that change the weapon angle, maybe. Guess its not a clean way of doing it, but it works.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Inside3d Forums Forum Index -> Engine Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2004 phpBB Group