2D Collider Light Shadows APIs

What functionality do you mean? 2D shadows directly using physics geometry? If so then know that 2D Shadows that uses collider geometry is coming from the 2D team (see video experiments below). The physics part of that work was done earlier this year; there's various shadow specific work being done on top of that. Maybe you mean some other specific functionality though?

Our implementation only uses public physics API. The core of this is the ability to get the physics shapes from any collider using Collider2D.GetShapes which uses a PhysicsShapeGroup2D to store that information. Also using Collider2D.GetShapeHash to determine if it has changed so you're not constantly retrieving it per-frame. Although not used in our implementation, there's also Collider2D.CreateMesh to create a mesh that covers the area of 2D colliders although as you can see in the docs, this doesn't support zero-radius lines because you cannot have a planar mesh that is just a line because it's just a collinear/degenerate triangle.

Note that this has been used for a while for things like 2D Navmesh where the physics geometry is required.

 

That's an old set-up where yes, only polygons were supported. The shadow code now correctly supports curved surfaces so circle, capsule (ends), edges and boxes with an edge-radius.

It's not using raycasting or physics queries at all. I wasn't indicating that the shadow code itself was public and available, that in itself is the new feature but the code that touches 2D physics is using all public API that I mentioned previously i.e. getting the actual geometry if it's changed and using it to produce shadow details. The new shadow code has a "provider" which can provide any geometry it likes for shadows, the shadow code goes away and decides how it produces shadows. My point was that you'll be able to create your own if you like but the one we provide that supports physics uses all public API.

Creating a mesh shouldn't be affected by feature. The mesh is created based upon the low-level physics shapes produced. Its job is not to create a mesh that is the same physics geometry but to cover the same area. Obviously this is true for circles/capsules because those are just a point or two and a radius internally. Did you spot a problem? Maybe you're asking if you could have an option to use Delaunay when producing the mesh? That's certainly possible and an interesting idea if so.

 

No but understand that I'm not the dev, I only implemented (using the existing public API) the provider to support colliders. You declare the provider and the types it supports and the shadow code calls it to "provide" the relevant geometry and/or determine if it needs updating at all.

Well physics doesn't use or have a mesh for colliders; a collider has PhysicsShape2D so if you want them, you can use the API I mentioned above. This is the "mesh" you want. If the PolygonCollider2D is set to use Delaunay, it'll return the convex polygons you can see in the gizmo. If it's off, it'll return those convex polygons you can see in the gizmo.

Regardless, it is a good idea to have that option for the mesh but understand, this won't necessarily be identical to the physics shapes used in a collider; it's just a mesh for you to use, not something physics uses. Indeed, the physics system never sees this, it's just a nice helper call.

You're most welcome. Likely I'll add that Delaunay option to CreateMesh, it's a great idea I didn't consider so thank you.