I’ve seen some people asking around the forum on how to do “real” bullets.
Not the projectile from the 1st person example, and not the instant hit linetrace from the multiplayer shooter example, but “real” bullets with travel time and bullet drop.
So, I’ve gone ahead and made that.
So far, it is just the bullet travel, the drop and some drag applied to the bullet in flight.
The drop is fairly accurate compared to real life, but the drag is a rough calculation for now, a flat 20% drag pr. second.
This is awesome! I can send you my SCAR if you need a weapon to test? Since I’m not an animator it doesn’t come with animation. Maybe you can find an animator to keep with that
Here’s my old SCAR(I need to redo it before I can send it to you):
I’m curious as to why you are not using the standard projectile movement component?
With a small collision component and a high velocity, it would act the same (minus the air resistance).
I don’t trust Unreal Engine at high speeds. Bullets move very very fast and could potentially move past an object in one tick. A bullet easily moves 1000 units in one tick at 60 FPS. Even further at lower FPS.
I suspect that using PhysX on hundreds of bullets is more taxing on the system than some relatively simple math and line traces.
It’s easier for me to apply drag, wind, altitude and other effects to the bullet if I control everything.
The 2 first reasons are just my own fears, not founded in any testing or insight.
I looked at the documentation, and I found you can enable CCD which is Continuous Collision Detection. This is pretty taxing from what I can read. So my choice not to use seems to be correct. More info is welcome.
Ahh, that is what I was confused me.
You see, the projectile movement component does not PhysX - it uses traces - although they against a component, not a line.
It also devides long ticks into smaller chunks to help create a better curve.
I have taken a look at ProjectileMovementComponent and I have chosen not to use it. My “spider sense” is tingling, I think there could be potential performance issues using it with many bullets. I would also lose some control if I chose to switch. I would hand over calculations to the physics engine, and… well, I don’t like that with bullets.
All traces use the physics engine - even tracelines.
As for simulating physics, that isn’t happening.
Look into UProjectileMovementComponent::TickComponent() again:
if ([UpdatedComponent](https://docs.unrealengine.com/latest/INT/API/Runtime/Engine/GameFramework/UMovementComponent/UpdatedComponent/index.html)->[IsSimulatingPhysics](https://docs.unrealengine.com/latest/INT/API/Runtime/Engine/Components/UPrimitiveComponent/IsSimulatingPhysics/index.html)())
{
return;
}
If you’re talking about MoveUpdatedComponent(), it just calls UpdatedComponent->MoveComponent().
As for MoveComponent(), it uses ComponentSweepMulti().
In the end, aside from a line vs a component trace, your system is essentially the same as this, but in a Blueprint.
Performance wise, C++ trumps Blueprints and there is nothing stopping you adding air resistance in a Blueprint that uses a ProjectileMovementComponent.
What is the performance like with this? Can you do some comparisons between say, 50 instant hits in one tick, 50 projectiles fired at once, and 50 of these at once. Maybe not 50, whatever number makes a difference noticeable. I would love to use an algorithm like this, if its not going to kill frames. Looks great so far, keep up the good work!
I just made a quick test with a minigun type weapon. 6000 shots pr minute. Played in the editor. Unfinished project. Not optimized yet.
Around 1000 bullets in the air before performance began to suffer.
With this test I found a very neat little optimization that I could do, it will make it perform even better after this.
Edit:
After a small change to the bullet blueprint I can now fire endlessly without having performance issues.
When a bullet goes below 100 meters per second I kill the bullet. At this point the bullets are in an almost vertical drop anyway
It helps us both. It brings to light information we may not have known and makes us question what we’ve already in the hopes of improving them.
Not a bad thing.
Have the same sort of setup, as well as a limited lifespan.
At the moment, said lifespan always 10 seconds, but I think making it dependant on calibre is better. In this way, low velocity rounds will remove themselves once they are beyond their effective distance, while high velocity rounds will be given ample opportunity to reach their target.
The performance of the standard ProjectileMovementComponent may improve if you replace the MoveComponent() call with single or multi line trace. Not as accurate as giving bullets an actual diameter, but they’re relatively small anyway, so…
So far, our bullets still use MoveComponent(), but we don’t intend to have thousands of rounds flying around in the game
Pretty sure you could make it a project like the ShooterGame (which is C++ & Blueprint) or as a C++ plugin.
In the current implementation, drag is applied in C++ function ComputeAcceleration(). This is the same place it applies gravity, so it seemed like the best place for it. A slight velocity change each tick would work and be less expensive, though it would be affected by server frame rates etc. This is why deviding the traces up by a fixed interval over long ticks is a good idea.
It all depends on what is a ‘good enough’ simulation.
This may be something you take into account in your design, by adding options for a fixed or variable rate, depending on whether the user wants accuracy, performance and so on.
Right now they state:
“Additional content types such as code plugins will be accepted at a later date, and this document will be updated with additional guidelines to reflect those additions.”
So right now it is only pure Blueprint they accept, so I can’t play with C++.
