Physics.Contacts GC activity

While optimizing audio performance of our game Human: Fall Flat, I've noticed quite big GC allocations in Physics.Contacts. It leads to GC collect once a second, potentially skipping a frame in a game. I noticed this a while ago in other project on Windows Phone and thought it's WP specific. I believe this is related to allocating contacts array before passing to monobehaviors if no OnCollisionEnter/OnCollisionStay methods are defined it does not happen.

Human will feature a physics based audio and we need to get collision information which is later processed to drive audio events. Already heavily optimized the code inside OnCollisionEnter and OnCollisionStay, but this GC issue is outside my code.

We have one more GC allocation in GeometryUtility.CalculateFrustumPlanes but it's only 136B per frame, still it would be nice to have and overload where we could pass existing array.

Is anyone else facing similar problems?

 

I'm experiencing the same problem, any one know a solution?

 

I had a small discussion with https://twitter.com/AnthonyYakovlev (don't know his forum handle) on alpha about this and he says there are plans. You can probably poke him on twitter to see if he wants to talk about it - he'd probably enjoy a stress test scene to work with...

 

This is a pretty huge issue, it makes OnCollisionStay almost unusable. Is there any news on this?

We just got NonAlloc versions of RayCastAll etc., it would be really great if we could get a NonAlloc version of OnCollisionStay, at the moment the garbage generated is just too much.

Another big improvement would be if we could call OnCollisionStay on demand or selectively instead of all the time.

 

Thanks guys, it's a nightmare trying to raycast reliably when OnCollisionStay has everything we want, and it can be solved but it just isn't :/

Often enough it's just one contact as well, we don't need many, but we need new data every fixed update... Seems crazy such a simple matter renders ..Stay() unusable.

 

That sounds brilliant for all our projects (we use 2D and 3D physics, spending on title). I hate to ask but would it be possible these (3D and 2D) changes make it in before Unity 6?

 

That sounds good, thanks for the update. Personally I am working with 3d, and as hippo said the ability to limit the contact points stored on every call would be very useful as well.

Non allocating struct sounds perfect. Really looking forward to the new callbacks.

 

At least 1KB of allocation per frame and per object that uses the callback. It quickly gets ridiculous. You need to do something.

 

Thanks for looking at this and appreciate it's dependent on other work going on.

Is there any updates or a timescale?

With heavy Physics it's killing the FPS:

 

I see this is scheduled for 5.5

Hopefully the GC alloc fix will have been done alongside that PhysX upgrade? (one can dream, right?)

Also...



I'd really like to know if we'll get something like "UseFullKinematicCollisions" for 3D rigidbodies?

 

@MelvMay This issue still exists in Unity 5.5.2f1, can you confirm this will be fixed in Unity 5.6?

 

So anyone know if this is fixed in 5.6 now that it is released?

 

There are still 'Physics2D.ConvertCollision2DForScript' GC allocations showing in the profiler in 5.6 and 2017.1.0b3 if you implement OnCollisionEnter2D. There is a screenshot of the profiler in this thread. https://forum.unity3d.com/threads/physics2d-collision-garbage.468708/

 

@MelvMay - i see you are still alive. is this thing actually getting fixed or is it time to roll our own physics?

 

Users don't really care about excuses, but we do need to make hard decisions that will affect our development schedules. In this case, I don't have much confidence that it will ever get fixed. It's unfortunate because this is the only GC in my game, i am sure others are in the same boat.

I am also sure that we would be ok if you bypassed the backwards compatibility excuse and made parallel API, like the raycast stuff, something along the lines of OnColisionEnter2DNoAlloc().

 

Melv, you are 100% correct. I am just frustrated, and I can see you are too. I am sorry for being a dick.

What we should do is discuss here, so others that are also frustrated, when searching for help, have some ideas. One thing you mentioned, and is certainly a good idea, is polling.

On the low-end android device, I see around 5ms per frame spent in overhead polling 125 rigidbodies against maybe 250 total rigidbodies in a busy scene via GetContacts with contact filters. these scenes are not the norm, but they do happen sometimes.

5ms is more than i would like to spend doing anything in a frame. Obviously all 125 rigidbodies are not colliding every frame, one would assume a callback method is more efficient.

But, as you said the callback method itself must have some overhead. assumptions are dumb. balancing costs of polling fixed cost vs garbage doom frame, perhaps polling does make more sense? I am running some benchmarks now to find out.

 

all 2d rigidbodies.

 

I should also add all of the colliders are CircleCollider2D, one per rigidbody, nothing fancy. good old radius checks.

 

Also, are contacts cached when resolving a collison, or is a Collider2D.GetContacts() poll testing for touching on-demand? there's that nagging worry of missing high-velocity/highly-elastic collisions. when i get a chance i should write something that compares Collider2D.GetContacts()'s results with a circlecast and verify.

Is there a way to get all of the collisions that happened in the last frame into a pre-allocated array in a single call? this would be ideal. i want to know about collisions, not necessarily contacts. Magic trampoline rides aren't free. Instead of hundreds of API calls, it's better to make zero or one.

In my case I do not need the actual contact points. I just have a bunch of CircleCollider2Ds and want to know if they bump into each other..

circleA - many of these
circleB - often more circleB than circleA, but not always. passive.

all i need to know is if any circleA was in a collision with any circleA or circleB, and if so, who was involved. don't care if circleB hits a circleB.
for this i have been using layermask and callback that quickly looks up whatever data I need using the collider2d's instanceId as a key. that's all i need, is some key identifying who is colliding with whom. no points or anything else. relative velocity would be nice, but i can work all that out pretty quick.

anyway, this works pretty good, callbacks aren't called all that often, certainly not even once a frame. if it wasn't for that gc...

i have also been testing this, only polling cirlceA, only when they are in a state that matters. worst case is currently around 125 calls per frame. on PC, that's not too bad, but on android it adds up quick.

UnityEngine.Profiling.Profiler.BeginSample("poll collision");
int colliderCount = myCollider2D.GetContacts(contactFilter, colliders);
UnityEngine.Profiling.Profiler.EndSample();



Here we can see the overhead of just calling that function 133 times was over 3ms (and the profiler node overhead, sure). the function itself only took 1.6ms. This is the overhead I am trying to avoid.

 

I should add that that cost fluctuates wildly. in this frame it may have had some collisions to report:

 

Thanks for the clarification. GetContacts() should be more accurate than a simple circlecast then.

I am now using your excellent "Physics2D.autoSimulation = false;" to use unity like most other game engines, where physics is run exactly once per frame. I call Physics2D.Simulate(Time.deltaTime) on the update pulse. This makes my game run hilariously smoother- less jitter, fewer frame drops, and more consistent than using autoSimulation and FixedUpdate.

most frames would have 0 contacts. there are up to 255 CircleCollider2Ds in the world, but they are usually not touching each other. I do not have a simple project set up.

 

If you can keep your framerate consistent, this is not much of a real issue. We're looking for 'good enough for a player to have fun' not full-on determinism here.

In terms of smoothness, I would rather update once a frame than ever have to worry about a spikey frame caused by running sim more than once. Updating less than once a frame causes visible jitter, so what you want is to sim once a frame.

And then you get the sample aliasing that happens when you run the simulation clock (FixedUpdate pulse) separate from the rendering clock (Update pulse). This aliasing is also visible as jitter. Nothing is rendered truly fluidly, there is always positional and rotational harmonic noise in the signal due to the fluctuating temporal difference between sampling and rendering. Anyone who has done a bunch of audio dsp stuff will tell you about some guy named Nyquist. To reduce this, you run the sim clock as close as you can to the render clock to get a more analog response. Which I am a lot closer to now.

Even if it is slightly less accurate when the GC doom frame strikes, it is far more pleasant for the player to do it this way. And my framerate has not declined by doing it this way. If anything it's improved because it never sims more than one frame in a frame.

Thanks for the tip. I will try that.

Me too. That was profiled on our minspec android. Occasionally there some contacts, but usally not. In the graph view, that frame had one of the 135 calls to GetColliderContacts() block for many ms. It was one spikey call rather than all of them... regardless, it shows that paying for the ticket to ride the magic trampoline to unity land 135 times is not worth it in my case.

 

darn, interpolation was already off. was hoping for an easy win.

 

to be clear, interpolation would help if i wanted to run the physics at less than 30hz... but running that slow introduces latency, which is no fun for anyone. it does help filter aliasing noise, but adds it's own distortion error, especially when extrapolating. but the real big thing is running 2 frames+ to try to catch up on a slow device just makes everything worse. might as well just run physics once a frame and be done with it.

 

A/B test 2d physics with let's say a spring joint with physics running at say 80% of rendering framerate with interpolation against Simulate(Time.deltaTime) with no interpolation and the difference is astounding. the second is incredibly smoother. The cost is one sim per frame, and you don't pay for interpolation.

 

yeah Melv, this is seriously the greatest improvement to rendering physics with fidelity my game has seen in a while. I'm stoked on it.

 

RE: Physics.Contacts GC activity.

On Android my game shows Zero GCAlloc while OnCollisionStay is firing.

In the editor (In Windows or Android player settings) it still shows 140b per OnCollisionStay.

I know OnCollisionStay is firing because I'm analyzing contact point/s to make spatialized metal scrape sounds as a vehicle scrapes buildings, I was watching the deep profiler: zero GCAlloc.

Also noticed reading GameObject.name or tag also gave no GCAlloc on Android device, it does in editor.

The GCAlloc in android device profiler seems to be accurate, I'm a little sloppy with some less frequent transient events and it was as expected.

 

This seems like classic "Bus Stop" problem; you are waiting for the bus, but it's late and you aren't sure if you should just start walking. The longer you wait, the more you don't want to lose the time you've already waited in case the bus comes right after you leave, so the longer you stay, the harder it is to leave.

This thread is over a year old and backwards compatibility was trying to be preserved, but here we are later and GC on collision callbacks is still a problem, but hey, at least everyone didn't have to rewrite code to take advantage of a better system... Are we going to leave the bus stop soon?

 

But three will come along at once.

 

They should have used the 2017 release to fix it... While they decide not to fix, we have to look at this stuff...

 

not sure if this has been mentioned yet - but I only see Physics.Contacts GC allocs in the editor; not in builds

This appears to be similar to GetComponent creating garbage in editor if the component isn't found, but not in builds. It's because it generates editor-only warning message strings internally

 

Interesting, but that profiling pic I posted is from the editor attached to the android running the game, so we can be safe to ignore all this GC if the profiler is not attached ?

 

I'm not going to assume. Contacts seems like an area that should generate garbage because we aren't passing an array for Unity to fill.

 

This still has not been fixed as of 2018.2 either, unfortunately. I am having a huge issue with it when trying to use PuppetMaster in my game, which is killing me as PM is one of the most major parts of the game.

Is there any update on this at all? : \

 

We will see after 2018.3 since the version of Physx changes there.

 

It's unity's interface between unity and box2d / physx that is creating the garbage allocations, so bumping physx will probably do nothing.

The GC from contacts has been the ONLY gc in our project for years at this point. it still causes GC frames.

This is 2018.2.5f1 connected to a player build, it generally allocates in increments of 7k. I have seen it spike up to over 100kb in a frame similar to that screenshot above:



I have zero faith that unity will ever fix it, or provide an alternative, non gc interface for acquiring contacts. There was some discussion here a few years back that sounded like they were thinking about fixing it, but there certainly has been no measurable action. Future projects will consider alternative technologies.

 

2018.2.13f1
These tiny spikes freeze FPS

 

One can only hope for allocation free contacts one day.

 

Still eagerly waiting for this, keep us posted with the details!