Official Unity Physics Discussion

Some joints are yes.

 

Joints are available in the runtime. The Editor/Setup side hasn't been locked down in the package, though the samples do have some initial editors you could copy into your own project (see https://github.com/Unity-Technologi...PhysicsSamples/Assets/Demos/4. Joints/Scripts).
Check out the "4a. Joints Parade" sample for all of the Joint types.

There is no out of the box wheel Joint. However, the higher level Joints (e.g. Ball and Socket, Limited Hinge etc.) are all made up from lower level, atomic linear and angular constraints. These can be combined to makeup whatever joint you might need (e.g. see the script for the Limit DOF Joint in the samples)

The Joint Parade demo does have a chain of boxes connected with limited hinges like a rope. (Note that the chain is setup in a hierarchy for the entity conversion system, ensuring parent entities are converted first). However, I don't recommend a chain of rigid bodies for a rope (unless you already know what you are doing and have a very specific need for full rope interaction). For a rope behaviour, I would recommend instead using a single 'Stiff Spring Joint' as shown in the 'ConnectedToWorld' object in the Joint Parade demo. You can set a max/min distance to get a rope behavior and this will do the main work of holding a heavy object. The rope body then could be a chain of bodies if necessary but it would be much cheaper to implement a simple graphics only, verlet simulation for the rope itself.

 

If you copy the Character Controller scripts (CharacterControllerAuthoring & CharacterControllerUtilities) into your own project, you shouldn't really have to do much to hook it up. The only real work you should need to do is add the CharacterControllerAuthoring component to a kinematic physics body and implement your own input system (i.e. replace CharacterControllerOneToManyInputSystem). You shouldn't have to dig into the code details if not comfortable.

The CharacterController is going to be somewhat refactored to separate the input system and the core CC simulation loop a little more, making the integration into your project easier. The core simulation loop will also likely be added as extension in to the Unity Physics package as well meaning you won't need to copy any scripts.

There are a few bugs still in the CC but if you can elaborate on what you mean when you say it "doesn't [feel] super good when you take control", that would be really useful.

If you want a really really simple character controller, there used to be a very scrappy implementation in the samples that just pushed a sphere around with velocities. I believe this is still available in the sample repo if you checkout an older version (e.g. https://github.com/Unity-Technologi...mmit/c50af1872c992c740b437c187d88054468799fd1)

 

This will depend on the setup and how hard you need the Joints. There isn't the equivalent of the Articulation (featherstone) joints in Unity Physics for example. However, there are a few things that can help any constrained system (like ramping up the simulation iteration count - see PhysicsStep component) or building up you own higher level Joint from your own set of atomic Constraint elements (see Limit DOF Joint script code).

 

Articulation (featherstone) solution would probably require JobDependencies too, if I understand ECS correctly

Thanks for pointers, stevee

 

The Havok talk from Unite was posted yesterday but has now gone private. Is it coming back?

 

You mean this one?

 

No, there was one up by @steveeHavok about Havok physics specifically. I have watched it yesterday.

 

Ooooh a secret Havok talk! Can't wait : popcorn :

 

I don't remember saying anything that was NSFW
I understand that the Unity team are working on getting the talk back up publicly.

 

Oh come on! It was pure physics-porn!

 

Maybe the footage of other games tripped a content bot flag?

 

So if I want the movement of the objects on which I apply the impulse to feel the same on different devices should I use Time.fixedDeltaTime or Time.deltaTime?

Edit: Just to be more specific on what I'm trying to achieve:
I use a 'sling shot' mechanism to move objects around the play zone where the 'strength' of the shot is calculated by how far you drag your mouse from an initial position. I would like my objects to travel the same amount of space on different devices (not more on powerful devices and less on less capable ones). Do I need to multiply the deltaTime with the 'strength' of the shot in this case? If so, which one ... fixed or simple deltaTime (my guess is yes, and simple in order to achieve good results on both 30/60 fps devices).

Edit 2: If this is considered out of topic on this thread I found another one with a similar question here:
https://forum.unity.com/threads/moving-a-physics-object-smoothly.740615/

Edit3:
Some code as well:

Code (CSharp):

1. float strength = forceMul;
2. float3 dir = MouseStartPosition - MouseEndPosition;
3. float dist2 = lengthsq(dir);
4. dir = normalizesafe(dir);
5. strength *= dT * dist2;
6.  
7. ComponentExtensions.ApplyImpulse(ref bodyVelocity, bodyMass, translation, rotation, strength * dir, hit.Position);

This is what I'm doing now. forceMul is just a float that I can set manually. I read a previous advice of yours to follow the FoceField sample and I tried to adapt to my needs

 

Please, make good CC fo DOTS like Kinematic Character Controller. I cant live another 10 years without good CC in Unity.

 

You might like this comment from the author of Kinematic Character Controller : https://forum.unity.com/threads/unity-physics-discussion.646486/page-10#post-4606162

 

Yep, this one is quite delightful

 

Hi,In CharacterControllerUtilities.cs line 415:

Code (CSharp):

1.  
2.         if (newConstraint.Plane.Distance < 0.0f)
3.         {
4.             // Disable penetration recovery for the original plane
5.             constraint.Plane.Distance = 0.0f;
6.  
7.             // Set the new constraint velocity
8.             float3 newVel = newConstraint.Velocity - newConstraint.Plane.Normal * newConstraint.Plane.Distance;
9.             newConstraint.Velocity = newVel;
10.         }
11.  
12.         // Prepare velocity to resolve penetration
13.         ResolveConstraintPenetration(ref newConstraint);
14.  

Is it do the same thing here?

 

TLDR; if your simulation needs are fine with a variable timestep use Nothke's realtime hack and multiply your impulse by deltaTime. if you need a more stable physics timestep TLDR's don't work!

Physics simulation generally prefers a fixed time step. Constraints are less likely to swing widely and over, or under, compensate for violations. Hence, Unity Physics currently steps every frame, with a time step coming from Time.fixedDeltaTime (which defaults to 50hz). The game loop (including the rendering) may be stepping at any time delta (unless vsync is enabled). So, on more powerful platforms you could be getting 100 frames per second, meaning that the physics simulation will be moving bodies twice as far as they should be each frame. On a less powerful platform you could be getting 30 frames per second, so physics won't be moving bodies far enough each frame.
If you need a more stable simulation e.g. you have lots of joints, then you need to use fixed time steps and you need to handle the time difference between the Graphics and Physics update. The good Unity folk are looking into supporting this in a clean way, by handling interpolation between simulation and presentation groups. I'll leave them to comment on the progress there.
If you are only throwing a ball around a mostly static environment, you may get away with the TLDR option above.

 

Yup, setting newVel is indeed redundant. There are a bit of a refactor going on in the CC and this will be fixed. You can comment out the newVel lines if you wish, but there is now current harm in leaving them.

 

Loving havok physics after playing around with it after your talk. was just wondering if soft body and cloth physics effects were coming down the line, or if it's just going to stay core stuff for awhile? Would really love to keep everything in ecs world all interacting with each other.

 

A few folk have experiemented with simple cloth systems in DOTS. I don't know the details though (probably a simple verlet system) and I don't believe it was related to Unity Physics.
Unity & Havok Physics is focused on 3d rigid body dynamics at its core, but it should be open enough for extensions, or modular enough for you to use piece meal. For example, the raycast queries are very fast if you wanted to add collision response to a verlet particle system. Or contact modification could be used to make bodies a little less rigid.
Did you have a particular usecase for cloth or soft bodies in mind?

 

Hiyas, has there been a pass on optimization for Unity.Physics.MeshCollider.Create yet? Just wondering before I have another go at using it.

Cheers,

Alia

 

I receive error after upgrade to Unity 2020.1a, Unity Physics 0.2.4
error CS0200: Property or indexer 'BoxCollider.Size' cannot be assigned to -- it is read only
It worked in 2018.2

Code (CSharp):

1. Unity.Physics.BoxCollider* scPtr = (Unity.Physics.BoxCollider*) physicsColliders [i].ColliderPtr ;
2. scPtr->Size = applyScale ;

Basically Size is read only. Unable to set it anymore.

Any thought on solving that issue?

Edit:

Code (CSharp):

1. Unity.Physics.BoxGeometry geometry = scPtr->Geometry ;
2. geometry.Size = applyScale ;

I think that is the way?

 

Did you know that you can actually build colliders in jobs? If you wrap the BlobAssetReference<Collider> in a NativeArray. It's not super fast for a mesh collider, but at least you can do it off the main thread.

Code (CSharp):

1. [BurstCompile]
2. public struct MakeMeshColliderJob : IJob
3. {
4.     [ReadOnly] public NativeArray<float3> vertices;
5.     [ReadOnly] public NativeArray<int> indices;
6.     [WriteOnly] public NativeArray<BlobAssetReference<Collider>> wrappedCollider;
7.  
8.     public void Execute()
9.     {
10.         wrappedCollider[0] = MeshCollider.Create(vertices, indices);
11.     }
12. }

Example with unity capsule:



Maybe that doesn't answer your question, but I was really happy when I realized you can do that because the main pain of classic unity physics is not how slow it was, but that it just blocks everything else, there was no way to offload baking process from the main thread.

 

Yup, you also need to assign the new geometry back to the collider. The '5b. Change Collider Size' demo shows this sort of thing. The reason for this is that the changes are tracked, updating the version of the collider so other systems (e.g. Havok Physics) know something changed.

 

Oh, ok I will look more into it soonish. This may be the reason, my collider don't scale correctly anymore, after moving to Unity 2020. I just modified size bit in the code. If I won't forget I will report back.

 

I read through most of it, this thread is becomming quite big - but I still have a question:
Is it possible to use havok-physics with a MonoBehaviour-World?
So I keep most of the game logic as MonoBehaviours like weapon switching, playing animations, opening doors... and use DOTS only for the physics calculation (and rendering?).
Basically it should be possible, I guess, by syncing:
Entity-Position ---to---> PlayerPosition
PlayerWantedVelocity ---to---> Entity-Velocity (dynamic physics body)

So I "just" use DOTS for Physics and nothing else. (Because nothing else causes performance hiccups in my specific case with one player and max. 50 enemies. But physically destroyable buildings do ... )
Is that possible, or will it be doable in the future?

 

Good info, I'll see if I have some time to work on that. Was looking at using off the shelf stuff for the moment.
basically my users generate a lot of asset bundle based content and I was aiming to give them a dynamics solution for their modded in characters (clothing, hair, etc). I currently post process all assets from their non entities world and can swap it whenever, was just wondering if on the longer run if a unified solution was going to be a thing. Did get a feeling that just rigidbody dynamics was the core important thing. Thanks for all the good work.

 

@Hannibal_Leo
At current state, as far I am aware, you can have one type of physics in MB but multiple types in DOTS. Not that is recommended, or aginst, but possible.

Unless something will change, I don't see why you can not have MB and DOTS physics working as is now.

 

Ah yes. I modified it and indeed worked.

Code (CSharp):

1. Unity.Physics.BoxCollider* scPtr = (Unity.Physics.BoxCollider*) na_physicsCollider [i].ColliderPtr ;
2.  
3. Unity.Physics.BoxGeometry geometry = scPtr->Geometry ;
4. geometry.Size = applyScale ;
5. geometry.BevelRadius = 0 ;
6. scPtr->Geometry = geometry ; // Set back.

The only difference is, since I use box collider, I had to change bevel radius, as was larger than size, in certain of my cases.

Not sure if setting bevel radius to 0 has any implications?

 

So I feel stupid but why do I see C++ code, isn't Unity scripting based on C#?

 

Along with using DOTS, we are entering on lower level programming.
This enables us such great performance.
I wouldn't call it most intuitive, for someone who is mainly oriented in C#, just like myself.
But I understand why is done this way.

You could probably implement method, which wraps lower level programming, to be more user friendly.

 

Yeah, but, isn't here Burst compiler that compiles C# code into C++? I am aware Unity has C++ interop, but still it's weird to me.

 

Well, they made some clever stuff there, which are beyond my imagination. I just (attempt) use it

Someone else would be better to answer, if curious more about details.

 

This is not C++ code, pointers is standart part of C# too

Burst compiler translates from IL/.NET bytecode to highly optimized native code using LLVM

 

So far the only thing I've needed is, the option of apply constraints (forgive me if this already exists, documentation is hard to find), and override position and rotation (say for instance I have a Rigidbody character controller and I want to teleport it or constrain its rotation).

 

I do recommend keeping some bevel radius, if possible. A bevel radius does smooth out the corners of convex hulls** but it also adds a little numerical buffer to the collision detection code, stopping it dropping into the more expensive interpenetration calculations.
Imagine 2 boxes sitting on top of each other. With 0 bevel radius the closest faces are co-planar potentially leading to interpenetration one frame and separation the next. With some bevel radius there is still an epsilon distance between the underlying geometries. So bevel radius of 0 works, but not as efficiently.
Assuming mass increases with volume, a bevel radius of around 5% of the objects extents is a good guide (i.e. 5 cms on a 1 meter box). Though there are issues as things get really big, or really small. More than one order of magnitude from objects around one meter and you need to start thinking a little more carefully about things.

** At the authoring stage the underlying geometry is shrunk by the bevel radius. The final physics representation becomes the Minkowski sum of the shrunken hull and a sphere with radius equal to the bevel radius.

 

Yup, this is still C# code, its just treading into the land of pointers where there is no barriers at the edge of the cliff!

 

@steveeHavok, such nice detailed answers. Much appreciated.

 

Yeah, Joints do exist but we've haven't really DOTSified the API/UI for them, so the higher level Joints authoring components only live in the demos for the minute. Copy everything from this folder into your own project, and check out the Joints Parade demo. I should really put up a blurb around the joints as the underlying atomic runtime constraints can be put together to make you own (the Limit DOF Joint was an example of doing this).

To teleport an Entity you can simply set the Translation and Rotation components.

 

Can I use joints to constrain rotation? When I'm talking about constraints I mean the constraints you'd see on a normal OOP Rigidbody. I need it for a physics character controller.

Teleportation using the Translation and Rotation components doesn't quite work as the physics system will override the input rotation and position unless I run it through a job. So it's getting (most of the time) overridden by the physics system.

 

Because order - matter. Your system should be in right place for exclude case where your input become overridden Your teleportation system shoud executes before\after Physics systems and you should chain correct dependencies. For example:

Simple sample with simple setup just for showing concept:

Code (CSharp):

1. [UpdateAfter(typeof(EndFramePhysicsSystem)), UpdateBefore(typeof(TransformSystemGroup))]
2. public class TeleportSystem : JobComponentSystem
3. {
4.     private EntityQuery _query;
5.  
6.     protected override void OnCreate()
7.     {
8.         _query = GetEntityQuery(new EntityQueryDesc()
9.         {
10.             All = new ComponentType[] {typeof(Translation)}
11.         });
12.     }
13.  
14.     protected override JobHandle OnUpdate(JobHandle inputDeps)
15.     {
16.         var translations = _query.ToComponentDataArray<Translation>(Allocator.TempJob);
17.         for (int i = 0; i < translations.Length; i++)
18.         {
19.             if (translations[i].Value.y < -3f)
20.             {
21.                 var t = translations[i];
22.                 t.Value.y = 0;
23.                 translations[i] = t;
24.             }
25.         }
26.         _query.CopyFromComponentDataArray(translations);
27.         translations.Dispose();
28.      
29.         return inputDeps;
30.     }

 

You can use joints to constrain rotation. Check out this thread for using joints to constrain. You can also tweak the inertia properties to kill rotations.

Unity Physics has 3 main systems:

BuildPhysicsWorld

,

StepPhysicsWorld

, &

ExportPhysicsWorld

.
1.

BuildPhysicsWorld 

reads all the ECS data (including

Translation 

+

Rotation

) converting it into a format easy for random access.
2.

StepPhysicsWorld 

performs the simulation using the converted data.
3.

ExportPhysicsWorld 

writes the updated simulation data back into the ECS components.

If your own teleport system is running in between the

BuildPhysicsWorld 

and

ExportPhysicsWorld 

system, your edits will be overwritten. On your own teleport system add

[UpdateBefore(BuildPhysicsWorld)]

to force the order or operation and stop

ExportPhysicsWorld 

overwriting your changes.

 

Why PhysicsSystems consume so much time with 2 bodies?


What is the reason there is so much idle time between jobs?

The same happens in the build, PhysicsSystems consume too much main thread time for some unknown reason. (0.4ms, 2 bodies)

 

The reason why I care about those 0.5 - 1.5 ms is I want to use physics for a rollbackable simulation (currently there are only 2 bodies).
I will need to run physics up to 20 times per tick, so those numbers will get significant

Why there are 512 jobs which do nothing? (Apart from a single one, which took 0.045ms (0.144ms taken by empty jobs))

 

I use 19.3.0b6, it is using old foreach jobs?

 

I have a strange performance issue. Here is my setup:
I generate a map 100x100 with different tiles where one of them is a wall with a collider shape. Wall is also generated around the map. All tiles are children of the map and it has a PhysicsBody set to static and a PhysicsStep with default settings expect gravity set to 0. All game objects are set to static aswell. All of this is part of a subscene.
Some of those tiles have a spawner attached to them which spawns an agent with physics body and physics shape on it. Agents are moved using a flow field, and it works OK, it takes about (1-2 ms) to move 15000 agents. But with physics, it takes about 100 ms where about 80% of this is taken by the broad phase. I have tested the DOTSoftheDead example provided by @illogikaStudios and with 50000 zombies and a lot of bullets I have better performance.

I there something I am missing?

 

HI,

I'm trying to do a pickup system, where my character can go to a PhysicsBody and pick it.
Though, I need to disable physics on the body and parent it to the character until he release it.

I have a very hard time doing that.
This is the potential solutions:

1. Remove Physics on the object completely: Didn't find an easy way to do that. For what I could see, to switch from Dynamic to Kinematic you have to modify 4 components (Collider, Mass, Velocity,...). Which might be fine, but then I loose all value set by the authoring.
2. Force the Body position. Looked at "MousePick" from the samples, and got scared... Just to move a body, the code if like 100 lines with matrix computations, etc... Also this solution is not perfect, cause I would still have collision on the object
3. Create a Joint between the body and my character. I tried, and I soon as I create the joint (Fixed Joint) my character jump in the air like crazy, even though my anchor is not inside my character collider. Also with this technique, I would still have collision on the object.

He's there a plan to have more friendly methods to handle this type of cases ?

Thanks