Physics.Contacts GC activity

Here's how it's presented as a simple check-box that'll be on by default. The reason this was reluctantly added as an option rather than as a hidden behaviour is because there are some devs who store away the Collision/Collision2D types so recycling them would cause issues for them but they are not the majority.

2D/3D Physics Settings

Picture or it didn't happen I guess: https://gyazo.com/0f6d884b296976529ed3cb24f34552e6

 

It actually uses (recycles) a single instance of Collision/Collision2D and just populates it for each callback, not keep a strong reference to all Collision/Collision2D sent out because those would grow without limit. This method does mean there are no bad performance/memory implications either which is the best part.

 

We don't have that issue for 2D but for 3D yes it's still a problem that needs to be addressed by the 3D team as we cannot simply cache it here because as you say, it's not a fixed length. Will update you when I know.

We could certainly cache a List<> which is one option in my mind.

 

Well it's as above, a single option that'll be on by default that causes us to reuse a single Collision/Collision2D instance for all collision callbacks. We acquire a strong lock on the instance to keep the GCs grubby-paws off it and release that when we shutdown and also when we do a domain reload too which happens when we exit play-mode but this is an editor-only concern.

It results in no GC spew but as has been pointed out, there's the "contacts" property which is an array and again, we're back to leaving that to the GC. 2D solved this using some brute force techniques but they were never going to be a long-term solution. What we've decided to do here is to produce and acquire a strong-lock on an internal "List<ContactPoint>" and like the "Collision" instance, reuse it for each callback. We can manage its memory allocation but will likely start at a reasonable size anyway. It'll also mean that you'll need to grab your contacts during the callback (no references) but this is the same as the "Collision" instance anyway as it's the same instance reused. This behaviour will also only apply when the above option is on anyway.

We'll likely change the "contacts" property to just do a "List<ContactPoint>().ToArray()" for backwards compatiblity however we can add various non-allocating "GetContacts()" methods.

NOTE: We may not use a "List<ContactPoint>" at all but rather a NativeArray but it'll be hidden anyway and of no concern. What matters is no allocations of course.

 

Before: https://gyazo.com/096a88ac1f66d0bce5b050c08f37c3ba
After: https://gyazo.com/246394b17c7846022585f4afae1e1101

If I can get a wiggle on, this should land 2019.1.

 

> Absolutely, this isn't some far-off research or anything crazy like that. As far as I'm concerned, they'll be in the Unity 5 release.
That work was going to be based on the new fast callback system (that part wasn't being developed by us) that never landed so our hands were tied. This work, based upon the new bindings system internal to Unity, untied them.

Unlike then, this work is actually done and running locally here. Hell, I've even got the docs done. Just got to write a bunch of tests and let QA have at it then onward to the release stream.

In no small part is this work related to our conversation earlier sir. Bumped its priority!

 

Unfortunately that isn't an overload of the callback, it's just Unity playing nice and throwing away the "Collision" or "Collision2D" instance.

The only realistic way to stop contacts being produced would be to have a global option that controls not populating contacts which isn't nice. Adding extra overloads of OnCollisionEnter,Stay & Exit isn't really a good option and would confuse a lot of devs. The next step is creating a completely new callback that doesn't suffer from these problems but we've solve that now so is kind of pointless.

A better way would be a callback that simply indicates a contact for either collision or trigger and you retrieve what you like. This is another body of work however.

In the end, the actual overhead of copying contacts though is very low, especially now because we do not create a new contacts array each callback and no special marshalling needs to take place.

Good news is that I've finished the work and I have a pull-request in process for review. It's has passed physics review and is waiting on QA test/review as well as doc review then it's onward to 2019.1

 

The internal pull-request has just been approved after a full QA test so it is now beyond the event horizon and is falling inwards towards the 2019.1 singularity. Expecting it to land early next week.

I have no idea if the release managers would approve this as a backport although it's more than possible to do that. I'll investigate this for 2018.3. I doubt it'd be allowed in the beta this late in the game but maybe in a patch release later.

 

This just landed in 2019.1 this morning. I've got a meeting with the release managers on Monday to do a risk analysis of landing this in late 2018.3 beta. I'll let you know what is decided.

 

We have provisional approvement to backport this to 2018.3 beta. The PR is done and it's going through review and will have some extra QA shortly. Note that for this to land in 2018.3 beta we had to make a sensible consession which was to have the option off by default. We also don't have time to update all the templates (those would turn the option on in new projects) although this will be done for 2019.1. To turn this option on however will be a simple check-box.

 

The backport for this no-gc work has just landed in 2018.3.0b11

 

It hasn't been released yet.

 

Looking at the schedule, 2018.3.0b10 has been published but not made public yet but I believe that should be in the next few days. 2018.3.0b11 is scheduled for publish on 16th Nov so a few days after that I guess.

We're also almost on top of the release candidate so the next release after b11 might be b12 or an RC, not sure.

 

You can try this feature right now but it's in 2019.1.0a8 which you can also download here but obviously it's an alpha so not necessarily in a great state, certainly not for production.

 

No way I could know what is going on, sorry. You'll need to discuss any alpha issues in the 2019.1 alpha forum.

 

Unfortunately I don't know exact dates when the releases will land as all I can see are the publish dates on an internal schedule page i.e. the date the build is built. It then has to pass QA verification etc. I certainly would expect it in November.

 

Because it has a behavioural change that some users would not want i.e. reusing the Collision/Collision2D instance for each callback. This would break existing projects that keep the instance beyond the callback and we do not want to break existing behaviour by just using a new version. New projects will have it on by default and it's a simple matter to turn it on yourself for existing ones.

 

I spotted this whilst getting my build gc alloc free and reported it to the appropriate team. A bug case was reported already so hopefully they'll sort it out. Apparently it's due to some function returning bool which causes boxing in some wrapper ... blah blah blah. Anyway, bug reported, hopefully sorted soon.

Such a dark view of the future! Fear not!

 

I pinged the person who's got this on their TODO again but I'm not the only one doing the same. Hopefully it'll land soon.

 

https://issuetracker.unity3d.com/is...reflection-allocates-17-bytes-of-gc-per-frame

 

In 2D physics, the suffix "All" and "NonAlloc" are tentatively deprecated. All queries are done using the main name only and each has several overloads accepting results in different forms such as a reusable array or List<T>. These replace
those older queries. All queries have this and the List<T> will only allocate when the list needs to be increased in size so reusing it for multiple queries means no GC waste.

In your case, you use Physics2D.OverlapCircle.

I'm not sure I follow the comparison of a spatial query to a class that contains reported contacts though.

The collision reporting now doesn't produce GC waste for the Collision(2D) types and doesn't produce waste for the contacts property unless you access it but even that has an alternative of Collision2D.GetContact(s) which as I said above can also accept an array or List<T>.

Maybe that answers your question.

 

FixedUpdate is being called 38 times because it's trying to catch-up to game time. That's not physics, that's something taking too long to run. You need to find what that is.

Do you get GC.Alloc in the player? The Editor has overheads that the player doesn't.

 

As i said, the Editor has overhead that the Player doesn't which includes allocations that the player doesn't.

You can attach a profiler to running build. That's how you profile on the device.

You don't show what you're doing so it's clearly impossible to say what is causing this however guessing, if you're calling Collision.contacts then that'll be why. Maybe you've got the following option turned off: https://docs.unity3d.com/ScriptReference/Physics-reuseCollisionCallbacks.html

Being as you're necroing this thread, I can only presume you read the thread and nothing above relates to what you're doing?