Hitscan (raycasting hits) vs Projectile simulation

Hey guys, I am working on a simple little FPS project - mainly to teach myself how an FPS is structured and I was wondering what your opinions are on simulating weapon hits.

I have done a bit of googling around this and it seems there are two approaches -

Hitscan
Basically raycasting hits which is much easier performance wise. However you lose the ability to simulate bullet drop over distance, wind effecting bullets and even (over long ranges) the player being able to move before the bullet hits. This means the player wont have to lead the target and turns it into a point and kill game.

Actual Projectile
Actually generating a bullet and giving it some force and direction. Physics will take care of everything else. As far as I can see in Unity I am going to have to turn on continuous collision detection to stop the bullet passing through objects. If I started adding machine guns and other rapid fire guns to the game I guess this is going to cause the physics engine to choke up. The benifits of this is that I could even simulating bullet bounce, pentration of walls etc and I get bullet drop added for free - due to the physics engine.

Now again I can see things that I have to consider:

1. The scale of maps - If we are playing indoor then hitscan will be the preferred choice as there will basically be no difference at short distances.
2. The type of weapons - If each bullet really counts and does a lot of damage and are slow firing weapons then I guess making projectiles will be better for realism. Laser weapons should of course be instant.
3. Skill/Realism - Hitscanning means the player will not have to lead (shoot ahead of) fast moving targets and can just point and click, meaning a more arcade experience?
4. Number of bullets/firing - If there are twenty charaters firing machines guns at each other - with 10 rounds per second I guess stuff will start to slow down quit quickly.

So, if you have written or are writing a FPS what approaches are you taking with your weapons?

P.S I know missiles, grenades etc will have to be projectiles.

 

It all depends on what kind of weapon you're simulating and what the distances are. I'm no gun expert, but I'm pretty sure that with modern assault weapons of the sort most FPSes love, the bullets move so fast that the effects of gravity, wind, and human-scale target movement are negligible, except over extreme distances.

 

I usually fire a raycast from the gun and then spawn a visual bullet that simply moves forward but doesn't do anything functionally. It bothers me a little though because with enough distance the enemy would react before the bullet even hit.

When I tried collision detection, I had a problem if the bullets moved fast enough the collision wouldn't register and would go through the target.

So here's something I thought about but never tried. What if one could place the raycast detection on the bullet itself? I'm not sure it would work unless you made your ray long enough, otherwise you'd run into the same problem regular collision detection had. I'm pretty sure it wouldn't be very efficient to have raycasting code on every bullet either. Actually this might be a terrible idea.

But then you'd have complete control of the bullet's movement anyway...

 

Did you set the collision detection on the bullet to "bullet"? If you do, then (as I understand it) this is basically what the physics engine does already — it casts a ray along the path that the object moves on each frame.

Actually, it has to do quite a bit more than that, since its collider has some extended volume. So you could probably do it more efficiently yourself. Just cast a ray the length of which is equal to how far the bullet will travel in one frame, and Bob's your uncle.

(It's a shame Unity doesn't include a "PointCollider" class... it could very be very efficiently checked against any of the standard volume colliders, and would be perfect for stuff like this.)

 

I didn't even know about that bullet option! Is that something that's been here the whole time, or was it introduced with the Physx upgrage in Unity5?

I feel rather silly for not seeing that.

I'm gonna try that out as soon as I can!

 

For an even easier implementation, cast a line that covers how far the bullet just traveled since the previous fixed update. Record the bullet's position in Start(), for example in a variable named previousPosition. In each FixedUpdate(), run a linecast from previousPosition to the current position. Then store the current position in previousPosition. You don't even need to set it to continuous mode for this.

 

You set the collision detection on the rigidbody component no? If so, I couldn't find a "bullet" option. Only Discrete, Continuous and Continuous Dynamic.

The Linecast from previousPosition seems simple enough too. I'll try that as well.

 

Yikes, I must have been thinking of a different engine. You're right, there's no such option, though this page explains how to set things up so that it ought to work.

So sorry for the confusion!

 

Sorry for reviving this older post but I'm interested in what you came up with. I was also wondering if setting the bullets collider to just be a trigger & firing the effect when it hits something would make a difference.

Thansk

 

This is a good thought, but if the bullet travels too fast it might not register a collision/trigger, even with detection mode set to Continuous. It could be in front of the target in one physics update and behind the target in the next physics update without ever actually making contact in either update. The newer PhysX in Unity 5 is supposed to be better than Unity 4 in this regard, but the issue is still present for very fast-moving objects.

 

I didn't think about that, the speed if the item & the tick of the check. Thanks

 

Moving this great discussion to Scripting.
Gigi

 

@superpig sent out a tweet the other day asking if people were still experiencing fast bodies moving through objects which lead me to believe that Unity had addressed this internally.

 

For which version?

I just code in an extra raycast behind the bullet from the last known position to the most recent known position and if it hits anything on the layermask then the bullet has passed through something and so I use the hit data and pop the impact manually. Works fine, runs awesome.

 

Erm, I haven't noticed any behavior change from 4.x to 5.x in this regard. Can we get the specifics of the changes to address the bullet-through-paper issue?

 

Sorry, I was just working on hearsay for Unity 5. My linecast code works fine for me in Unity 4 & 5, so I haven't had a need to change it and test fast-moving collisions.

 

Ahh I figured out what the deal was. Took a few minutes to experiment with it this morning.

You must use AddForce or move the rb with a physics driven method. It looks like Continuous actually makes zero difference if you use Transform to move something. Is this intentional? Certainly seems like an optimization choice but I'm not sure if it was intended for Transform changes on rb's to be captured with Continous the same way the AddForce movement is captured.

 

I'm pretty sure it's intentional that manually changing the transform bypasses PhysX. Rigidbody.MovePosition() (that physics-driven method you mentioned) teleports a physics object to a specific point while respecting its interpolation setting.

 

It does make sense, but its curious because the Rigidbody is still moving positions when you're using Translate and collisions are still being considered... It just seems to be not handling as Continuous unless a physics method like MovePosition or AddForce has been invoked, probably dirtying the state by doing so?

 

Just to throw in a small test since we are seeing new stuff in unity 5...

Bbuilt on Unity 5.1.1f1 Personal...
My bullet setup:


Rigid script looks like:

Code (csharp):

1.  
2. public class rigid : Projectile {
3.  
4.     private Rigidbody myRigid;
5.  
6.     public override void SetUp(ProjectileInfo info)
7.     {
8.         base.SetUp(info);
9.         myRigid = GetComponent<Rigidbody>();
10.         myRigid.velocity = velocity;
11.     }
12. }
13.  

and it's base setup function is:

Code (csharp):

1.  
2. // This is bullet initialization, It gets called by the weapon that fired this projectile
3.     public virtual void SetUp(ProjectileInfo info)
4.     {
5.         myInfo = info;    
6.         hitCount = 0;
7.         velocity = myInfo.speed * transform.forward + transform.TransformDirection(Random.Range(-myInfo.maxSpread, myInfo.maxSpread) * myInfo.spread, Random.Range(-myInfo.maxSpread, myInfo.maxSpread) * myInfo.spread, 1);
8.         collidersToIgnore.Add (myInfo.owner.GetComponent<Collider>());
9.         backCollidersToIgnore.Add (myInfo.owner.GetComponent<Collider>());
10.         Invoke("Recycle", myInfo.projectileLifeTime); // set a life time for this projectile
11.     }
12.  

So basically just gives the rigid bullet some velocity and direction

(edit) Forgot to mention the projectile speed is set to 1000 for the webplayer test... (end Edit)

and here is the test webplayer:

https://dl.dropboxusercontent.com/u/1475775/UnityForumsStuff/RigidTest/RigidTest.html

Results to me look like it does stop the bullets pretty well using just physics..

 

I know this is old, and maybe I shouldn't revive it a second time, but it's been 5 years of development since then. This is probably still the best option, but I wanted to know if there have been any other major updates that revolutionize the way bullets are done. Someone mentioned a "bullet" collision detection option that turned out to not be in Unity, but that's a possible example of what I mean. Any major updates?

 

first ray cast... check distance and then use formula to find time... like t = d/v;

then after time t check where is player...

i have seen this in pro developer coding