Impact Damage - after multiple hits

Why not use the available contacts on the Collision2D type? This gives you everything the physics knows: https://docs.unity3d.com/ScriptReference/ContactPoint2D.html

OnCollisionEnter2D is called when you first "enter" the collision with OnCollisionExit2D being when you "exit" the collision. OnCollisionStay2D is called continuously so will give you a time to retrieve the data continuously.

OnCollisionEnter2D/OnCollisionStay2D are the same thing. It calls Stay if there's already been an enter, it's the same data. Reset what? The relative velocity is the relative velocity, it's not stored anywhere.

No, it's a recording of the state as it happened. This is why you get impulse info etc. WOuld impulse magnitude be a better match? This is used for breaking joints etc.

Surely relative velocity is only good for the initial impact because after that it'll be stopped.

 

Did you look at the link I provided?

 

Impulse, relative velocity etc. Per-contact which is what you seem to be asking for i.e. multiple points of contact.

Know that you can also simply retrieve all the contact information whenever you like using GetContacts (See Rigidbody2D/Collider2D/Physics2D) API.

 

I'm not really telling you what to do here (you'll have to determine what you need) but yes, you can retrieve contacts whenever you like, not limited to fixed-update. Obviously contacts are only updated during the simulation step but you can read them per-frame if you like but they won't change per-frame necessarily. Contacts are what other queries like IsTouching uses.

 

You need to really understand what happens to better express your question TBH.

To be clear here, when you say "FixedUpdate" you mean scripts (monobehaviours) and their FixedUpdate callback. Unity calls all Script FixedUpdates before the internal FixedUpdate. The internal FixedUpdate is where internal systems such as physics, animation etc are called. The same is true for Update; you get the script Update callbacks then after all those, the internal Updates happens.

You can configure 2D physics to run in the internal FixedUpdate or Update or manually when you choose. By default it's during the internal FixedUpdate. This means anything you do in the script FixedUpdate is before the internal FixedUpdate happens. If you check for contacts before the simulation step then you're checking the previous simulation step data; IsTouching isn't delayed by a "frame" at all. You are reading the previous simulation step. Also, I keep using the term "simulation step" intentionally because "frames" infer rendering and unless you're running the simulation per-frame it has nothing to do with "frames".

The final part of the simulation step, no matter when it is called, is performing the physics callbacks such as the one you mentioned.

There is no "AfterFixedUpdate" but the "Update" script callbacks will always be after FixedUpdate both for script and internal so checking for contacts using things like IsTouching or any other query, will be querying the last simulation step. That said, it doesn't mean physics ran that "frame", you might do several "frames" before simulation step happens but calling it in "Update" always means it's the latest simulation data.

So in short, you don't "sync" OnCollisionEnter2D with IsTouching, they are different things but now you know when things run, you can ensure you're querying the last simulation step data by, for example, querying in "Update".

Also, you don't have to run physics in FixedUpdate if don't want. If your project allows, you can simply run physics per-frame. Physics runs at a variable frame-rate so the quality of the simulation is affected by frame-rate but there's lot of times when this doesn't matter at all. You then don't need to use FixedUpdate at all for anything physics. Even interpolation is automatically ignored for you.

 

Nothing is being collected. Update is always called after FixedUpdate (both the scripts and internal fixed-update) so you are guaranteed to be querying the latest simulation step as I said above. Also as I said above, FixedUpdate isn't called each frame, it's called at the fixed-update interval you can set.

I'm not going to comment on what visuals you have because physics isn't about visuals at all. IsTouching isn't about "visually touching", it's about whether there's an active contact saying two colliders are touching in the last simulation step. I might sound like I'm being pedantic but what I'm saying is 100% correct. Any difference in visuals could be a number of things.

 

If you want to host something like the above, you'll first need to delete the library folder as it's just too large. The library folder alone can be Gb in size.

 

No idea, it was too big to download and you've only just said you've removed the folder. I'll try to remember to look at this tomorrow.

 

No, it said it was too large to download as a zip. To be honest, you're best zipping it up anyway before hosting it. Always worth removing the library folder too.

 

So I took a look and what you're doing and it is definately extreme with huge forces involved on a few specific things. Visual circles using the PolygonCollider2D (so multiple shapes) with a x8 gravity using Continuous Collision Detection on a "terrain" that's also composed of multiple shapes where some get compressed together at high velocities.

To show this, you can replace the circle shape with a CircleCollider2D and this stops the issue. Either that or reduce the gravity force and then it also goes away. Or changing the "terrain". You can see the culprits if you turn-off continuous collision detection and go to discrete; they get thrust into the terrain.

This seems to be coming out of the the continuous collision detection solver so Box2D itself. It certainly does have its limits in such situations. Essentially the solver has an impossible task in trying to solve the situation.

I'll do a little more digging to find the specific part of Box2D which is producing these high impulses and we'll go from there.

 

I detailed the workarounds above. Mainly it's helping the solver out. Try replacing those circles with CircleCollider2D. It'll be a lot faster too.

The size of things makes no difference or at least it's not relevant to this issue.

It still shouldn't do this but I need to find out if it can be avoided or not. Rewriting the Box2D solver here isn't an option but it might be avoidable. It might also be a bug in Unity in passing this info although that would surprise me being as it's used all over the place for many, many years but I will check. I did notice that it seems to be the last contact that has this which is very suspicious indeed and would suggest it might indeed be a data-transfer issue. I am investigating.

NOTE: If your terrain really is like this test and you're using continuous collision detection then you can add a CompositeCollider2D in outline mode to produce edges. This'll massively reduce the complexity here for you i.e. increase performance.

 

Well ultimately it only seems to be happening when using continuous collision detection. I hope you know that this is very expensive to use for a lot of objects.

I don't need a large project, I'm not trying to optimize that but just find what is the reason for this large value and a smaller project with fewer objects is better.

It's impossible to debug something when there's lot of things happening. Right now I've narrowed it down to only using 3 objects in your project. Physics Object (30, 31 & 32).

 

Increasing gravity x8 because your scale is wrong is a bad thing to do. It makes the solvers job that much harder because there's a constant high force acting on everything and will result in everything else scaling up too including friction, bounce, the forces you apply etc.

Regardless, I need to focus on isolating where this is coming from for you.

 

Nothing wrong with a handful of specific objects using it, assuming there's a reason why. It's normally only used for when you might see tunnelling through colliders because of very high speeds. In Box2D itself it's known as a "bullet" because that's its typical use-case.

 

Sorry for the delay.

It certainly seems like there's a problem here but it was hard to isolate so I need to do more work on it. Would you mind submitting a bug report with the project attached? That way you can track the bug and subsequent fix. If not, no worries, I can process the bug fix without it.

If you do, can you please post the incident number you'll get here.

Thanks.

 

Thanks. I've contacted our QA and told them to accept and progress it to an internal case so I can use it for fixing the bug.

I'll keep you informed via this thread.

 

Sorry for the late reply but I wanted to mention that the fixes for this have been submitted. They are not in a public release yet but will eventually land in the future.

The technical detail was that this only applied when using continuous because only continuous can adjust the contact points from 1 to 2 contacts for each physics shape. This resulted in the recorded velocity when there was one contact not being updated when there were two with the end result being that the second contact point relative velocity being uninitialized.

This is all due to the fact that a Unity collider can be comprised of many shapes so we have to jump through hoops gathers all related contacts for each shape and collate them to a single collider. In your project, the "balls" are polygons being comprised of many shapes. If these were a CircleCollider2D for instance, you wouldn't get this as there's only ever a single contact for such a shape.

Anyway, it's now fixed and will land eventually.

 

You're most welcome and sorry for the delay on the fix. Summer holidays etc.

 

Well yes, using queries is more appropriate than waiting for contact events in some circumstances but TBH this isn't useful for this thread. Note that this is about 2D physics, not 3D physics and CheckSphere is just asking if something is overlapping the 3D sphere. Also, there's no point in doing queries per-frame if the physics doesn't run per-frame as nothing moves per-frame.

 

It happens. I do the same sometimes.