Ad hoc collisions?

[wezu]

I keep getting this feeling that some of the collision setups I make are most of the time a waste of resources. For instance a typical gun collision ray, it scans all the time for something to hit and I only need it to check for a handful of frames (1 frame if you go to the extreme) for collisions - when the trigger is puled.

Wouldn’t a fire-and-forget collision system something very useful?

[powerpup118]

@wezu

I keep getting this feeling that some of the collision setups I make are most of the time a waste of resources. For instance a typical gun collision ray, it scans all the time for something to hit and I only need it to check for a handful of frames (1 frame if you go to the extreme) for collisions - when the trigger is puled.

Wouldn’t a fire-and-forget collision system something very useful?

Have a look at bitmasks, use mygun.setCollideMask(0) after firing the gun and collisions will stop occurring, likely until you set it back to default mygun.setCollideMask(GeomNode.getDefaultCollideMask())

So to answer your question, there is no need for any modifications at all, except to your code before and after you use your collider

[darthrigg]

I’m no expert at this… but what would the performance be like if you ‘fired’ a collision sphere from the gun?

It makes sense in my mind - a collision ray implies instant impact right? Whereas a shot really takes a little time to reach the target.

…which in turn, is fire and forget really.

Cheers,
~G

[powerpup118]

Efficiently speaking that could take more CPU for those, instead fire a ray instantly and get the position of the hit object, use a doMethodLater task with the time it takes for your bullet to reach your target, after the time is up if the objects position is the same (accounting for a little movement) then the bullet hi them.

Less accurate? Can be.
Much faster than shooting 30 spheres at once, most certainly.

That’s only my thoughts, though.

~powerpup118

[darthrigg]

@powerpup118

Efficiently speaking that could take more CPU for those, instead fire a ray instantly and get the position of the hit object, use a doMethodLater task with the time it takes for your bullet to reach your target, after the time is up if the objects position is the same (accounting for a little movement) then the bullet hi them.

Less accurate? Can be.
Much faster than shooting 30 spheres at once, most certainly.

That’s only my thoughts, though.

~powerpup118

Point taken. It makes sense to do it how you say - but if something else gets ‘in the way’ between bullet firing and landing, you won’t detect it right?

I guess I’m just thinking ‘ideal world’, whereas the reality is - shortcuts such as you describe are necessary.

The practicality of each approach, really, depends on how many rounds per minute the player can fire. If it’s low, tracking the spheres probably isn’t that intensive. If it’s high, a problem.

Cheers,
~G

[wezu]

@powerpup118

@wezu

I keep getting this feeling that some of the collision setups I make are most of the time a waste of resources. For instance a typical gun collision ray, it scans all the time for something to hit and I only need it to check for a handful of frames (1 frame if you go to the extreme) for collisions - when the trigger is puled.

Wouldn’t a fire-and-forget collision system something very useful?

Have a look at bitmasks, use mygun.setCollideMask(0) after firing the gun and collisions will stop occurring, likely until you set it back to default mygun.setCollideMask(GeomNode.getDefaultCollideMask())

So to answer your question, there is no need for any modifications at all, except to your code before and after you use your collider

Well ok, that seams like a good solution, I’ll just a wrapper function for that to set the mask, return the first hit object or point and un-set the mask again.