Jump to content

physics collision callback delays


Recommended Posts

So I created a hitbox system that spawns an entity with a given shape and size that uses physics collision callbacks to determine if it has come into contact with anything. The hitbox is given a "lifespan" for number of frames it will exist before it gets removed. This has worked pretty good for the most part, but there is one flaw.

For cases where the hitbox needs to exist for a very brief period of time (1 frame) if the game goes through a lag spike during that time, it can cause the hitbox to "skip" it's physics collision check before it gets removed on the next frame.

I've been trying to think of ways around this, like if I could somehow tell if a physics entity has been active long enough to run at least 1 physics collision check, but I haven't had any luck so far. Currently, making lifespan a 2 frame minimum seems to help, but it's such a lousy solution and is still not 100% safe from lagspikes. Does anyone else have any ideas?

Link to comment
Share on other sites

Maybe redundancy through a per frame update loop, using math to calculate the hit area for collision with a specific entity within it or not. This is how projectiles work in this game, I was experimenting with physics collision based projectiles and had similar annoyances.

I think you were the guy who made that awesome don't smash together mod right? Is this system for that?

Edit:

If its only for a single frame or 2 then this might be better to do than spawning a physics collider.

Edited by IronHunter
  • Like 2
Link to comment
Share on other sites

About the only thing I can think of is to have a dummy entity that's spawned with your triggerbox entity that forces a collision callback to happen, using some mask that won't interfere with the other physics you're already using.

Then you can store the guid or entity reference in some table to denote that it should be purged.

From that you'd want some function that's called at the end of each logic tick to remove the flagged entities.

Which you may need to end up having a wall updating component and have its sole purpose be the garbage collector.

  • Thanks 1
Link to comment
Share on other sites

Oh man guys, I gotta be real, I'm not so hot with coding terminology but I'll do my best

17 hours ago, IronHunter said:

Maybe redundancy through a per frame update loop, using math to calculate the hit area for collision with a specific entity within it or not. This is how projectiles work in this game, I was experimenting with physics collision based projectiles and had similar annoyances.

I think you were the guy who made that awesome don't smash together mod right? Is this system for that?

So basically forego the physics collisions for just checking for entity proximity every frame? I guess that would be one way, but I really like being able to use physics entities because you can attach motors and stuff to them. Also with all the varieties of shapes hitboxes can take, mathing them all out would be rough. and I just finished the 3rd hitbox rewrite, i would hate to do another one.

But yep, it's for that mod. Things are coming together, now I'm trying to polish off these rough edges that have existed since the beginning.

13 hours ago, CarlZalph said:

About the only thing I can think of is to have a dummy entity that's spawned with your triggerbox entity that forces a collision callback to happen, using some mask that won't interfere with the other physics you're already using.

Then you can store the guid or entity reference in some table to denote that it should be purged.

From that you'd want some function that's called at the end of each logic tick to remove the flagged entities.

Which you may need to end up having a wall updating component and have its sole purpose be the garbage collector.

Ok I'm pretty sure I get what you're saying. Spawn a dummy hitbox on top of every hitbox for the purpose of detecting a collision so that it can then be marked as eligible for removal? I was thinking of something similar at one point but I was worried doubling the number of active physics detections on screen would reduce performance.

But I've been tinkering around with it for a while and I think I got something started. So this physics partner attaches itself to the hitbox, and as soon as it collides with it once, it marks it and removes itself. Once I'm done messing with it I'll let you know how it turns out, but I think this might do the trick

Link to comment
Share on other sites

Things are looking pretty good with this change! To test it out I ran the sim at double speed while running a youtube video, rendering a video, and screen-capturing  to get the game down to 20 fps. But the result is a 100% hit rate compared to a 30% hit rate without the change. And all without bloating hitbox lifespan under normal conditions. 

Thanks!

  • Like 1
Link to comment
Share on other sites

Hi, I'm interested in your hitbox system, it seems really interesting for modding in general.

On 6/12/2020 at 5:27 AM, pickleplayer said:

So I created a hitbox system that spawns an entity with a given shape and size that uses physics collision callbacks to determine if it has come into contact with anything.

Did you use Physics:SetTriangleMesh to create custom hitboxes? If so, can you make two TriangleMesh collide?

I've played a bit with the hitboxes but I haven't been able to achieve satisfactory results.

 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
  • Create New...