Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Voting for the Unity Awards are OPEN! We’re looking to celebrate creators across games, industry, film, and many more categories. Cast your vote now for all categories
    Dismiss Notice
  3. Dismiss Notice

2D Physics lagging considerably vs 3D

Discussion in 'Physics' started by dzeitler2, Mar 27, 2018.

  1. dzeitler2

    dzeitler2

    Joined:
    Aug 20, 2015
    Posts:
    7
    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
    https://forum.unity.com/threads/2d-physics-about-100x-slower-spoolup-than-3d-physics.428160/

    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.
     
  2. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    10,470
    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.
     
  3. dzeitler2

    dzeitler2

    Joined:
    Aug 20, 2015
    Posts:
    7
    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.
     
    MelvMay likes this.