Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice
  3. Dismiss Notice

Official 2D Physics in Unity 2023.1

Discussion in '2D' started by MelvMay, Nov 20, 2022.

Thread Status:
Not open for further replies.
  1. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,683
    2D Physics in Unity 2023.1 (alpha)

    SubStepping.png

    Hi 2D folks! We have new updates for 2D Physics in Unity 2023.1 alpha.

    What’s new?
    • New Physics Sub-Stepping Option
      • A new method of performing the simulation known as sub-stepping was added. This and other related options are availble in the Physics Settings Window.
      • Sub-Stepping is available for per-frame or manual simulation steps and will perform smaller time-interval sub-steps when a large time has elapsed. This allows the simulation to stay stable even during poor frame-rates (large simulation delta-time).
      • Dev Video

    • New Physics Simulation Layers
      • A new feature has been added that allows specific layers (Simulation Layers) to be simulated for any simulation modes (the automatic FixedUpdate/Update or manual Script).
      • The feature gives you finer level of simulation control when performing a simulation step.

    • New Rigidbody2D usability and performance features
    • New Physics Queries, Improvements and Deprecations
      • Added query overloads for Rigidbody2D and Collider2D of Cast, Overlap and Distance to allow quering from a specified position and rotation without the need to first move the Rigidbody2D or Collider2D.
      • New Physics Query performance improvements
      • Most physics queries with the "NonAlloc" suffix are now obsolete as they have had an equivalent without this suffix for many years.

    • New HingeJoint2D Feature
      • A new property of "useConnectedAnchor" that allows the complete disabling of the point-to-point constraint of this joint. The joint can now be used for just the motor and/or limits without constraining position which is particularly useful when the joint connection to another Rigidbody2D isn't required.

    • New CompositeCollider2D Feature
      • Per-collider compositing operations (None, Merge, Intersect, Flip & Difference)
      • Per-collider compositing operation to control compositing sequence
      • Support for CircleCollider2D and CapsuleCollider2D added to the existing BoxCollider2D, PolygonCollider2D and TilemapCollider2D.
      • New "GetCompositedColliders()" to retrieve which Colliders are being composited.
      • Dev Video #1 / Dev Video #2

    • Miscellaneous
      • Collider2D.CreateMesh now has a Delaunay Triangulation option that should, in most case, produce a more optimized mesh.
      • All the latest appropriate Box2D fixes.
    Samples
    Check out the 2D Physics Examples GitHub repo. We've added a bunch of scenes to demonstrate some of the above new features:

    About 2D Physics
    Read more about the current 2D Physics features here.

    What can you do?
    Try it out and let us know what you think of the additions and improvements. We want to know what works as expected, what doesn’t and what is missing. We’d love to see how you use them as well, so please show off all the cool things that you make with them!
     
  2. pastaluego

    pastaluego

    Joined:
    Mar 30, 2017
    Posts:
    199
    Is it possible to add custom Actions to get invoked in each internal substep call?

    For example if I use raycasts for my 2d collisions instead of box2d physics, it looks like I won't be able to utilize the benefits of substepping unless I'm misunderstanding how it works.

    But if I were able to add the raycast collision check methods to some delegate list that gets called in each substep, then I think I could still use it.

    Right now regardless of FPS, if a single rigidbody is moving too fast I divide all rigidbody movement into steps in fixedupdate, then at each step I increment the rb.position by the stepped movement and then check raycast collisions until the last step gets the finalPosition of every rigidbody. But this breaks interpolation unless I move every rigidbody back to their original position at the end and then rb.MovePosition(finalPosition) before the internal physics step. This works but it's not ideal.
     
    Last edited: Feb 18, 2023
  3. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,683
    Substepping is an internal thing, from your perspective the simulation time-step is from the frame delta-time or the time you pass in the manual simulation step, it doesn't work in FixedUpdate mode.

    I don't see how what you're doing relates to this sub-stepping option, it's not about making discrete detection more accurate, just stable at varying simulation rates. It's not a velocity based feature but a simulation time-step feature. Doesn't sound like it's a solution to whatever your problem is.

    That said, I don't see why you need to divide into steps if you're using kinematic motion, physics queries don't care about it, they won't miss anything; they are effectively continuous collision detection. Perhaps a conversation for another thread perhaps.
     
  4. CoraBlue

    CoraBlue

    Joined:
    Nov 16, 2017
    Posts:
    60
    I regret I didn't test this sooner. It's been on the backburner while I've been working on personal projects, but this is really extremely important for the next generation of 2D developers looking to break in to Unity.

    I have some thoughts on Slide, but first I should ask: What are these new Physics and Rigidbody additions and what aren't they? If they're meant to be out of the box solutions then they're lacking some important features and sometimes behave oddly. I assume this stuff is meant to be extendable, but it bears mentioning.

    First up, it's not clear if the rigidbody is meant to be simulated or not. If the rigidbody is simulated it will ignore SlideMovement's layermask settings. If it isn't simulated you lose all interactivity with other rigidbodies which may cause confusion or disappointment with users. I really appreciate the built in layermask functionality. (On a personal note, I say to hell with Unity's wonky physics system anyway for retro 2D games, kinematic everything! But if that's the case people will want stuff like moving platforms, etc)

    Secondly, I appreciate the small finetune options like surfaceAnchor. Turning that down achieves a more pleasant result that doesn't end up 'snapping' the player too noticeably to the floor. I worry nuanced control like this might be lost in a final version. Actually, I'd like more control. I'd like move acceleration and for gravity to act as acceleration and to have another 'terminal velocity' field that acts as the y speed cap. Gravity acting as a constant downward speed isn't what I expected and feels bad.

    Also, am I missing it or are there no simple returns for detecting 'stuck' states? I would at least like some kind of return or handling inside of Slide if the rigidbody ends up inside another collider. For example, being smashed with a level geometry by a scrolling screen or animated level geometry. I got inconsistent behavior in these states (being able to move left but not right for example).

    Lastly, just some food for thought. If Slide is the evolved version of Move for 2D Platformers, have you thought about an evolved AddForce? You're solving so many problems here for sidescrolling movement. It would be just so fantastic if you could paint a complete picture that included jumping. Game feel is so important and playing guessing games with Unity's physics system is annoying. People want to create arcs. They want to know exactly how high a jump will go and in how many seconds. They want to visualize that stuff in advance. That would be HUGE.

    Thank you for the work you guys are doing. If I have any more thoughts after playing with the other features here I'll leave them.
     
    Last edited: May 9, 2023
  5. alkaitagi

    alkaitagi

    Joined:
    Dec 8, 2016
    Posts:
    87
    Thank you @MelvMay for this fantastic API that makes the 2D so much easier!

    But there's one serious problem for my use case: PlatformEffector2D. Is there a way to make the two features work together? Tried various configs; they don't account for each other.
     
    MelvMay and LoupAndSnoop like this.
  6. LoupAndSnoop

    LoupAndSnoop

    Joined:
    Jun 23, 2023
    Posts:
    39
    I also have this issue. It makes it very hard to make a fully tile-based game when I can't draw tiles with edge colliders, and I can't make a PlatformEffector2D work properly with a composite collider. I would really like to see these two basic features start working properly together.
     
  7. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,683
    Please don't hijack this thread for feature requests.

    The PlatformEffector2D works perfectly well with any type of collider because it doesn't see colliders, only physics shapes; it doesn't matter what created them

    What you're actually asking for is likely one-way on individual tiles so that would be nothing to do with the PlatformEffector2D (works on a collider, not tiles) nor the CompositeCollider2D but a feature of the Tilemap system i.e. the TilemapCollider2D. To note, the physics shapes in a tile don't exist to have any form of one-way when you use the composite, that's the whole point of it; all that info is lost.

    I acknowledge the feature request but I also wanted to address the point that the above somehow isn't working properly, it is.
     
Thread Status:
Not open for further replies.