The following information will soon be added to the Unity Roadmap but I thought it worthwhile adding it here. Note that the information here may eventually get stale and may be removed later. Items in “Research” are likely to go into “Development” for 2017 so just because they are shown there, doesn’t mean years until you get them. They’ll either appear in the 2D experimental build or a one-off custom build for feedback.
2017.1.0 (beta)
Simulation
Ability to manually simulate physics using “Physics2D.autoSimulation=true/false” and “Physics2D.Simulate(time)”.
Development
Low Level API
Expose low-level collider primitives of circle, edge, polygon & capsule and ability to retrieve from existing Collider 2D components.
New 2D collider with ability to be composed of low-level collider primitives.
Super fast, primitive intersection tests with batching support not requiring 2D collider components.
Gizmo support for primitive collider shapes of circle, edge, polygon & capsule. Useful in visualising/debugging intersection tests.
Research
Simulation
Multi-instance 2D physics worlds.
Ability to assign simulation group(s) to Rigidbody2D and simulate specific group(s) and/or calculate contacts for those group(s) only.
Expose contact processing allowing users to defer contact solving, enable/disable contacts etc.
Performance
Asynchronous CompositeCollider2D outline and triangulation.
Asynchronous PolygonCollider2D triangulation.
Multihreaded simulation.
Animation
New Animatable 2D Collider that tracks SpriteRender mesh.
Explicit Kinematic Rigidbody2D Hierarchy control
Joints
HingeJoint2D motor “free spin” support.
Joint2D anchor local scaling support.
Colliders
EdgeCollider2D ‘adjacent edge’ support allowing chaining of EdgeCollider2D together with virtual edges.
EdgeCollider2D to EdgeCollider2D collision support.
Rigidbodies
Transform write-back to planes other than XY using swizzle option i.e. write back to XZ, YZ etc.
Customised collision modes allowing alternatives to layer-based detection.
Distance based wake-sleep for Rigidbody2D.
Wake/Sleep Callbacks.
Ability to retrieve all Rigidbody2D, Collider2D & Joint2D.
Effectors
New asset-based effector behaviour system allowing blending of multiple behaviours.
SurfaceEffector2D “speed-up only” support disabling slowing down if surface speed is too high.
Very interested! Basics like getting Super fast, primitive intersection tests with batching support not requiring 2D collider components are wonderful.
I was wondering if this in any way helps with local physics? moving platforms can be tricky / arcade games on vehicles and various moving objects etc with arcade rules mixing with physics are difficult but often needed.
I do love the entire roadmap though. I see a lot of stuff I’d love to mess with including LiquidFun!
It may not come across in the roadmap but my main motivation here is to expose, in a sensible way, as much of the physics as possible so we do not continue creating higher and higher level constructs (effectors etc) but instead provide the ability to create those features yourself. That obviously means being able to do cool stuff in your games but also to the point where we can get much more sophisticated stuff on the asset store. It also means that more and more of the higher level stuff can be provided open-source, completely script driven. I’d like to be in a position where the UI team are where the components are scripts.
Expose contact processing allowing users to defer contact solving, enable/disable contacts etc.
This one alone means that every single effector we have can be done by a user, including the PlatformEffector2D.
That’s wonderful for me. Eventually Unity has to stop adding things for people who can’t code, especially if visual scripting can access these things you’re exposing in future… else you’d be doing nothing but high level work for years to come
Any idea on times? In particular my sense of fun reaches out for LiquidFun for the lava in my 2D game… (and water). I guess we would want an array of these points or at least a starter mesh to do further rendering with, maybe it’s rendered with the particle system?
No times. I’ll keep the **roadmap **updated. You’ll see things transition from “Research” to “Development” then into “Release”. I’ll also make a lot of noise about each on **Twitter **as usual which is where you’ll see it first with development screenshots and videos typically.
Posting here as it might be relevant to future plans…
@MelvMay currently I find myself needing to see if a gameobject with one or more colliders (components on the same object OR as children) … are overlapping another complex or simple arrangement.
I can get this with OnCollisionStay and filter out what I don’t need but I’m not sure if this use case is possible now or in the future roadmap. I’ll explain the situation:
I have a bunch of RPG style items such as swords, shields etc, and they all have different colliders, different numbers of colliders and so on, in short they’re unique.
But most of the time they do not need to be simulated, only when they’re dropped in the world. Bur when say, a sword is attacking, it needs to know if it’s overlapped with a shield, and they both don’t have any consistency with colliders.
So I’m not sure how to best check if the sword hit the shield, and if it didn’t, check the sword hit the player and so on. I figure I can do it manually but that is a hell of a lot of colliders to check pairs for against…
TLDR: need to get a list of other colliders touching my complex gameobject mess of multiple colliders. This Unity - Scripting API: Physics2D.OverlapCapsuleNonAlloc is fine, but my objects aren’t just made of capsules, so I would have to peform multiple separate Overlap checks for boxes, capsules, circles, each time filtering out results that belong to the same gameobjects.
I feel that would be asking Physics2D to do a lot of redundant work.
Note that you can do the iteration yourself using a combination of Rigidbody2D.attachedColliderCount and Rigidbody2D.GetAttachedColliders. The attached colliders may of course be on children. There’s also the GetContacts for when you need to know about actual contacts from the last update which removes the need to rely so much on callbacks.
That would work fine, how much quadtree work do I need to do to split space up to optimise it, or will it just discard things it won’t potentially touch early on? and of course disabled colliders? I realised, I don’t know a thing about the optimisations going on with Physics2D!
Quadtrees? I am not following because I do not follow exactly what you’re trying to solve here. The colliders being Cast/Overlap just use the collider shapes as definitions so they need to be enabled (otherwise they do not have shapes) but not simulated as contacts are not relevant.
It might be worth discussing this on another thread or in a conversation rateher than here.
Great to see this roadmap, very good improvements.
Currently for my project, i heavily used Physics2D.IgnoreCollision(Collider2D, Collider2D, bool), the case is:
There’s a lot of star-ships, each ship composed by numbers of Rigidbody2D, the colliders in same ship will not collided with each other, but they will collide with other ship’s. Because the ship count may larger than 32 so i can use layer based filter, there is only Physics2D.IgnoreCollision can works, but it is not elegant(since It is not persistent, more works need to do after collider enabled/disabled etc.).
So I wondering, if there’s a collisionGroup or collisionLayer for colliders or rigidbody, each ship will has a certain group/mask id, the colliders will not collide with same id but will collide with all other which has different id. It will make things easier.
I think a method that scales beyond 32 of anything for collision control is something worthwhile, especially if the method could be used for multiple purposes. The “layer” stuff can be very limiting for physics in some scenarios but it’s also something we have to keep for backwards compatibilty.
It would also be nice if we could have something that could be multi-purpose. For instance, being able have some “named” group then be able to use as many of those as you like for collision detection, queries, simulation etc.
Not going to give out any estimates because they’re useless until the feature is at least beta quality and has been reviewed internally. As always, I’ll try to push out dev videos/images as it emerges and maybe push to experimental build if appropriate.
I am working on the low-level primitive work now though. It has most of my focus.
