Note: At the risk that this topic may have already be beaten to death, I wanted to find out where the community stands with this subject.
As some of you know, to ensure a high-speed projectile triggers a collision on objects when passing through them between the frames, the recommended process is to use RaycastHits to predict the collision first. Most of the documents and tutorials I read stated this ray should be casted forward since the projectile is moving at a high velocity, the hits would register immediately.
However, the ray is casted from start to finish instantaneously – basically at the speed of light. The problem with this is most projectiles are not traveling at the speed of light. For example, a regular bullet fired from a normal rifle travels between 2000 to 3000 feet per second. This is a fraction of a fraction of the speed of light. So in terms of accuracy, how could a ray being casted forward account for a objects that will step out of the ray or objects that step into the ray at the time when the projectile supposedly reaches that location? Generally, the code can not predict the future, especially when you have human interaction manipulating the environment in any way.
In the FixedUpdate(), casting a ray forward the distance the projectile will travel in one frame seems to be the most appropriate way to do this at first glance. However, a few other things to consider with this; if you’re trying to use true and absolute physics, you will account for a drop in height after so many feet – the more familiar “bullet drop” has to be accounted for. When casting a ray forward, you’ll need to cast it where the projectile should be on the next frame. Although this could be a feasible option, the code is still trying to predict the future.
To most, this will be acceptable and you’ll create a fantastic game with it for sure. But I’d like to offer up the idea of casting the ray Backwards instead. Recording the position of where we are and where we were seems to be much easier than doing a calculation of future positions. In my mind (no matter how lost it may be) we would be recording what the bullet DID HIT, as opposed to what the bullet SHOULD HIT.
To me, casting a ray backwards the distance it traveled between frames seems to be the best way to calculate collision hits. But I would love to hear feedback on this hypothesis and some opinions on what other people think best way to calculate a small projectile traveling at fast speeds – Raycasting or otherwise.
Sorry if I sound harsh, but I just can’t see any advantage to this, man!
If you do your raycast from where your bullet is towards where it was, all the hit collision info you’ll get will be from the last object to the first. (Last one hit to the first, if we suppose the bullet went through everything it touched).
Granted, all you’d have to do is to grab the last element in the list of collision hits to know the one that was actually hit.
Right.
But, of the object you’ve hit, you’ll get the info of the other side of where you’ve actually hit, the exit hole! The hit position as well as the normal will just be the wrong ones!
Not too harsh at all, and I absolutely understand where you’re coming from. But as you said, the hit array has the information of the entry point.
The problem I’m trying to identify with is how can you guarantee an object in front of the projectile will actually be hit with the projectile? Most objects can be calculated, but anything with a human element can not.
For example, if I control the direction of movement for an object that moves at a constant speed and the projectile is racing up behind me, if I move to the left or right just before impact I should avert the collision. How does the projectile calculate this movement until it actually happens and what if it happens between frames? Casting a ray backwards would not register a hit with the object I am controlling.
I know this has its flaws too – such as how does the projectile know that it didn’t actually collide first before the object moved away but the ray cast does see it.
This all boils down to what is REALY the best (or closest) method to use that reflects reality, given the limitations of an end-user computer.
Using raycasts for bullets is an approximation. The key to a good approximation is that it is suitable for the purposes it is used for. Bullets are fast, and in normal circumstances a human will not register the time between the bullet leaving the gun and the bullet hitting the target. Hence we tend to use the effectively instantaneous raycast. It’s not perfectly accurate (as you pointed out, there is no bullet drop) and its closeness to perceptual reality decreases with range - even a human can register the time between firing and impact on a sub-sonic round at 300m, so this approximation is not appropriate and should be replaced by something that models reality better.
The point is that raycasts are the current best balance between realism and computational speed for a lot of situations. We can spend more computational resources, but the increase in realism for some cases isn’t going to be worth it - the difference likely won’t even register with the human observer below a certain range. This frees up the processor to think about things like AI, particles, etc. which makes the game more interesting. Nobody ever said “The enemies were dumb as rocks and the particle smoke looked like a slideshow but the bullet physics were unbelievable!”.
The alternative is to model projectiles frame by frame. This tends to be used for “slow” projectiles like rocket launchers, baseballs, Star Wars laser blasts etc. For these, the non-instantaneous nature of their travel is part of their features, so the instant-raycast abstraction isn’t appropriate.
The short version: You’re right, it’s not realistic. But most people can’t tell the difference if you, the developer, “cheat” with your hit detection.
Well after reading all of what you guys said i have a solution of my own. Combine ray-casting to and from the distance the bullet would travel in that frame then combine the two to figure out what it really did hit. the impact on computational power would be minimal since there is still no actual physical bullet object.