Official 2D Physics : Manual Simulation, Simulation Groups & Multiple Worlds

MelvMay · Apr 14, 2018

I just don't follow what you're saying and it seems to be going in circles. I also have no idea what you mean when you say "nothing goes wrong".

If Time.deltaTime and Time.fixedDeltaTimeare identical then it'll enter the loop each and every time only once as it checks >=.

Why not just try this yourself rather than trying to convince me this doesn't work. Also, for the final time; please post on another thread. You've effectively took over this thread for your own purposes.

Thanks.

Deeeds · Apr 14, 2018

Why don't I try it?

LOVE TO!!!

But where/how do I set fixedDeltaTime independent of the cycle rate of FixedUpdate() ?

They seem to be the same thing, but without control of which is first. It seems impossible to know if the FixedUpdate is called before the manual simulation, or after it.

MelvMay · Apr 16, 2018

All this information I have provided to you already in the links above showing you how to set the time and what the order is for the MonoBehaviour callbacks etc.

any_user · Apr 16, 2018

Going back to the original topic of this – I'd be very interested in multiple 2d physics worlds.

In a game we're working on, we're using cavalier perspective. There is a ground plane at which we look from a 45° angle, and there are vertical planes that are aligned to the camera. We use 2d physics for the ground plane. So circles on the ground turn into ellipses etc. Sprites "standing" on the ground are rendered completely flat because they are aligned to the camera (like billboards, but they can still be rotated on the vertical axis).

There are some scenes, in which we would like to use 2d physics on some of these vertical "sprite-planes" in addition to the normal ground physics. Right now that's very complicated to do, the only easy way is to either use ground physics or sprite-plane-physics for one of these sprites. Or we could simulate it somewhere on the ground plane and then project it to the visible plane, but that seems very cumbersome. For this it would be very useful to have small 2d physics worlds, one for each 2d object that uses physics in local space.

Is that a use case that would be supported with your approach of having multiple worlds?

MelvMay · Apr 16, 2018

This feature will be going into 2018.3 and is pretty much complete already. Your scenario will be possible with the feature.

any_user · Apr 16, 2018

Great to hear, thanks!

jollyblade · Apr 23, 2018

Hey Guys,

It's a really good thread, but I still have some questions about how to organise some things, and why things are so as described here.

First of all, why is the Simulate called in the Update?
Why is it not just in the FixedUpdate()? Am I missing some info?

Like this:
void FixedUpdate(){
// apply input, and then
Physics2D.Simulate(fixedTimeStep);
// do anything else with the results
}

I need this to be able to re apply input, for local prediction, from an earlier state.

What I do:

I set the rigidBody properties to the latest available from the server, then I take my input from my buffer, and reapply the remaining. However it does not really work, and I don't understand why.

What I do:

void FixedUpdate ()
{

reset each networked rigidbody to acked state from server
// everything else is kinematik atm

for each input > acked input
{
apply Input; // add forces, torque, etc
simulate(fixedDeltaTime); // do a simulation step for the given input
}
}

But this unfortunately does not work, and I don't really understand why. It seems that either the reset breaks something, or doing multiple simulate calls in one fixed update is basically bad.

If there are 3 - 5 not acked inputs in the queue, they all have to re simulated and applied onto the last result from the server, meaning that in one fixed frame all the inputs needs to be simulated.

Or not? what do you think? How is it done properly?

Thank you very much.

chesiq · May 25, 2018

Hi,
Thank you for creating this thread!

I'm currently developing a game a lot like Heat Signature.
It's in 2D, the view is top down, you are able to control a char that is able to walk around, build and fly spaceships.

The solution I'm using is a hack ( parenting empty object with player child(with a rigid body) to the ship with a rigid body).

The problem I'm having is low max usable speed of ships. I can walk on spaceships that are slower than 15 - 20m\s (unity meter per second) and if set higher - player starts to hit lagging behind walls and is able to glitch through the ship walls.

I need to be able to walk on fast moving ships - like in Heat Signature; as well as use projectile weapons inside fast-moving ships.

Is there a current possible solution? Maybe making physics deterministic so that walls do not lag behind their visual representations by locking fixed update to the framerate?

From what I was able to find out games like Star Citizen use multiple physics simulations, I wonder when will be seeing this feature? And if so, will it solve my problems?

I read about different cheat like approaches like making ships stationary and only moving the world around, but then you are fighting other ships that also have players on them... so I don't want to try out other solutions that I will regret further when implementing multiplayer.

Thank you in advance.

foxnne · Jul 27, 2018

jollyblade said: ↑

Hey Guys,

It's a really good thread, but I still have some questions about how to organise some things, and why things are so as described here.

First of all, why is the Simulate called in the Update?
Why is it not just in the FixedUpdate()? Am I missing some info?

Like this:
void FixedUpdate(){
// apply input, and then
Physics2D.Simulate(fixedTimeStep);
// do anything else with the results
}

I need this to be able to re apply input, for local prediction, from an earlier state.

What I do:

I set the rigidBody properties to the latest available from the server, then I take my input from my buffer, and reapply the remaining. However it does not really work, and I don't understand why.

What I do:

void FixedUpdate ()
{

reset each networked rigidbody to acked state from server
// everything else is kinematik atm

for each input > acked input
{
apply Input; // add forces, torque, etc
simulate(fixedDeltaTime); // do a simulation step for the given input
}
}

But this unfortunately does not work, and I don't really understand why. It seems that either the reset breaks something, or doing multiple simulate calls in one fixed update is basically bad.

If there are 3 - 5 not acked inputs in the queue, they all have to re simulated and applied onto the last result from the server, meaning that in one fixed frame all the inputs needs to be simulated.

Or not? what do you think? How is it done properly?

Thank you very much.
Click to expand...

This is exactly the problem I'm facing. Basically at the moment, unless I've missed something, the only option is to create your own collision solver using casts or overlaps, which is harder than it seemed given the data available from those casts or overlaps. Doing this, you can call your move method to process input whenever you like.

However, making it behave in many conditions (circle character controller moving into a small space between two boxes, or similar) is hard to solve in an efficient way. I've been researching Speculative Contacts to try to build something that works but it's difficult to shove that type of system into Unity. If anyone has information on that, I'd love to see it.

The 3D character controller component does this, i think. At least it works in the same way. It can be used in place at the moment, but that means not using 2D colliders which is annoying.

I've been battling this for a long time now, each time I try to make a better system but it never quite gets there. I would absolutely love some specific information on if it's currently possible to implement client side prediction using unity physics in some way (simulating multiple inputs in a single frame).

Hopefully what I read above is that you could either put all currently moving bodies in a seperate world and simulate thoseton demand or something, coming in 2018.3. Still, I hope it's possible to simulate multiple times within a single frame (even just one single collider) .

Is there any information on whether that will be possible in the near future?

rxmarccall · Aug 22, 2018

@MelvMay
Will the simulation groups be included in Unity 2018.3?

I'm working on netcode and am trying to simulate each individual player Rigidbody2d one at a time....
Currently I'm setting all other player Rigidbody2d's to "isKinematic" and then simulating physics just for that player and then moving on to the next player.

Is this an appropriate way to simulate only specific Rigidbody2d's at a time?
I'm running into an issue where the physics simulation seems to run 2x as fast once I have 2 players in the game, so I'm assuming somehow I'm running the physics step 2x as much as needed. For that reason I'm asking about physics groups as I think it'd help me out!

Thanks

wongagame · Sep 10, 2018

HI

my one query i am develop flip poker card animation. i'm used fliping book page project.
i'm develop poker card animation but no idea so plz help me.
i'm create fore card animation but card drag and other three card not proper working.

– reference pokerrr 2 card show animation
– reference link :

Plz help me.

Thank You !!

impbox · Oct 9, 2018

Hi @MelvMay, I see unity 2018.3.0b3 says it includes support for per scene physics and there is now a PhysicsScene2D in the docs, however I can't see any mention of how to set up a new PhysicsScene2D. Is this now supported?

Thanks!

Singtaa · Dec 28, 2018

impbox said: ↑

Hi @MelvMay, I see unity 2018.3.0b3 says it includes support for per scene physics and there is now a PhysicsScene2D in the docs, however I can't see any mention of how to set up a new PhysicsScene2D. Is this now supported?

Thanks!
Click to expand...

You need to set LocalPhysicsMode when creating/loading the scene.

https://docs.unity3d.com/2018.3/Documentation/ScriptReference/SceneManagement.LocalPhysicsMode.html

HaTi13 · Apr 8, 2019

MelvMay said: ↑

Let me start by saying what I'd like to get out of this thread before going any further; constructive feedback on the thread topic, good use-cases for them, creative ideas on how to ideally expose stuff via components/API etc. What I'd like for you to get out of this is the ability to make real changes in what's coming. I know that sounds like an empty promise but it's true; whilst we already have many sources of use-cases, now is the time for good implementation ideas.

So I'm Melv May and I'm responsible for the implementation of 2D physics in Unity (I'll say "Physics" from now on). I've potentially been the source of delight and frustration for physics for you. It's the Easter break here in the UK but my mind is squarely focused on physics for 2017. Indeed, early next week there'll be a big update to the Unity RoadMap for physics which'll cover a huge range of features and improvements. Some are "planned" and some are research only.

For now though, I'd like to get some feedback on a few select topics and I intend to create more on other topics soon. This is more than a wall-o-text though and for the impatient amongst you, there's a custom build avaiable here that contains implementation for some of the discussion below!

So the topic for today is three things that have some overlap:

Manual Simulation

Simulation Groups

Multiple Worlds

have you video about this?

Manual Simulation
So as you know, Unity already performs a physics simulation during the fixed update. Technically, during the fixed update, all the FixedUpdate functions in your scripts are called first. When that's done, the physics simulation is run followed by Unity performing all physics callbacks. I'm going to ignore the fact that Unity can actually perform the physics simulation several times if it needs to catch up with real time but yes, this happens. After the fixed update, we're into frame rendering i.e. Update callbacks etc.

One of the problems with the above is that there is no LateFixedUpdate which means it can be a pain to gather results from the physics simulation unless you wait until the next FixedUpdate.

So, I went ahead and implemented the ability to turn-off the automatic simulation of physics using:

Code (CSharp):

Physics2D.autoSimulation = false;

With this done, physics will not automatically update during FixedUpdate. This leaves it open for you to update the physics yourself using:

Code (CSharp):

Physics2D.Simulate(Time.fixedDeltaTime);

This means that you can now update the physics whenever you like. It also means you can potentially read the results of the simulation immediately after the call.

To duplicate exactly how the physics simulation is called, you could now do the following:

Code (CSharp):

using UnityEngine;

public class BasicSimulation : MonoBehaviour

{

private float timer;

void Update()

{

if (Physics2D.autoSimulation)

return; // do nothing if the automatic simulation is enabled

timer += Time.deltaTime;

// Catch up with the game time.

// Advance the physics simulation in portions of Time.fixedDeltaTime

// Note that generally, we don't want to pass variable delta to Simulate as that leads to unstable results.

while (timer >= Time.fixedDeltaTime)

{

timer -= Time.fixedDeltaTime;

Physics2D.Simulate(Time.fixedDeltaTime);

}

// Here you can access the transforms state right after the simulation, if needed...

}

}

For those interested, almost identical functionality has been added to 3D physics and you can find the discussion here although I'd like if it you'd keep 2D physics discussion here if possible. Don't worry though, I'll share discussions with Anthony (the owner that thread).

The manual simulation feature for both 2D & 3D physics is landing in 2017.1b. We feel that this is the basis for lower levels of control and isn't going to change much.

Simulation Groups
With the ability to manually simulate physics, there's an opportunity to perform partial simulations i.e. only a selection of all Rigidbody2D. There are several ways to achieve this, the problem being that supporting all of them could lead to a messy API so it'd love to get some feedback on this.

Here's some potential ways to perform partial scene simulation:

Layer-based - "Physics2D.Simulate(time, layerMask)"

Selected-based - "Physics2D.Simulate(time, Rigidbody2D[] bodies)"

Group-based - "Physics2D.Simulate(time, groupMask)"

Others? Please tell!

The obvious one would be to use layers; they are integrated into the UI, are named and have existing meaning to physics. This would work and is probably intuitive to some degree however there are some oddities here; the layer is against the GameObject and not the Rigidbody2D. This means child Collider2D can be on separate layers. This makes partial scene simulation potentially confusing because partial scene simulation is against Rigidbody2D (bodies) and not Collider2D. We will never only simulate a specific Collider2D as they are not simulated, they only produce contacts from simulating Rigidbody2D. So layers would make sense as long as it was understood that it was the layer of the Rigidbody2D only. Finally, restricting partial scene simulation to layers then adds another meaning to layers which I feel would be overly restrictive in some use-cases.

The next choice is to allow a physics simulation of an array of Rigidbody2D. Here there is no confusion over what will be simulated. I feel that this is a good choice for some use-cases however whenever I see this I start to feel that in some cases, compiling and maintaining this list/array could become cumbersome. It does have the advantage however that you are not limited by any existing mechanism on what gets updated.

The next choice is to provide a dedicated property on Rigidbody2D for this. This solves the potentially confusing aspect of layers for Collider2D above. With the ability to specify a Rigidbody2D.simulationGroup = (0-31) you'd be able to associate a simulation group with some logical aspect of your game and keep it apart from the collision layer mechanism. This means you can manually update the physics simulation for some or all simulation groups. Simulation groups have no name (for now) but that could be added if and only if this were applied to both 2D and 3D physics alike. Simulation groups also allows turning on/off whole groups of simulation even while using automatically physics updates with "Physics2D.simulationGroupMask = <mask>" which is used if you do not specify a simulation group mask when manuallly updating physics or if automatic physics updates are on.

This would look like this.

This would allow you to perform manual updates on selective simulation groups like this:

Code (CSharp):

using UnityEngine;

public class GroupSimulation : MonoBehaviour

{

// Create 32 simulation groups.

public bool[] m_SimulationGroups = new bool[32];

private int simulationGroupMask;

private float timer;

void Update()

{

// Do nothing if the automatic simulation is enabled.

if (Physics2D.autoSimulation)

return;

timer += Time.deltaTime;

// Catch up with the game time.

// Advance the physics simulation in portions of Time.fixedDeltaTime

// Note that generally, we don't want to pass variable delta to Simulate as that leads to unstable results.

while (timer >= Time.fixedDeltaTime)

{

timer -= Time.fixedDeltaTime;

Physics2D.Simulate(Time.fixedDeltaTime, simulationGroupMask);

}

}

// Calculate the simulation group mask.

private void OnValidate()

{

simulationGroupMask = 0;

int i = 0;

foreach (var group in m_SimulationGroups)

{

if (group)

simulationGroupMask |= (1 << i);

++i;

}

}

}

Experiments!
So as I mentioned above, the ability to manually update physics is going into 2017.1.0b soon. On top of this, I've implemented the "simulation groups" option above as an experiment on top of that. Right now, the simulation groups are a 32-bit bitmask which is both fast and easy to implement. It's possible to allow an unlimited number of bits but that incurs extra cost but isn't prohibitive. Right now, it's just a quick experiment.

The good news is that this is now available as a one-off custom build here.

I also made some posts on Twitter if you do that kind of thing:
https://twitter.com/melvmay/status/852440222348578817
https://twitter.com/melvmay/status/852915614570209280
So right now, manually simulating physics outside of play-mode in the editor isn't allowed however I'll soon allow that. Do not forget to install this into a separate folder. Also note that whilst it's badged as 2017.1.0b2, it isn't that release, it's just partially based upon that and certainly should not be used for production. You have been warned.

Beyond that, I'd love for you to download it, experiment with it and discuss!

Multiple Worlds
So I decided to include this alongside manual physics simulation as I believe there are many overlapping use-cases.

Right now, we offer a single physics world. Everything is exposed as components that automatically create the low-level physics objects for the implicit single world we create when Unity starts. This is simple and in most cases, all that is required however it isn't perfect and does not help when you want to start doing more advanced stuff.

Rather than state all the known use-cases for multiple words such as isolation, prediction etc, I'll skip that and go ahead and discuss how that feature might emerge but more importantly, involve you in the problems in exposing it.

So right away, we have a few problems with the notion of multiple worlds. It's not a problem creating these worlds, more a problem of "fitting" them into the existing API and component-based setup.

The first problem are components; when you create a Rigidbody2D, Collider2D or Joint2D, it's created within the default world. If we were to expose the ability to add multiple worlds, we'd have a problem with these components as we wouldn't know which world to create them in. Sure, we could expose a property on each that allows you to change it but that would mean creating it in the default world, you changing the world then it being deleted and recreated. This is crazy wasteful. Changing the generate "AddComponent<T>()" to take a physics world wouldn't fit correctly and just isn't an option.

We could make the world itself a factory for components by adding specific factory methods like world.AddRigidbody(gameObject), world.AddCollider2D(gameObject) etc but it's an ugly syntax.

When a GameObject is disabled, we do not create the underlying physics objects so it's possible to assign the associated world with the component before the GameObject is enabled but being forced to do this with the only alternative being creating by default in one world to then have to change it is not good.

Another problem is persistence. If we were to create a component associated with a world and that component was persisted in the scene or part of a prefab then that requires the world to do the same. This means that worlds cannot be freestanding and must be part of a global setup saved with the main Physics2D state for the project.

Another problem is with the existing Physics2D type. This is a static type that allows you to both change the settings of the default world and perform physics queries on it. Changing every single query to allow a world instance arg is a lot of work and leads to lot of overloads and potentially confusion. The existing settings would have to be deprecated and moved to some world instance.

Another issue is callbacks; when you had a callback, the callback signature does not tell you which world. This can be easily worked around by exposing the world instance on the Rigidbody2D & Collider2D.

One solution is to allow context switching i.e. the ability to select a world instance as the current context. This means you have a physics world object and select it as the current context. Then, any new components added or physics queries issued relate to that physics world in context only. This isn't perfect but does solve several issues. A real downside here is that it can lead to subtle bugs in scripts where the context isn't set so the last set context is used. These would be hard to track down.

Another solution is to ignore Physics2D and all existing components completely! This would mean exposing managed types that allow creating a world, body, collider & joint primitives. Indeed, work this year that'll appear on the road-map is to expose lower level primitive shapes for colliders that represent an almost 1:1 of what physics actually uses at a low-level. The downside here is that you'll only have multiple worlds as a script-only feature with no components or the ability to use effectors etc. A problem with this is that these would require their own callbacks as they could not use existing ones as they are clearly based upon Rigidbody2D and Collider2D components.

Conclusion
Enough text already!

So I would really appreciate thoughts on this. If you could focus on these topics only, it would also be appreciated. If you would desperately like to discuss another feature request then reach out to me and I'd be happy to start another thread.
Click to expand...

impbox · May 16, 2019

Creepgin said: ↑

You need to set LocalPhysicsMode when creating/loading the scene.

https://docs.unity3d.com/2018.3/Documentation/ScriptReference/SceneManagement.LocalPhysicsMode.html
Click to expand...

Ok, once i've done that I get a "Scene" from CreateScene passing LocalPhysicsMode.Physics2D, but this doesn't give me a PhysicsScene2D object/struct, how do I find the PhysicsScene2D of my new Scene?

Thanks.

MelvMay · May 16, 2019

Use these: https://docs.unity3d.com/2018.3/Documentation/ScriptReference/30_search.html?q=getphysicsscene

Note if you just search "PhysicsScene" in the docs it gives you everything related to it.

MrHaribo · May 27, 2019

Hello @MelvMay

I am working on a 2D Multiplayer Game in Unity. It absolutely needs an authoritative server so i am stuck with implementing server side physics with client-side prediction wich requires some kind of way to rewind and replay different Ridigbody2D individually.

I Stumbled on the thread https://forum.unity.com/threads/2d-...ion-simulation-groups-multiple-worlds.466501/ about different simulation groups to simulate rigidbodies individually which could greatly help with rewind and replay.

My question is, how is the progress on simulation groups? Is there an experimental build for Unity 2019 i could use wich has the feature enabled?

My current approach is to enable/disable all Ridigbodies but one, but this approach seems poor and so look the results. Do you have another idea how i could Simulate Ridigbody2D individually? Is it possible to set the Property Rigidbody2D.simulated to false to simulate rigidbodies individually?

Thanks for your reply in advance.

MelvMay · May 27, 2019

MrHaribo said: ↑

My question is, how is the progress on simulation groups? Is there an experimental build for Unity 2019 i could use wich has the feature enabled?
Click to expand...

No work has been done on it.

MrHaribo said: ↑

My current approach is to enable/disable all Ridigbodies but one, but this approach seems poor and so look the results. Do you have another idea how i could Simulate Ridigbody2D individually? Is it possible to set the Property Rigidbody2D.simulated to false to simulate rigidbodies individually?
Click to expand...

There's no way to simulate a single Rigidbody2D and it would be pretty expensive to go through a whole simulation step per Rigidbody2D. Maybe you can just control the body using physics queries and move it kinematically. That way you have full control over how it moves and where it ends up.

MrHaribo · May 27, 2019

MelvMay said: ↑

No work has been done on it.

There's no way to simulate a single Rigidbody2D and it would be pretty expensive to go through a whole simulation step per Rigidbody2D. Maybe you can just control the body using physics queries and move it kinematically. That way you have full control over how it moves and where it ends up.
Click to expand...

Thanx for your quick reply.

My game has rather simple physics so i hope it will not be to complicated to resolve collisions manually. I hope that i can rely on Trigger Callbacks for collision detection.

impbox · Aug 27, 2019

Thanks for the help so far, I've managed to get multiple physicsScene2D's simulating separately, however for performance I'd like them to run in parallel rather than in sequence. I've enabled "Use Multithreading" in Physics2D Settings. However when attempting to simulate inside a IJobParallelFor

Code (CSharp):

UnityException: IsValid_Internal can only be called from the main thread.

Constructors and field initializers will be executed from the loading thread when loading a scene.

Don't use this function in the constructor or field initializers, instead move initialization code to the Awake or Start function.

UnityEngine.PhysicsScene2D.IsValid_Internal (UnityEngine.PhysicsScene2D physicsScene) <0x14485d04ad0 + 0x00052> in <b8f5f0ad853f4c859c01e6abc87868f0>:0

UnityEngine.PhysicsScene2D.IsValid () (at C:/buildslave/unity/build/Modules/Physics2D/ScriptBindings/Physics2D.bindings.cs:39)

UnityEngine.PhysicsScene2D.Simulate (System.Single step) (at C:/buildslave/unity/build/Modules/Physics2D/ScriptBindings/Physics2D.bindings.cs:59)

GameManager+PhysicsJob.Execute (System.Int32 i) (at Assets/Scripts/GameManager.cs:1167)

Unity.Jobs.IJobParallelForExtensions+ParallelForJobStruct`1[T].Execute (T& jobData, System.IntPtr additionalPtr, System.IntPtr bufferRangePatchData, Unity.Jobs.LowLevel.Unsafe.JobRanges& ranges, System.Int32 jobIndex) (at C:/buildslave/unity/build/Runtime/Jobs/Managed/IJobParallelFor.cs:43)

Is there a way to Simulate multiple PhysicsScene2Ds in parallel?

MelvMay · Aug 27, 2019

impbox said: ↑

I've enabled "Use Multithreading" in Physics2D Settings.
Click to expand...

That means when you call simulate either explicitly or Unity calls it automatically then it goes wide across all cores. It does not allow you to perform multiple simulations in parallel from a C# job. This is mostly because of the main-thread actions it needs to do such as performing script callbacks etc.

impbox · Aug 28, 2019

MelvMay said: ↑

That means when you call simulate either explicitly or Unity calls it automatically then it goes wide across all cores. It does not allow you to perform multiple simulations in parallel from a C# job. This is mostly because of the main-thread actions it needs to do such as performing script callbacks etc.
Click to expand...

Thanks. I see, does that mean it's impossible to do parallel 2d physics simulations in Unity as of now, or is there another way to do this?

MelvMay · Aug 28, 2019

impbox said: ↑

does that mean it's impossible to do parallel 2d physics simulations in Unity as of now
Click to expand...

It can't be done for now and the only way I can think of is to place your different physics objects in separate scenes but separate them spatially and use additive loading to merge them into one big scene which you can simulate using all the cores.

impbox · Sep 2, 2019

MelvMay said: ↑

It can't be done for now and the only way I can think of is to place your different physics objects in separate scenes but separate them spatially and use additive loading to merge them into one big scene which you can simulate using all the cores.
Click to expand...

Ok! Thanks for confirming!

Warthong · Sep 7, 2020

Hi @MelvMay, I noticed this on the Unity Roadmap under development. I have been hoping that the simulation group feature would be added to Unity for a few years now. I have been silently watching the progress. Can you give an update? My game could really use this feature:

To comment on your original post, what I would like to see is the ability to define a group and then to be able to specify if an object is included in that group. This should not be limited to 32 groups ideally. It would be great if a property could be exposed in the RigidBody2D that would allow you to choose one or more groups that that GameObject is part of. To be able to access this in script or the inspector would be great.

My particular use case is this:
1. Character can move in the xy plane.
2. When dead I would like to the character to ragdoll on a local ground collider that is at the base of its feet.
3. No other character, including other prefab instances of that character should be able to fall on that local ground collider. Each prefab instance should have it's own local ground collider and it needs to be exclusive to that instance.

If you have anything in the works I would love to try it out. I have a crappy solution based on Physics2D.ignoreCollision that I use right now, it works but it's bad because for every new prefab instance that is created I have to tell the new prefab that it can collide with its own ground but then find all of the other ground objects and tell it that it can't collide with any of the other previously made instances.

Search Unity

Official 2D Physics : Manual Simulation, Simulation Groups & Multiple Worlds

MelvMay

Unity Technologies

Deeeds

MelvMay

Unity Technologies

any_user

MelvMay

Unity Technologies

any_user

jollyblade

chesiq

foxnne

rxmarccall

wongagame

impbox

Singtaa

HaTi13

impbox

MelvMay

Unity Technologies

MrHaribo

MelvMay

Unity Technologies

MrHaribo

impbox

MelvMay

Unity Technologies

impbox

MelvMay

Unity Technologies

impbox

Warthong

Search Unity

Unity ID

Useful Searches

Official 2D Physics : Manual Simulation, Simulation Groups & Multiple Worlds

Unity Technologies

Unity Technologies

Unity Technologies

Unity Technologies

Unity Technologies

Unity Technologies

Unity Technologies