Official 2D Physics in Unity 2021.2 beta

In Unity 2021.2 we’re introducing two new features for 2D Physics that provide direct access to primitive shapes and unlock additional extensibility possibilities.

What’s new?

• CustomCollider2D
  • A new collider with direct access for creating, updating and deleting actual primitive shapes.
  • It can use any combination of the available primitive shapes that the physics engine understands i.e. Circles, Capsules, Polygons or Edges.
  • As a 2D Collider, it automatically inherits all existing features such as physics materials, triggers, physics callbacks, effector compatibility, scene gizmos etc.
  • Physics shape properties can be modified at runtime as well.
• PhysicsShapeGroup2D
  • Represents a simple collection of primitive shapes.
  • Physics shapes can be added, modified or removed and PhysicsShapeGroup2Ds can be merged.
  • Designed to define the shapes in a CustomCollider2D
  • A PhysicsShapeGroup2D can be populated by using Collider2D.GetShapes on any existing 2D collider or Rigidbody2D.GetShapes on any Rigidbody2D (to get all shapes on all colliders).

Samples
Check out the 2D Physics Samples GitHub repo, especially the scenes in the colliders folder that show CustomCollider2D and PhysicsShapeGroup2D in action:

• CustomCollider2D_Compound
• CustomCollider2D_Logo

About 2D Physics
Read more about the new 2D Physics features here:

• CustomCollider2D
• PhysicsShapeGroup2D

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!

 

Depends on which part you mean but the CustomCollider2D means you can create your own colliders with a mixed combination of unlimited shapes in a single collider. Want to create your own CompositeCollider2D, PolygonCollider2D or your own TilemapCollider2D? You can with this.

Yes. We're working on a bunch of features for 2022.1 and Contact Modification is one of them however, now I've said that, I will add that features unless fully complete won't make it and will be bumped to a later version. In short, promise the feature, not promising the 2022.1.

 

Question: Is what bad for performance?

Are you asking about the CustomCollider2D and how it performs when changing shapes etc? As mentioned above, this collider gives you very fast access to low-level shapes which are just simple structs. You can create/update/destroy shapes individually or in batches as you want, allowing you to create your own simple or complex colliders.

This collider can reproduce any of the existing colliders. Unlike the existing colliders though, it has pretty much no "hidden" work to do because you're feeding it geometry the physics engine already understands so there's practially no overhead there. There's also NativeArray support so you can generate shapes/vertices in Jobs using Burst and fire that to this Collider. We've tried to remove the limits here and expose as much as possible.

Whilst creating this there were a few videos put out demonstrating it being changed in realtime at high framerates with lots of shapes. This is really stress testing it during development and not so much about practical usage examples but those videos are here nevertheless. In all these videos, it's a single collider being modified by a simple script on the main-thread:

 

TBH this is just taking this thread off-topic with a rendering feature request. Feature request are great but I know you've been discussing rendering features here where you already have the attention of a 2D graphics engineer.

We're hoping for 2D physics feedback here so posting a rendering feature request isn't appropriate.

 

Potentially but that's not typically how soft-bodies work which are normally implemented by creating vertices/bodies with joints/constraints. The rest is rendering using something like SpriteShape like this.

That said, given that you can have unlimited and mixed shape types in a single collider where you are free to modify/update the shapes, you can use it for whatever purpose you have and maybe some soft-body closed shape if it suits. This is raw access though so it shouldn't limit use-cases beyond the inherent limitations of the 2D physics engine.

 

The motivation here is part of the 2021.2 onwards drive to not implement high-level black-boxed features but rather to expose, as low level as possible, engine access allowing you to create features you need but also allow us to base features on them too. This feature is exposing the collider system by providing a collider that allows you to create your own, maybe to replace the black-boxed ones we provide but with your own options. The only major "limitation" being the four primitive shapes available in the physics engine.

For instance, if don't like what the TilemapCollider2D does and want a regular grid-based collider where you stream-in chunks of tiles (Minecraft-ish) and want to then "join" them together then you can use this for that. Or maybe your own version of CompositeCollider2D that introduces computed solid geometry.

Nothing stopping you using this for that.

Another use-case would be physics destruction and more so because this feature landed with the ability to read shapes from all Collider2D too. Right now devs use the PolygonCollider2D to specify a path (outline) which we have to decompose down to (convex polygon) shapes the physics engine can consume. We do that outside of your control. Now you could read the shape data, pass that to a job-system thread, smash it up and generate shapes then send that data to your custom collider(s).

Finally, now we have real physics shapes defined as a first-class type, we can use this elsewhere. For instance, "physics shapes" on Sprites are not shapes at all; they're outlines. We can transition the usage of this there so a sprite could define a shape group that need no further processing. Same for Tiles etc.

 

Nothing I've created no. Maybe if I get time later in the year I could add it as a physics example though but no promises. Most of the code would really be showing off one destruction algorithm and not so much the feature above which really just lets you fire any shapes you desire.

As another side case, we decided to use this feature for 2D shadows when colliders are used as one of the sources. It's fast enough for that and coupled with the improved shape-hash feature, you know if the collider has changed at all and whether you need to refresh.

 

The PolygonCollider2D takes arbitrary outlines as paths and can even define opposite windings to produce holes. None of this is geometry the physics engine understands so we use LibTess2 to decompose that down into primitive polygons (up to 8 sides each) and yes, that takes time. Polygons in the CustomCollider2D are raw primitive polygons that only allow 8 sides and can be consumed immediately with no work.

Yes but not in the way you describe. Right now the PolygonCollider2D does the (relatively) expensive thing of asking the Sprite for an outline then decomposes it.

For the future, we're looking at Sprites containing REAL physics shapes, not what are described as physics shapes now (they are not) which are just outlines (See here). It'll mean that in the Sprite Editor you'll be able to author real physics shapes so multiple circles, capsules, polygons, edges and even outlines that are baked into real physics shapes (polygons or edges) per-sprite. This data is baked into the Sprite but whereas now it's an outline that requires a runtime processing to decompose it, like the CustomCollider2D, it can be consumed with almost no work.

So to answer your question, yes you'll be able to read the physics shapes (as a PhysicsShapeGroup2D).

A couple of alternatives in the meantime might be:

• Read the Sprite outline (physics shapes) now and use Libtess2 C# to give you 8-sided polygons from it. I've experimented with this and it works very well. I also created a pseudo-CompositeCollider2D (using the CustomCollider2D) with it because that's all the composite is; it reads the paths from the box/polygon and uses libtess2 to create a bunch of 8-sided polygons or outlines. I'm tempted to add this as an example in my PhysicsExamples GitHub project. Let me know if you're interested in this. It's exactly what I'm doing here i.e. outline to polygons all in script.
  
• Read the triangles from the Sprite and use that data to create triangle polygons (potentially too many here though).
• Read the vertices from the Sprite (as above) but find the hull of them and use that to create polygons using Libtess2 C#.

Note: We added Delaunay triangulation to the PolygonCollider2D/CompositeCollider2D and you can do the same with Libtess2 C#. It means you get polygons but fewer of them generally, especially with curved sections that typically produces fan-shaped triangles.

 

Adding to my reply on this: What actually happens isn't specific to a collider, well technically not. What does happen is that the local scale of the Transform is used. This works as expected for every collider but the CircleCollider2D has to deal with it in a specific way because it has to be uniform scaling because there's no Ellipse primitive. You are correct in that it takes the maximum XY component of the local-scale and uses that.

Essentially this pseudo code in Unity:

Code (CSharp):

1. // Calculate the scaled radius.
2. const Vector3f scale = GetComponent<Transform>().GetWorldScaleLossy();
3. const float scaledRadius = Max(Abs(scale.x), Abs(scale.y)) * m_Radius;

 

Hi folks! Unity 2021.2 has been released and these features in 2D Physics are part of it! I'm closing and unsticking this thread. Let's continue the discussion here!