2D Physics in Unity 2021.2 beta

7374698--899342--PhysicsCustomCollider2D.png

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:

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!

4 Likes

This is really cool.
I'm not entirely sure what the real-world usecases are for this yet — but I always like more features (and I'm sure I'm going to run into a need for this eventually), so I'll take it! :smile:

Big question though; does the Box 2D team plan to add a 2D contact modification API, similar to the one PhysX is getting ?
And if the not, can we please add it to the list? (I really want this feature). :sweat_smile:

Thanks. :p

[quote=“NotaNaN”, post:2, topic: 850340]
I’m not entirely sure what the real-world usecases are for this yet
[/quote]
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.

[quote=“NotaNaN”, post:2, topic: 850340]
Big question though; does the Box 2D team plan to add a 2D contact modification API
[/quote]
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. :wink:

1 Like

[quote=“MelvMay”, post:3, topic: 850340]
Want to create your own CompositeCollider2D, PolygonCollider2D or your own TilemapCollider2D? You can with this.
[/quote]
Ooo, that’s a really good example / usecase I didn’t consider — I now see the applications for this. :hushed:
Thank you very much for pointing this out! (I now am really looking forward to upgrading to 2021.2). :smile:

[quote=“MelvMay”, post:3, topic: 850340]
Yes. We’re working on a bunch of features for 2022.1 and Contact Modification is one of them.
[/quote]
This is fantastic to hear!
Thank you so much for the leak on the future 2D features!

[quote=“MelvMay”, post:3, topic: 850340]
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. :wink:
[/quote]
I am prepared to wait as long as necessary. :stuck_out_tongue:

1 Like

[quote=“rustum”, post:1, topic: 850340]

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:

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!
[/quote]
It sounds cool!

Question: Is it bad for preformance?

[quote=“r31o”, post:5, topic: 850340]
Question: Is it bad for preformance?
[/quote]
Question: Is what bad for performance? :slight_smile:

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:

https://www.youtube.com/watch?v=V0cP8SaL48Y

https://www.youtube.com/watch?v=cGwxZayiHIw

https://www.youtube.com/watch?v=VOskTWltUJU

5 Likes

I know this is for physics2d but can we pkease get the similar functionality to the 2drenderer 2dlight? It also has polygon light with shapes which current has no api access for...

[quote=“castor76”, post:7, topic: 850340]
I know this is for physics2d but …
[/quote]
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.

4 Likes

is this ability to change shapes good for making/faking soft-bodies?

for bodies expanding and contracting?

[quote=“april_4_short”, post:9, topic: 850340]
s this ability to change shapes good for making/faking soft-bodies?

for bodies expanding and contracting?
[/quote]
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.

I spent a few hours going over this a week ago. And trying to imagine what it could be used for, because it seems both incredibly fast and light.

I'm sincerely apologising here: I am struggling to find creative uses for it. I'm having a creative mental blank. Highly unusual.

As you're saying, I usually think of (and have made) a few soft bodies with joints and and constraints and then drawn based on their positions and the shapes I'm using at extremities as fake edges/bounds.

Did you have any ideas or things you were thinking of making when you came up with this?

Or is it a sort of halfway stage to somewhere else you're heading?

One idea that did come to mind, but can also be done with existing 2D physics approaches, is a modernised version of Qix - one of the first strategy arcade games.

Jump to the one minute mark to see the guide to how to play, if you don't know it:

https://www.youtube.com/watch?v=qO4y0vc9IZI

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.

[quote=“april_4_short”, post:12, topic: 850340]
One idea that did come to mind, but can also be done with existing 2D physics approaches, is a modernised version of Qix - one of the first strategy arcade games.
[/quote]
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.

3 Likes

[quote=“MelvMay”, post:13, topic: 850340]
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.
[/quote]

Dreamy stuff. Have wished for this for decades, it feels.


On the other stuff, I’ll continue to ponder creative ways to blow stuff up etc.

Please expect more silly, naive and stupid questions. I do specialise in these. It’s a feature, not a bug :wink:

1 Like

[quote=“MelvMay”, post:13, topic: 850340]
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.
[/quote]

This should probably be a poster on the walls of all the other teams in Unity. As a subtle reminder of a better way.

1 Like

[quote=“MelvMay”, post:13, topic: 850340]
Another use-case would be physics destruction
[/quote]

That sounds really interesting, is there any sample test project for this? :slight_smile:

Love to see 2D physics still being updated with new features, amazing work :)!

[quote=“Volshar”, post:16, topic: 850340]
That sounds really interesting, is there any sample test project for this?
[/quote]
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.

2 Likes

I love it!

Adding a polygon shape just takes the vertices. But there's some other things that happens - the debug view shows that a PolygonCollider2D is split into what looks like convex parts. I assume that that's being calculated on the fly as points are being set? I assume that this takes a non-zero amount of time?

There's two reasons I'm asking:
- There might be situations where we could know beforehand which parts are convex, and could supply that information instead of having it calculated?
- If we could get access to the code that does that, an out of the box "turn a concave polygon into a set of convex polygons" algorithm could often be handy!

In addition to that, when we add some kinds of 2D colliders to GameObjects that have SpriteRenderers, or reset ones that have already been added, the collider tries to automatically fit the SpriteRenderer. So PolygonCollider2D's follow the sprite's outline, BoxCollider2D's fit the bounds of the sprite, and CircleCollider2D's seems to take the greater of the bound's size-values as it's radius.
Questions relating to that:

  • Will the CustomCollider2D do this in some way?
  • Can we get access to those functions? They could be convenient if we want to stich together a CustomCollider2D to fit a bunch of sprites.

[quote=“Baste”, post:18, topic: 850340]
Adding a polygon shape just takes the vertices. But there’s some other things that happens - the debug view shows that a PolygonCollider2D is split into what looks like convex parts. I assume that that’s being calculated on the fly as points are being set? I assume that this takes a non-zero amount of time?
[/quote]
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.

[quote=“Baste”, post:18, topic: 850340]
Will the CustomCollider2D do this in some way?
[/quote]
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.

1 Like

[quote=“Baste”, post:18, topic: 850340]
So PolygonCollider2D’s follow the sprite’s outline, BoxCollider2D’s fit the bounds of the sprite, and CircleCollider2D’s seems to take the greater of the bound’s size-values as it’s radius.
Questions relating to that:

  • Will the CustomCollider2D do this in some way?
    [/quote]
    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:

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