Best way to create game weapon projectiles

[Toadcop]

Projectile system - a system to handle movement and collision of game object which may collide/interact with other game object and produce actions.

For now and from what i know is see several options.
1) rigid body (sphere ?) and rely on bullet to detect anything and do actions on collision (callback or iterate over all contacts).
advantage: "realistic physics" and alot other stuff out of the box.
drawback: from my observation, it's too general purporse/overcomplicated, and in end effect it may penetrate too much (or even tunnel) kind a overdo for projectiles.
2) use own objects and cast rays/sweep spheres to detect possible collsions and kind a build completely own logic on it.
advantages: alot of control, and safe useless operations/features (increase performance), you can avoid penetration and tunneling at all. (because of simplifications)
drawback: need to code anything self, i have doubts about ray cast performance (and the algorithm performance at all)
3) use GhostObject to detect collisions (but without response), and the task will be to resolve collisions by your self, and build stuff around this.
advantages: mostly like with ray cast way, but in this case bullet can do more work for you.
drawback: also require to build own physic logic around it.

so mostly as i see to get a proper "game projectile system" (for weapons like plasmagun, rocket launcher, grenades etc.) you need to use only some basic parts from bullet, and build it on the top of it. (mostly to achive high/required stability, what is most important for a proper game.)

i am really interested in suggestion, comments, or even "full solutions" how to implement such system using bullet. would be great if someone allready did such stuff and could share expirience.

[chaosavy]

I use ridgid bodies for bullets and it works fine for me.

You could do something like this:

Code: Select all

	if(bNoResponse) //Set collision flags for non responders
		newBody.rigidBody->setCollisionFlags(newBody.rigidBody->getCollisionFlags() | btCollisionObject::CF_NO_CONTACT_RESPONSE);

Then the objects would only give you collision detection.

or your #1 approach, its not overcomplicated at all. Works fine.

[reptor]

I am wondering how well such rigid objects work as bullets.

Are you modelling them to be the same size with real bullets? Consider a 7.62 millimetre bullet which is a real size magnitude for a bullet of an assault rifle I have used in a military. How can you expect such a small object to collide correctly with much bigger objects in a physics library such as Bullet? Do you 'inflate' the size of the bullet to make the chance of detecting collisions greater?

Consider that in a military simulation you can have a main battle tank have these 7.62 mm bullets hit it. I think the size difference between the two objects is huge for a physics simulation and I have understood this is not a situation when physics simulations work well.

I have not tried to implement this but I am going to have to for my game so I am very interested in this topic.

[lulzfish]

For bullets, I would use raycasting as that's what most FPSes since the dawn of time have done.
Rigid bodies would be for larger, slow-moving objects that need to arc and bounce a lot, like grenades or rockets.

[Coderro]

Personally, I use #1 for projectiles like grenades but #2 for for exotics like plasma, flamethrowers, etc. As has been mentioned, gunfire should be done with raycasts. Haven't tried it yet, but #3 should be very similar to #2.

[Toadcop]

I use ridgid bodies for bullets and it works fine for me.

you use broad or narrow phase collision ?

I am wondering how well such rigid objects work as bullets.

with integrated response they work "not good" for games... but to detect collision it should be fine.

Are you modelling them to be the same size with real bullets?

no ofc =) but with ccd i think it's not a huge problem at all. (to detect collision)

For bullets, I would use raycasting as that's what most FPSes since the dawn of time have done.

for instant projectiles yes. For example doom3 rifles fire isn't instant (you can see bullets flying) but well doom3 features "superior" physic (for game purporses)

Rigid bodies would be for larger, slow-moving objects that need to arc and bounce a lot, like grenades or rockets.

well the main problem with a bit faster objects is tunneling (potential) thats to say why i started this thread =)

but #2 for for exotics like plasma, flamethrowers, etc.

why so ?

tnx everyone for response, i need to get more info first i make a decision =)

[zmorris]

UPDATE: I found a workaround using convexSweepTest() that I posted at the bottom of the thread, and suggested a way that the maintainers might improve Bullet to add pairs to the manifold properly with CCD in a future version of Bullet.

----------

For anyone reading this, I wanted to warn you ahead of time that triggering/callbacks don't work properly with CCD, I've posted my exploration of the issue here:

http://bulletphysics.org/Bullet/phpBB3/ ... f=9&t=6920

The core of the issue is that CCD is disabled if you set:

body->setCollisionFlags( body->getCollisionFlags() | btCollisionObject::CF_NO_CONTACT_RESPONSE );

Callbacks are easy to do without CCD, or if you raise your tick count to 120 or 240 fps. I may workaround the issue by making the shots long cylinders or capsules so that their length is equal to the distance traveled in one tick, and forget about CCD. I lost many days to this bug and must admit that I am underwhelmed by Bullet at this time, because it's more of a hodgepodge of various schools of thought than one cohesive physics engine, and it focusses on speed at the cost of accuracy. Perhaps CCD will become more of a core aspect of Bullet down the road, but without it, Bullet isn't really useful for accurate simulations, at least as of version 2.78.

--Zack

[dphil]

For bullets, I would use raycasting as that's what most FPSes since the dawn of time have done.

for instant projectiles yes. For example doom3 rifles fire isn't instant (you can see bullets flying) but well doom3 features "superior" physic (for game purporses)

Just a comment... just because you can see projectiles in flight doesn't mean they aren't using some "instant" hit detection with something like raycasting. Granted it would imply that, but the visual bullets can just be graphical candy for some simpler raycasting or other collision algorithm. If they move fast enough, or they put a slight delay on a bullet hit response (monster reeling back, etc) you wouldn't really notice the disconnect between graphics display and physics algorithms.

[Banana]

You could do something like this:

Code: Select all

	if(bNoResponse) //Set collision flags for non responders
		newBody.rigidBody->setCollisionFlags(newBody.rigidBody->getCollisionFlags() | btCollisionObject::CF_NO_CONTACT_RESPONSE);

Then the objects would only give you collision detection.

I have seen this solution getting proposed more on this forum (like here: http://bulletphysics.org/Bullet/phpBB3/ ... f=9&t=3724) So I suppose it should work.

However, me and more people (like here: http://bulletphysics.org/Bullet/phpBB3/ ... f=9&t=6930) experience problems with this, so could somebody please go into this in a little more depth as just setting the btCollisionObject::CF_NO_CONTACT_RESPONSE is clearly not the only thing which determines if a collision response happens or not.

[ologon]

I think they are called "PhantomShapes" in havok. They listen for collisions but are not affected by them.

It would be really interesting to know how these can be reproduced in bullet indeed

[dphil]

I think they are called "PhantomShapes" in havok. They listen for collisions but are not affected by them.

It would be really interesting to know how these can be reproduced in bullet indeed

btGhostObject? . This was toadcop's 3rd option in the top post.

[Banana]

You could do something like this:

Code: Select all

	if(bNoResponse) //Set collision flags for non responders
		newBody.rigidBody->setCollisionFlags(newBody.rigidBody->getCollisionFlags() | btCollisionObject::CF_NO_CONTACT_RESPONSE);

Then the objects would only give you collision detection.

I have seen this solution getting proposed more on this forum (like here: http://bulletphysics.org/Bullet/phpBB3/ ... f=9&t=3724) So I suppose it should work.

However, me and more people (like here: http://bulletphysics.org/Bullet/phpBB3/ ... f=9&t=6930) experience problems with this, so could somebody please go into this in a little more depth as just setting the btCollisionObject::CF_NO_CONTACT_RESPONSE is clearly not the only thing which determines if a collision response happens or not.

I found out the problem wasn't in ghost object afterall, it was in its action; the btKinematicCharacterController.


to fix this: http://bulletphysics.org/Bullet/phpBB3/ ... e964140769

[Toadcop]

I am wondering how well such rigid objects work as bullets.

i use CollisionWorld (not Dynamic) and kind a GhostObjects (custom one) basicly "if you do anything by yourself" you can achive good results.
for now i am stucked with not determenistic simulations introduced by convexSweepTest, it seems what it does use garbage memory somewhere or similar. haven't figured out whats wrong for now. (i hope it's nothing fundamental O_o), probably need to study dynamic world implementation of CCD.

i dropped dynamic world due lack of knowledge/weird complications. in collision world you can self decide what to do.