/agdg/ - Amateur Game Development General★

with a few nice tricks you can make physical bullets very efficient, if you're good enough they might not even need to be attached to their own GameObject although this would also depend on the use case

here's how i do it: a raycast along the camera's Z axis to determine the point the bullets go (assuming you don't want the bullets to come out of your head, which in itself is actually fine) then the bullets are GameObjects that raycast along their forward axis to where they will be next be in the next fixed time step. compared to rigidbodies which is a common trap people fall into this is blazing fucking fast and the performance hit is worth the extra gameplay depth

if you want this shit to be network aware you'd better just kill yourself now like i plan to

>>24778

(not OP)

This works for a projectile moving straight forward and I need one like that in my game (think of the HL2 crossbow, basically) so thanks.

But I want another type of projectile that actually flies in an arc. If I only use one of them (very, very low firerate) per player at a given time, how many players do you reckon I could allow before running into problems? Basically, how many fast moving rigidbodies can Unity simulate on weak-average CPUs? I was planning on using a capsule collider but I guess a box would also work.

P.S. I run the physics update at 100 hz instead of the default 50.

>>25016

do not try not to use rigidbodies for things that don't need to be rigidbodies.

using fast moving rigidbodies for bullet hit detection is bad as fast moving rigidbodies can sometimes pass through colliders for no apparent reason. additionally, you are waisting processing power on a rigidbody for something that can be easily predicted in code. in games, ballistics are very predictable and you can calculate things like gravity, air resistance and richocets without using a rigidbody at all. a lot of projectile simulation only utilises the four basic kinematic equations.

id also suggest running your physics at 50hz.

>>25046

The weapon I'm thinking of would be a grenade launcher, with grenades moving significantly slower than a bullet. Not quite as slow as a Quake grenade but a lot slower than BF/COD grenade launchers.

You haven't given me a solid reason not to use physics, other than the collision issue which the 100 hz update should take care of at the velocities I want. I know more frames are always better but before I code authentic ballistic physics manually I might as well use Unity's pre-existing stuff and sacrifice a bit of performance. What audience is that going to cost me, South America?

>>25052

I don't think Grenade Launcher should be a problem, you should never have more than 2 instances of a rigid body per weapon in that case given you'll want to explode and clean up most of the grenades before they can fire a third one. The other anons are probably concerned about the idea that you might be spraying something like 30 out at a time per weapon with bullets.

>>25069

No, actually there would be only one grenade at a time. You can't shoot a second one before the first one explodes. For gameplay reasons, not technical limitation.

>>24750 (OP)

>Hitscan or fast projectiles?

There is almost no difference for you as a developer. You don't use physics actors as bullets, what you do is use traces, both for hitscan and fast projectiles. For a hitscan it's simple, you trace from the start to the end and see what it hits, for fast projectiles you trace the distance it travelled that frame.

For example if a bullet travels at 500m/s, you trace from startPos (the position the bullet started this frame) to dirVector*speed/deltaTime + startPos then store this value as the new startPos every frame (first startPos being the muzzle of the gun). Basically what >>24778 said.

You do not want to use a physics actor for the bullets because they offer absolutely no advantages. First and foremost because they won't handle that kind of speed and physics/collisions will completely fall apart, but also because of the performance hit of spawning 600 physics actors per minute and simulating them. On top of that you gain nothing because no physics engine in existence is currently capable of properly calculating terminal ballistics in real time, so it won't help you there, you'll have to make your own function for when the bullet hits.

>>25016

>arc

Just store the downward speed at that frame in a variable, make it increase by whatever your gravity is, then add it to the end position of the bullet for that frame. So if you normally would end up at x,y,z, make it x,y,z-speed/deltaTime.

>>25052

>but before I code authentic ballistic physics manually I might as well use Unity's pre-existing stuff and sacrifice a bit of performance.

You seem to be under the impression that rigid body physics will calculate any kind of ballistic physics for you, but it won't, at all. Only thing it can do is calculate the drop and the bounce, and even then it's only at extremely low speeds for a projectile.

However since you are talking about a very slow grenade, rigidbody physics will be fine. Just don't ever use it for actual bullets or anything faster than a few dozen metres per second.

>>25087

>You seem to be under the impression that rigid body physics will calculate any kind of ballistic physics for you

lolno, I just think it would be tough to wrap my head around realistic collisions including rotation/spin. I'd also like for these grenades to bounce differently on different surfaces (low bounciness + high friction on sand, and the reverse on a hard, smooth surface). Unity's physics materials seem to do a good job at this and they require a rigidbody...

So yeah, I'm dead set on using rigidbody+physic material on grenades. The "pin" weapon will be all raycast though, I don't even want it to drop, just ricochet if it enters collision at a low enough angle (will start with 45° as a cutoff and see if that feels right).

>>25099

As I said, it works perfectly fine for slow grenades and other objects. Can work fine for rockets too if its the videogame kind of rocket (the kind that flies at 1/100th of its speed in real life).

I'm still traumatized from that time I saw a guy try to use rigid body physics for a machinegun. A bit more than 10 rigid bodies coming out at 700m/s every second, all with precise collisions (thankfully not per poly, but the bullets were like 200 tris each), then he wondered why it wasn't working properly (both in performance terms and in terminal ballistics terms).

>>24750 (OP)

The only real answer is slow projectiles.