Official Unity Physics Discussion

So an update:

I have managed to get the errors to go away by adding the ConvertToEntity.cs-scripture to the root gameObject, but the skinned mesh renderer still doesn't show up. Is it because it is dependent on a Transform to connect to?

So it seems I can either get the skinnedmeshrenderer to be visible, or have ragdoll joints... Please help.

 

Make sure you have the HybridRender package installed. That one got me for awhile. Without that, nothing renders.

 

It's installed. Version 0.0.1.

 

The physics samples have a ragdoll example (using Unity Physics) which might help.

 

Yes this confused me for a few minutes. The conversion system should give a warning if it attempts to convert a renderer but the package isn't present.

 

It is not using a SkinnedMeshRenderer.

 

Is it possible to get the entity that was hit from a `RaycastHit`? Also, what does the `RigidBodyIndex` represent? Would I be able to use it to get the entity (or body) that was hit?

 

in the physics samples MousePickBehaviour.cs has an example of this(getting an entity from a raycasthit)

 

Thank you thelebaron!

 

Everyone, many thanks for all your feedback and discussions so far.
We've gathered a few of the questions that have asked (since around page 4 anyway) and I'll reply in a followup to this.

First, we wanted to provide a high level roadmap of the main changes to expect in the coming months.
In terms of the core features we wanted to deliver, we are largely complete. The focus is now around validating that the fundamentals are solid, and iterating based on community feedback as well as overall DOTS development.

Specific issues to be addressed in the near term include:

• A solution for stable stacking that does not require adding extra state
  • We are currently seeing reasonable stacking on pyramids up to 5 blocks high and across a range of scales.
  • 
  • The seesaw sample is now stable and can be more complex.
  • 
  • Work is still ongoing, balancing stack stability with behavioural anomalies.
• A faster and more robust convex hull generator
  • The convex hull generator has been improved, though work is still progressing on removing unnecessary coplanar triangles.
    
  • A faster hull generator will also allow visualisation in the editor and potential runtime usecases.
• More use case examples are being worked on across the board (e.g. trigger volumes)
  • 

In the medium term:

• We continue to work on getting the Havok Physics integration ready for its first release in summer.
• Performance improvements in Unity Physics are being investigated, in many of the areas raised here in the forum (e.g. removing Complete calls to scheduled Jobs were possible)
• APIs are planned to allow a full simulation step within a single job (e.g. for predictions / mini simulations)

More details as plans allow.

 

That's all great. I'll see if I can sneak in an extra question/suggestion.

I would like to have the ability to constrain translation and rotation to particular axes, like we can with the freeze options on GO rigidbodies. I assume that this is possible today by modifying the jacobians or contacts, but it's not immediately apparent how to achieve these behaviours. A provided component would be ideal, but I'd appreciate if somebody could give a pointer or sample towards properly implementing this myself.

Forgive me if this is trivial and the proper solution is as simple as setting the transform values as desired every frame. Intuitively I would assume that this is improper, as energy would be lost doing work that I would be undoing.

In the legacy GO physics those freeze options are imperfect, as sometimes they will drift a little over time. I often only want rotation around one axis but have to zero the others each frame to prevent drift. I could obviously easily add a system to do that in DOTS, but it would be neat if the engine could handle perfectly locking transform values on some axes.

These features are particularly useful when working on projects that are a bit more 2D. I have a top down game where the objects must be 3D, but most must only rotate about Y and many must only translate in XZ.

 

Things like effectors are expected to be implemented by users since they sit on top of the core simulation. Yes it would need a system to calculate and apply a force per PhysicsVelocity component before the physics world step. The PlanetGravity sample provide you with a simple example.

Good point. We've logged this as an issue. We also want to autopopulate the values to good defaults so you don't have to think about all the values. Ultimately we want to have tools that visualize the mass properties, allowing you to manipulate them from the viewport.

We don't have an Editor level equivalent to the FreezeRotation flag currently. However, in code you can achieve the same end result by manually setting PhysicsMass.InverseInertia = float3(0) to freeze all rotation. Setting the Inverse Inertia to zero effectively makes the body have infinite mass around the zeroed axes.
You can zero out 2 axes instead, so rotation is still possible around a single axis. If doing this, please note that the inertia is offset/rotated from the entity transform by PhysicsMass.Transform.

Ideally we would like to open up the github repro. Its a discussion beyond just Unity Physics, and I'm sure Unity will provide an update on that when they can.

Breakable or deformable joints are not directly on the roadmap, as such. That said, we do need to add joint impulse reporting so your own systems can check for violations and remove the associated Joint entity (breaking the Joint), or change the Joint parameters (deforming the Joint). Expect a new Joint demo when reporting is added (though I don't have an ETA just yet). Articulations are not planned.

There is definitely scope for improvement here as it does a bunch of memory copying and building a bounding volume. If that avoided managed memory and used Burst it could be quite a bit faster. Its not a focus at the moment, so if inclined, you should be able to write a different version yourself. Our hope is that users are empowered to do such things rather than be blocked.

Sleeping is currently out of scope for Unity physics. The design pillars for Unity Physics are for it to be stateless and also simple enough for users to confidently modify to their unique needs.
Sleeping is something that feels simple on the surface but actually adds lots of complexity to a physics engine implementation, so does not fit the design goals.
A primary goal of the Havok Physics integration will exist to address the use cases where a stateful engine really does becomes necessary - such as scenes that have enough settled rigid bodies, such that sleeping the inactive ones becomes important.

Demo 2a2 has a kinematic body rotating in the air and colliding with a dynamic body. Without seeing your project, I can only suggest there are some collision filters setup to stop interaction?

Thanks for the detailed investigation. GPU instancing does need to be enabled (there was a reason it was disabled way back when!).
The FindOverlappingPairsJob does appear to be taking longer than it should, that is something we are aware of too, and plan on profiling deeper into that job in particular soon.

If a GameObject has a Physics Shape, but doesn't have a Physics Body component, then that shape may becomes part of an ancestor that does have a Physics Body, creating a compound collider. (If no ancester has a Physics Body then a static body with that shape is created)
Compound colliders currently cannot be mutated after construction. So instead, you need to add a Physics Body to the "Blade" in order to make that a separate rigid body which can be moved independantly of the "CharacterController" rigid body. Note that rigid bodies do not have a hierarchy, so you would need to set the linear and angular velocities of the blades body to appropriately move with an animation. We do expect to add samples showing animation use cases in future.

This is a little confusing but the magnitude of the Ray Direction vector is the ray length.
So Direction needs to be multiplied by distance you wish to cast out your ray, otherwise you are only checking 1 meter from the ray origin.
We need to remove this confusion and just have a Ray.Start and Ray.End (or Ray.Origin, Ray.Direction and Ray.Length) interface.

Agreed, this can be initally confusing. PhysicsVelocity.Angular is in inertia space since that is what the solver works with, while PhysicsVelocity.Linear is in world space. Note that inertia space different again to local space. Expect the ComponentExtensions to go away, but we do need to move to world space or at least provide safer utilities to map between spaces. At the very least, in the very short term, the Initial Angular Velocity property on the Physics Body component should be in world space.

 

There is not an option in the editor at the minute, but in code you can set PhysicsMass.InverseInertia[0] = PhysicsMass.InverseInertia[2] = 0; This effectively makes them have infinite mass around those 2 axes while allowing rotation around Y.

[edit] A planar joint is not there out of the box (like BallAndSocketJoint etc) but you could add you own. The bigger ECS level Joints are made up of smaller more atomic solver level constraints. And there is a Planar 1 DOF linear constraint already. I suggest copying the CreatePrismatic function in com.unity.physics\Unity.Physics\Dynamics\Joint\Physics_Joint.cs and removing the Constraint.Cylindrical call to get your own Joint to constrain your bodies translation to a plane of your choice.

 

Thanks, I've actually already done that. It feels to me like a little bit of a hack because I'm not sure that that's intuitively the right place to put that responsibility. I think of mass/inertia as being properties of the object, but the restriction I want to put in place as being a property of the simulation. This does seem to work fine for now and maybe will always be the way to do it, but conceptually I would prefer that this be modelled as a constraint that I could add to any object without messing with its mass. I view mass as the domain of the asset creator and rotation constraints as the domain of the programmer.

There's no similar way to prevent linear velocity in Y, is there?

 

Very, very nice. Happy as a sandboy TBH. Thank you very much (and all involved).

Spoiler: Stacking Hearts!

 

How about control over what is simulated or not by ourselves: If you add code to allow us to set things as static or not, we can then get something similar to sleeping but not automatic, just manual. I'd be happy with that so long as:

• have a public API call for setting one or a group of bodies to be simulated or not (this would replace sleeping)
• being able to just group up a bunch and set them from simulated to static etc

Not asking for actual automatic sleeping, but for an API that lets me just control how much work the CPU would need to do (for example treat all these bodies as being level/static for a bit).

I just want to have a few hundred bodies, but make most of them which can't be affected by gameplay be inactive until I wake them myself (proximity to player, other event).

So while sleeping might be out of scope, keeping things optimised by scaling what they can do should still be in scope... after all, it will be common enough to have a whole bunch of bodies being non-simulated for longer periods of time so some API helping to control how much work we need to do per body would be super helpful.

And ultimately probably will be better than a generic sleep scheme - and satisfy the requirement that no sleep be possible for the Unity Physics while still being a good (manual) optimisation for local not just mp physics purposes.

TLDR:

Want public API for managing sim state so we can set a whole lot of them to be dormant until we set dynamic using code. Public API because it's such a common optimisation to be able to control this, why not?

Not sleeping! not automatic, just management for optimisation purposes that we could do ourselves via a public API.

 

But this is something that already exists with Physx in Unity (Physics.Raycast behaves the same if you set length to 1 and multiply the direction vector instead) - so it shouldn't actually come as a surprise to anyone using existing Unity Physx integration.

 

I updated my original reply about constraining linear velocity. Something similar should be possible for angular constraints, though I haven't looked. Setting inverse inertia is cheaper compared to adding a constraint that would end up fighting with collision resolution. Having an editor interface with a toggle to restriction rotation would probably just set inertia values behind the scenes anyway ;-)

 

What is the equivalent of MovePosition/MoveRotation in the new system?

 

Yeah, that's why it was implemented this way. However, the question has come up a number of times now, so I would argue the interface is not transparent enough. Would you be against changing it?

 

In your case, I would do whatever is more efficient on the Physics side. Most people would probably normalise their direction or maybe their code has it normalised already, in which case it's trivial to multiply by length before feeding to Unity Physics. But if Physics has to normalise it then that's unwanted work isn't it, and not cheap either.

So please don't mind me, do the fast performing option

 

Thanks for that edit, I'm going to have a look into working out those constraints.

I'd like to make a quick defence of the point that they should be conceptually separate from the mass/inertia values.

I may want to toggle the constraints, or even to manually modify the transform in the DOFs that I've denied to the physics. I have a real world use case for toggling, where objects that have fallen out of the world should tumble and bounce physically in all DOFs as they fall, so the constraint must be removed.

If I naively modify the mass properties to reduce the DOF, I lose the original values. I would need to add a component to make note of the original inertia, and then removing the constraint would become restoring the original values. Similarly if I wanted to manually rotate it in some axis but prevent the physics from doing so, I would need to read and transform the separately stored original inertia every time I manually rotated the entity.

That would work, but feels like the wrong way to model the problem.

PhysicsMass

is no longer the source of truth. If I had other independent systems that did interesting things by reading out from

PhysicsMass

then I potentially just gave myself a headache.

What I would like to see is the addition of a component that tells the solver to pretend that inverse inertia or mass is 0 in some world space axes without having that actually reflected in the data. I believe this would give a nicer API, a more sensible data model where the stored physical properties remain correct, and better performance than modelling this behaviour with constraints.

Character controllers would be a common use case for this feature.

 

You should be able to do this yourself already. If an Entity doesn't have a PhysicsVelocity component on it, then it becomes static. So you should be able to setup a ComponentSystem to remove the PhysicsVelocity component on bodies you what to go to sleep and then add them back on if a strong enough collision is registered (or based on your own logic).
New demo to be added to the list then ;-)

 

Just setting the values in the Translation and Rotation components. However, if you are not specifically wanting to teleport, please consider setting velocities instead.
On that note, we are planning a utility function to provide appropriate velocities needed to reach a required translation and rotation within a specified timeframe.

 

UnityEngine.Physics.Raycast() has also the argument maxDistance.

 

@steveeHavok No. The problem is not related to Physics Body. But it's related to the ConvertToEntity. The children of the ConvertToEntity with ConvertAndInjectGameObject mode will not be convert to entity any more.

Code (CSharp):

1.  
2.         public static void AddRecurse(EntityManager manager, Transform transform)
3.         {
4.             GameObjectEntity.AddToEntityManager(manager, transform.gameObject);
5.            
6.             var convert = transform.GetComponent<ConvertToEntity>();
7.             if (convert != null && convert.ConversionMode == Mode.ConvertAndInjectGameObject)
8.                 return;
9.                
10.             foreach (Transform child in transform)
11.                 AddRecurse(manager, child);
12.         }
13.  

The problem is my hierarchy is like below.
CharacterController (ConvertToEntity,ConvertAndDestroy)
|-CharacterModel (ConvertToEntity,ConvertAndInjectGameObject, to use with the hybrid Animator)
--|-Blade (ConvertToEntity will not work here)

So the PhysicsShape and PhysicsBody of Blade. won't be converted to entities

 

I'm going to add the attached Angular and Linear Joints to the demo set for the next release but anyone can use them now. The attached PhysicsJointConversionSystem is tweaked to create them. This is mostly demo code in Demos>4. Joints>Scripts anyway.

The setup in the screenshot above gives me 2d style physics with movement only in the XY plane and rotation around the Z axis.

Check out Demos>5. Modify>ModifyContactJacobians for an example of tweaking the solver to pretend that inverse inertia is 0. The inertia/mass modification approach is great for car racing games to stop the vehicle spinning wildly if they graze against a side wall for example.

So I don't disagree with your thinking, but it is personal taste. Depending on the usecase, some folk will want to tweak inertias and be done with it, some will want to mess with the contact jacobians on a per object/per contact basis and some might want to constrain motion with Joints.

If the engine doesn't block you from doing what is necessary for your approach I think we are heading in the right direction.
Now does anyone, want to implement a constrain to path Joint for a VR buzzer game ;-)

 

I tested new Physics package briefly and I have some questions about Kinematic bodies. Based on this table about Physix (the one at the bottom of the page):
https://docs.unity3d.com/Manual/CollidersOverview.html
I should get Trigger events resulting form overlap of those pairs of objects:
"Kinematic Rigidbody Trigger Collider" <-> "Kinematic Rigidbody Trigger Collider"
"Kinematic Rigidbody Trigger Collider" <-> "Kinematic Rigidbody Collider"
Yet, I am not able to get any trigger events form any such setup. Once I make any of the bodies a Dynamic one it raises Trigger events. Is this a bug or will new Physics differ from PhysX in this regard?

Also I wanted to ask about performance of Kinematic rigidbodes. In my game I will have a lot of constantly moving kinematic rigidbodies that will interact with plenty of regular dynamic rigidbodies. Will this affect a performance in any significant way? Would I be better off making those kinematic bodies a dynamic ones with a very large mass so that they are not affected much by collisions?

 

Not getting events between overlapping trigger colliders sounds like a bug. We will investigate.

There is no difference in performance between a Kinematic and a massive Dynamic body. A Kinematic body simply has a

PhysicsMass.InverseMass

of 0 and a

PhysicsMass.InverseInertia

of

float3.zero

- i.e. infinitely massive.

Given there is no collision resolution on a Kinematic body, they are more likely to intrepentrate with other bodies, triggering an extra block of logic to handle that penetration. However, its not likely to be worth worrying about, especially if you have collisions between Kinematic and Static bodies filtered out anyway.

 

Splendid, thank you

 

Is there any way to access the collision filter data I set on the PhysicsShape behaviour from component data? I only found PhysicsCustomData so far..

It would be very useful to have this data accessible when I'm doing raycasts from jobs, since I could use the defined data on the objects I'm casting from (for example when raycasting from projectiles).

Edit: Nevermind! I just found the GetCollisionFilter() extension data that extracts it from the Collider blob

 

@Joachim_Ante That's what I'm asking. Refer to the sample, I can use PhysicsBody and PhysicsShape to make a Character Controller.
And the Gun the level of my hierarchy CharacterModel.
And I want to use a hybrid animator to animate blade for a trigger event to process with damage in the CharacterModel.

 

I merged those DOF joints into a single one and added support for limitations relative to another body. This would let you limit motion to an arbituary, or even dynamic, frame of reference rather than just the world. Then I tried something silly!

 

Would it be possible to get pyramid and cone shaped colliders?

 

Just create a pyramid or cone mesh and select the Convex Hull option in the PhysicsShape component.

 

I'm using the new Unity ECS Physics in my game for Movements, Collisions, bullets hit detections ...
My characters are moving using the PhysicsVelocity ComponentData but im having a strange behavior only dynamic bodies are interacting with all bodies.
kinematic bodies are walking through kinematic & static bodies, which do not make sense for me, a player walking through walls and other players.

Can you please tell me what is wrong with my game and how can i fix it ?

my game is a 2.5D TOP DOWN game which means all characters are moving only on X and Z axes, is it possible to use 2D physics with ECS ?

 

Anyone tried using an imported FBX-rig with a skeleton and a skinned mesh renderer with the new unity physics ragdoll joints and managed to make it work? I am asking again because I have tried a lot but I have no idea how to make it work due to no documentation.

 

This was already answered on the thread you made about it: kinematic objects are kinematic, not dynamic, they don't get collision responses by design. This isn't Unity Physics related issue, every physics engine works this way. To fix this, it's up to you to code the physics queries to prevent the character capsule (or whatever you use there) from penetrating into other colliders (if you use kinematic approach) or do fully dynamic rigidbody if you want physics engine to handle the collisions for you.

 

Sorry i misstated my question.
yes Now i know it's not a bug.
but im asking:
how can i prevent Players from colliding with walls and other players ?

i really have no idea how to make them push each others depending on their Forces, Angles ....
is there any easy way of doing it ?

And is there any Easy way of implementing 2D Physics on X,Z axes using ECS ?

Thank you.

 

Did you get an answer to this? Anyone?

 

i ended up by using PhysicsBody and Freezing the X,Z axes of the PhysicsMass.InverseInertia and it seems to work.

 

it will be also a great idea if we can control the axes of the 2D world, Like choosing between X,Y or X,Z.

 

I am glad that Kinematic objects are handled in a logical way. Previously, they could not have a stable velocity which was a pain.
I am not glad that there are no plans for sleeping. To me, this is a showstopper. I recognize that sleeping is quite a challenge to implement robustly (i.e. if you have stacked blocks all sleeping and one gets moved by a player setting its position), but the truth is that most games that actually use physics require some sort of sleep system.

 

I tried this and it does not work well, because it seems like my capsule has no friction. I locked the X and Y axes and the capsule just slides a lot. Did I miss something?

 

My guess is your bodies are floating slightly of the floor so there is no contact friction being applied. I suggest tweeting the limiting joint code a little to allow some minDistance tolerance, letting your capsule make contact with the ground and have friction applied.

 

Hello,
When using the new Unity physics system with ecs if I a create a sphere with a physics shape and try to cast a ray from it's translation value (so from the inside) to the outside of the sphere, the ray hits the sphere's collider and return it as the closest hit.

That was not the behaviour of the previous unity physics system.
Will the new system match this behaviour (ray don't hit backface) or is this change in behaviour on purpose ?

 

Regarding filtering, I'd like in general some way to say "ignore these specific physics bodies/colliders" on the filtering stage for both queries but also per physics bodies.

Right now the solution is to make unique physics category for each physics object you don't want to self collide but want to get hits for others. This works if you have limited amount of such objects (category amount is limited to 32 by default and you'd want to use this for other filtering as well).

Imagine you do a physics vehicle with separate kinematic colliders on each wheel but also with raycast queries for each wheel. You'd want to make the wheels colliders to not hit static objects so putting them in the same compound collider with body is no go. You also wouldn't want the raycasts hit the vehicles own wheels nor would you want the wheel collision shapes to affect the simulation of your own vehicle body but you'd still want them to respond to other vehicles collisions and queries. You probably wouldn't want to waste 30 categories for 30 simultaneously simulated vehicles to accomplish this.

For own wheels not hitting own body colliders, one could just filter them on broadphase but this could get costly perf wise.

As a hacky workaround, one could just use the same categories by default on each vehicle but swap to additional ones when there's other vehicles in close proximity but this would complicate the setup a lot in case there were bunch of vehicles in the same space.

Alternatively, I noticed that 32 categories was hardcoded amount right now, is there any issues if one could modify the max amount of categories per project? Some projects could do with noticeably less amount as well.

 

Sorry for the dumb question, but how to apply constrain a phyisic body? I'm using a prismatic joint to simulate a suspension but i dont know how to fix the rotation of the body..
Also, is there a way to add force proportional to connected body movement?

 

https://docs.unity3d.com/Packages/com.unity.physics@0.0/manual/collision_queries.html#filtering
Filtering out individual pairings can get quite expensive. There is a second option for the CollisionFilter that is currently not exposed at Editor setup time through the PhysicsShape at the minute. The

CollisionFilter

struct also has the

GroupIndex

option which is great for ragdolls, vehicles or other associated set of bodies that should not collide with each other. e.g. if all the bodies in a ragdoll have a

GroupIndex

of -N then they won't collide with each other. Would this cover your usecase?

Note: we will also change the name of the CategoryBits and MaskBits member varibles to match the BelongsTo and CollidesWith labels exposed in the editor.