2D Physics lagging considerably vs 3D

[dzeitler2]

Let me say that I’m no stranger to the 2D and 3D physics systems. I know they are completely different in the eyes of the engine.

I did a test of 500 boxes with 2D box colliders and 2D Ridgidbodies.
I did the same test with 500 boxes with 3D box colliders and 3D Rigidbodies

I then set the ability to toggle between the two (turning off the 2d to turn on the 3d version and vice versa).

What i’m noticing is a HUGE frame dip on the 2D side until all the boxes have settled. If more boxes start to move again (i.e detect more collisions) the lag continues.

On the 3D side I do not get such lag at all. At run the boxes start to fall and collide. At no time do they start to dip below my 30fps test target.

I did ANOTHER test.

Simply spawning 2D physics cubes into a volume until my FPS drops below 30FPS

Again on the 2D side I get under 30FPS at only 2300 boxes but on the 3D side I get over 3000 before getting the same framerate dip.

Let me be clear, I tested these in BUILDS so that the editor performance load wouldn’t effect my findings.

So what gives?

I found this post

2D physics about 100x slower spoolup than 3D physics

500 objects in one spot, box2d and rigid2d on them, I press play, wait and wait and wait, after about 5 seconds it moves, stutters at first then smooth as butter. Same thing with 3D box and rigid, spool up in 1/10th of a second. I would say this is a problem. PS: if I scatter the objects so they don’t start in one point, 2D spool up is much faster.

That basically says it’s a problem with the 2D overlap and that Unity doesn’t have the time resources to do such a massive overhaul.

I’m wondering…performance wise if it’s better to just go to 3D at this point until Unity works it out down the road but i’m curious if my findings are isolated.

[MelvMay]

Could you please provide both test projects either here or attached to a bug case (and give me the case number).

@dzeitler2

That basically says it’s a problem with the 2D overlap and that Unity doesn’t have the time resources to do such a massive overhaul.

Don’t have time/resources? Massive overhaul of what? This is a very old post too. Note in that case, it was talking about a bug where things were interacting that were set not to so don’t see how it’s related to what you’re referring to.

At only 2300 boxes. Well, that’s a lot of boxes but more specifically, it’s likely a lot of contacts. Did you look at the profiler to see what was taking the time?

One of the major differences between Box2D and physx is that Box2D is single-threaded whereas physx performs many tasks on multiple-threads. That has changed since 2018.1 alpha with the introduction of experimental multi-threaded 2D physics, so yeah, we put in some time and resources. You can go into the 2D physics settings and switch that on to see if it helps with your case.

Here’s a few videos showing you that working:
Single-Threaded
Multi-Threaded

As I said, I’d be curious to see your test projects and/or the profiler results to see what’s the bottleneck here.

[dzeitler2]

@MelvMay

Could you please provide both test projects either here or attached to a bug case (and give me the case number).

Don’t have time/resources? Massive overhaul of what? This is a very old post too. Note in that case, it was talking about a bug where things were interacting that were set not to so don’t see how it’s related to what you’re referring to.

At only 2300 boxes. Well, that’s a lot of boxes but more specifically, it’s likely a lot of contacts. Did you look at the profiler to see what was taking the time?

One of the major differences between Box2D and physx is that Box2D is single-threaded whereas physx performs many tasks on multiple-threads. That has changed since 2018.1 alpha with the introduction of experimental multi-threaded 2D physics, so yeah, we put in some time and resources. You can go into the 2D physics settings and switch that on to see if it helps with your case.

Here’s a few videos showing you that working:
Single-Threaded
Multi-Threaded

As I said, I’d be curious to see your test projects and/or the profiler results to see what’s the bottleneck here.

Thanks for your reply! I will find time to go back and run the tests to screen shot the profiler for you. Physics calculations being restricted to one thread with so many collisions could be why I saw such a loss in performance in comparison but I will profile again to see for sure in this case.

Very glad to hear so many overhauls to the engine with 2018! Talking with Unity engineers at GDC gave me the impression that Unity before the big recent hiring phase, had to chose where to put the most resources in RnD. I’m really glad to see the whole engine getting attention. I will definitely test in 2018.1 when I get a hold of it.

[dynamicvoltagegames]

Resurrecting this thread because I have the same issue. It’s not just physics though, it’s even sprites. Rendering 200 sprites, which is NOTHING, only gives me about 40 FPS, whereas I can get over 120 fps if I just render planets with unlit/transparent textures on them. Everything about 2D is slower than 3D for me (Unity 2022.3.11f1) - by a LOT.

[MelvMay]

@dynamicvoltagegames

Resurrecting this thread because I have the same issue.

Please don’t necropost on these forums. Create your own threads and post your own details.

Your issue isn’t the same issue at all which was exclusively about 2D physics.

Thanks.