Official Unity Physics Discussion

Slightly back on topic, I just turned Unity Physics down to 1 solver iteration... It's still stable. wtf is this solver? seriously. I have a 64 cube long chain and it's still totally stable on one iteration. PhysX isn't stable with a 10 cube chain and 64 iterations. Jeez. Even in worst case it just get's stretchy. It's incredible.

Once this has better performance and stable stacking i'm switching as soon as I can. It's just so stable. Been trying all kinds of joint setups and stuff just works. Honestly, without the jittering i could just project the renderer back into it's constraint and get visibly perfect joints (minus some penetration from rigidbodies, but it would be subtle). This is going to be awesome for VR when it's performant. Can't wait X3

 

I'd like to request separate overrides for mass distribution:


It's actually very rare that you want to modify Inertia Tensor when you want to modify COM.

Current setup forces you to set all these three fields at once. It makes very little sense to bundle there in the editor side script like this IMO (I feel they are bundled just because they are set in same group in code etc, but you should just be able to use the precomputed values for items you don't want to change).

 

Hello,

Obviously Physic ECS is early stage, but we are already using it for our new prototypes. Currently we have this problem and I am looking for suggestions:

For our Character controller we want to freeze the rigidbody rotation, this is usually done in Physx by setting rigidbody.contraints = RigidbodyConstraints.FreezeRotation, is There a similar setting in ECS Physics? (we want to disable the rotation part)

 

Today update of the entity package broke the Physic package (no update available so far):

Library\PackageCache\com.unity.physics@0.0.1-preview.1\Unity.Physics\ECS\Systems\BuildPhysicsWorld.cs(21,16): error CS0619: 'ComponentGroup' is obsolete: 'ComponentGroup has been renamed to EntityQuery. (UnityUpgradable) -> EntityQuery'

 

That latest version of the Entities packages is not compatible with the current Physics package. However, the Unity team is working on an update for this:

 

I have Unity Physics 0.0.1-preview.1 upgraded to the new Entities package locally, but still waiting for response from Unity here if I can share stuff like this in github:
https://forum.unity.com/threads/ecs-packages-on-github.656512/

I'd happily share changes like these but don't want to step over Unity if they don't want these packages on github.

Unity Physics itself is rather trivial to upgrade to new Entities version, pretty much everything is covered in the release notes upgrade guide.

 

Also, I know joints are still WIP but is there any ETA for breakable joints? What about articulations, are they planned?

 

I have been using the CompoundCollider type to generate collision, set up by code. We have structures that are actually composed of multiple simple shapes, so this seemed the most suitable choice. However CompoundCollider.Create() currently generates quite a noticeable spike.

Is this a feature where performance will be improved in future releases? Otherwise I might have to do something more specialised when it comes to generating these colliders. Overall though, we have seen ECS Physics working pretty successfully so far - thanks!

 

Hello, I'm starting to play with the unity physics. In my experiments I noticed that having the classic Rigidbody and coliders on a game object and the convert to entity script seem to have the same effect as the new phisycs shape and body components.
Except losing the ability to choose between unity and Havok, am I correct to assume that or is there any draw backs in keeping the "old" rigidbody and coliders ?

 

Conversion workflow can't convert what is not there: New Physics Body has some settings that don't exist on old Rigidbody component. Same applies to Physics Shape component.

If you only need to convert the settings that exist on both components, I'd guess it makes no big difference. I dunno if you get PhysX dependency by doing this though? (You probably could remove regular physics module from your project otherwise if needed).

 

Can you please further clarify for Unity Physics:

Deterministic across all platforms.... do you mean fixed point arithmetic operations? If not - how else is this achieved given the way floats are calculated, if you are using fixed point, how are you optimising this for 3D, can we control precision amount? I couldn't get better than 2D deterministic fixed point arithmetic physics.

I have desperately needed deterministic 3D physics for networking RTS games, but i couldn't make a good enough physics engine for it with performance. And the arithmetic operations were complicated for 3D.

Secondly, why is it an either/or between current physics solutions (physX) and unity physics? What does one provide that the other does not, it sounds to me like unity physics will provide what we already have AND more for things like networking, performance and determinism, why would we need the physX solution anymore after that?

 

Disclaimer: I don't work for unity and i'm not a primary source, i'm repeating what i've seen in talks and around the forums. There are people here who will know better than me.

Determinism: From what i've seen they are going to use Burst(which let's them compile their own machine code) to create the same exact operations across all platforms. This would remove all the platform specific optimizations to floats that create different behavior between platforms.

PhysX difference: It's an either or because Unity physics is missing a bunch of features that you need to ship a game, eg: physics sleeping, dynamic rest (stable stacking of rigidbodies), currently has a bunch of sync points that are tanking performance on even simple scenes, etc... The other thing is that PhysX is for the Gameobject pipeline and Unity Physics is for ECS. Plus stuff like determinism and statelessness can come with a really large performance hit sadly. So it won't be the everything solution for a while yet.

Hope that helps!

 

Isn't the lack of sleeping and dynamic rest simply because it's still in development ? Or do they not plan to add half the features PhysX has regardless?

 

My Player Kinematic Physics Body is not colliding with any other Entity .
i tried to change my body to dynamic and im able to collide.
i didn't get the reason .

 

*shrug* No idea. Their design doc makes it sound like they aren't going to implement them but in this thread they've said they're looking for feedback for future releases and made it sound like they where interested in implementing them. It's super weird and unclear. I'd really like a solid answer on whether their planning this to be a full featured solution in the long run but for now it's super ambiguous.
https://docs.unity3d.com/Packages/com.unity.physics@0.0/manual/design.html

 

What exactly is the 3 year plan of unity?

 

It's basically this:



Image taken from this DOTS 2019 Roadmap talk: https://www.gdcvault.com/play/1026146/

 

Unity Physics 0.0.2-preview.1 and Burst 1.0.0-preview.12 are up. Unity also updated the physics examples from
https://github.com/Unity-Technologies/EntityComponentSystemSamples/tree/master/UnityPhysicsExamples

 

Please provide a clear documentation for the new Unity Physics and restore the ECS documentation.
ECS does not have a documentation anymore.

 

https://docs.unity3d.com/Packages/com.unity.physics@0.0/manual/index.html
https://docs.unity3d.com/Packages/com.unity.physics@0.0/api/Unity.Physics.html

https://docs.unity3d.com/Packages/com.unity.entities@0.0/manual/index.html
https://docs.unity3d.com/Packages/com.unity.entities@0.0/api/Unity.Entities.html

 

So I took preview 2 out for a spin this evening. Out of the box, it still has the same nasty issues as the previous version.

But I am a little smarter now and turned on Synchronous Compilation in Burst, and all the narrow phase lag spikes completely vanished. It would be nice if Burst cached compilations between entering play mode several times if the C# code was not recompiled.

The pool table demo is still slow, but that's all render thread issues. Enabling GPU instancing on all the materials helps a bit. I haven't investigated why that's slow. And for everyone struggling to enjoy the interactive demos due to the simulation running outside of fixedUpdate, turning on vsync in the project settings seems to tame that down for me.

I didn't notice many changes in the code other than a reworking of the collider internal functions and the inclusion of dedicated cylinder colliders.

So overall, I managed to make nearly all the demos perform well with just a couple of tweaks, and there's some real potential with this Physics Engine! It doesn't meet my needs at all, but my needs are not the normal use case so that is completely understandable.

I can officially confirm that the broadphase is a very fast BVH-based broadphase from a raw computing perspective. I'm still not convinced it is the best approach, especially if Burst ever supports AVX. And right now it is suffering from some scheduling issues.

This is with safety checks and leak detection disabled. I know I can expect to see better performance not in the editor, but this is on my workstation and I don't think I would magically get a 4x improvement in a build on something like a Ryzen 3 mobile compared to this setup. I'd test that theory, but it is getting late for me.

 

Will Unity Physics Interoperate Havok AI ,for 2d`3d PathFinding,Character Steering & Collision Avoidance .

 

Thank you !!!!

 

The character controller scene show us the way to use PhysicsBody and PhysicsShape for character controller. And make Gun as a child with Convert And Inject Game Object for it. It give me the ability to use Animator or other Hybrid feature for it.

But what about the situation below. I want to add a PhysicsShape with isTrigger checked to the blade.

Any suggestion for it? Thank you.

 

As a child I used a physics engine called Newton Game Dynamics, it was the most amazing stable physics experience ever. They never stopped developing it. It's now called Newton Dynamics, open source and highly underrated. If you look at some of their recent work they even incorporated the latest physics findings from the international space station:

Here is a low quality comparison video of Newton Dynamics VS PhysX VS Bullet and it shines just like it did years ago.

They are working on a Unity extension over at GitHub.

Truly a very underrated physics engine that deserves more attention. I wish Unity would reach out to them and give them an opportunity to work together.

 

Do you have a source for Chaos being GPU based? I didn't hear that before. FWIW I think you could have "GPU based" rigid bodies right now in Unity by just enabling a couple of flags in the PhysX setup - no need for voxels.

 

But would it be possible? I got the feeling from the MegaCity presentation that the hierarchical culling etc was kind of hardcoded for that specific scene (without using a "complex" data-structure like a BVH). So doesn't that mean you cannot really move all these objects at runtime? Because the culling code wouldn't work anymore.... I probably missed something here.

 

That suggests there is a problem in the setup. You can definitely do stable chains with PhysX. Here's an example using the default joints, but it's even better with articulations & the new solver:

 

I believe Unity Technologies have the people who could make that happen, if they want to.

 

Isn't it just the Dzhanibekov Effect ? It's been supported by Bullet for years - they even have a sample for it IIRC.

 

That looks like a very biased video, conveniently showing a few cherry-picked tests. The original benchmark suite has hundred more. It's also quite out of date anyway with PhysX 3.4. There's a new version of this tool but it's not released yet. Looks cooler now:

 

Yeah, I've seen those demos. Never been able to get anywhere close in unity, not sure if that's a unity problem or if those demos are doing fancy stuff under the hood, but it's definitely irritating. It breaks into a jittery mess the moment it hits an impossible situation. I would be very interested how much trickery their doing under the hood to make those demos work. =/

As for GPU based, it's mostly the scale. They showed in their usage demo they are using voxels instead of convex meshes. Considering these are leagues slower on CPU's and much better fitted to GPU's it would only make sense to be using some kind of GPU acceleration, not to mention the whole demo has too much going on for even a fast CPU physics solver. Plus they mention reading the contacts directly into Niagara on the GPU, considering this would require massive data upload if it was simulated on the CPU i highly doubt their doing that.

[EDIT] that rope video is from one of the devs of PhysX. He's using a bunch of extra joints (jointed to the root, and every 2-4 elements), COM editing, mass scaling, etc.. to get it to be stable, as well as it's using distance and spheres instead of actual links. Which is fine but it's not stability by default. That's duct tape and hacks.

 

Well it's PhysX, it has always been "performance by default", not "stability by default" But the "hacks" like tweaking inertia tensors are the bread and butter of game physics (everyone does that, including Havok) so I'd say that doesn't really matter as long as it works. If you want the "stability by default" I suppose PhysX 4 & the new articulations would give you that anyway.

 

One thing I don't understand is why isn't Unity doing the "duct tape and hacks" for users under the hood. Exposing half of the PhysX API as-is isn't helpful, it's like trying to use that lib with one have hand tied in the back. There is no added value in a wrapper if it only exposes the regular API calls but not even all of them etc. I would have expected Unity or Unreal to actually enhance the physics API and provide maybe a higher level rope component making all that stuff work out of the box for their users. Why isn't it the case.

 

FWIW there's a "createLongChain" function in this snippet, that doesn't use "hacks" and still works fine. But it's using articulations so I guess not available in Unity:

https://github.com/NVIDIAGameWorks/...s/snippetarticulation/SnippetArticulation.cpp

So I think saying "PhysX isn't stable with a 10 cube chain and 64 iterations" is misleading, BUT your point about "impossible situations" is valid: PhysX struggles with "impossible" cases indeed (where things would just break up or explode in real life for example). I suppose it's normal to get numerical explosions in these cases? How is Unity Physics dealing with these? Can you describe your case where you get a "jittery mess"? Would be interesting to test the same case in Bullet or Newton.

 

For more context: When i said the 10 cube chain with 64 iterations, I was actually referencing a real test i did the same day. 10 cubes with character joints, with lots of parameter tweaking. Any rapid movement would cause it to explode in a jittery mess (all joints jump around everywhere whenever it stretches) even with 64 iterations. Often knocking into other objects in the scene causing collision cascades.

Unity Physics I made basically the same setup, just using ball and joint (there's no equivalent in Unity's PhysX, closest is character joint). Totally stable. No parameter tweaks, no extra joints, no COM, tensors, no magic. 1 iteration was a little squishy but still held it's shape, even in impossible situations. Took less than two minutes, mostly just duplicating cubes and assigning targets. even huge chains where stable, if squishy on low iterations.

I didn't mean PhysX couldn't handle it, but having to add tons of extra non-physical joints, tons of COM and tensor tweaking, just to get basic joint setups to be stable is a terrible workflow. It's also not generally applicable, so it's almost impossible to automate. Meaning every joint setup takes hours. I'm not going to compare setup that takes 2+ hours of tweaking to a setup made in 2 minutes in a dead simple way and pretend their equivalent because it's technically possible with another 3 hours in physX and a bunch of custom code. I'd much rather be doing those tweaks to improve my physics rather than having to do them to make something even remotely usable. On top of this there's the constant knowledge that at any moment during gameplay PhysX could shatter and blow up everything in the whole scene if the player manages to break one of the joints. o_o

Unity Physics has a long way to go before it's production viable. But i absolutely love the ability to make setups that make sense and they just work. I work on VR stuff, I have wanted reliable joints for ages, the joints in this work way better. I actually feel like they can be relied upon to not break my game. I'm sick of not being able to trust PhysX's joints to not trash everything. I want to spend my time thinking about what i want to make, not fearing when physX is going to explode.

Anyway, sorry for the long post, just my rambling thoughts. It's really nice being able to just make stuff for a change. Rather than feeling like i'm trying to land on the moon every time i want to make some jointed structure.

 

FWIW there's no "character joint" in PhysX. "Ball and joint" sounds like a "ball and socket" joint, a.k.a. spherical joint in PhysX.

It doesn't take 3 hours of tweaking to make a 10 cube chain in PhysX. It just works for me, not sure why it doesn't in Unity. Bit of a mystery here. PhysX isn't perfect but it's been used in tons of games that don't randomly explode because of joints, so.... Unity wrapper issues maybe?

 

Does PhysicsWorld.CastRay have an error or am I doing it wrong?
I've tried to cast an ray from the mouse position, but it hits only if the origin(Camera) in a collider.

The Job:

Code (CSharp):

1. [BurstCompile]
2. public struct RaycastJob : IJobParallelFor
3. {
4.     [ReadOnly] public PhysicsWorld world;
5.     [ReadOnly] public NativeArray<RaycastInput> inputs;
6.     public NativeArray<RaycastHit> results;
7.     public NativeArray<bool> isHits;
8.  
9.     public void Execute(int index)
10.     {
11.         RaycastHit hit;
12.         isHits[index] = world.CastRay(inputs[index], out hit);
13.         results[index] = hit;
14.     }
15. }

OnUpdate:

Code (CSharp):

1. protected override void OnUpdate()
2. {
3.     ref PhysicsWorld world = ref World.Active.GetExistingSystem<BuildPhysicsWorld>().PhysicsWorld;
4.     var mPos = UnityEngine.Input.mousePosition;
5.  
6.     var ray = UnityEngine.Camera.main.ScreenPointToRay(mPos);
7.  
8.     uint layerMask = 1 << 0;
9.     var filter = new CollisionFilter { CategoryBits = layerMask, MaskBits = 0xffffffff };
10.     //filter = CollisionFilter.Default;
11.     var input = new RaycastInput
12.     {
13.         Ray = new Ray { Origin = ray.origin, Direction = ray.direction},
14.         Filter = filter
15.     };
16.     var rayCommands = new NativeArray<RaycastInput>(1, Allocator.TempJob);
17.     var rayResults = new NativeArray<RaycastHit>(1, Allocator.TempJob);
18.     var isHits = new NativeArray<bool>(1, Allocator.TempJob);
19.     rayCommands[0] = input;
20.    
21.     JobHandle handle = new RaycastJob
22.     {
23.                 inputs = rayCommands,
24.                 results = rayResults,
25.                 world = world,
26.                 isHits = isHits
27.  
28.     }.Schedule(rayCommands.Length, 5);
29.     handle.Complete();
30.  
31.     var result = rayResults[0];
32.     var isHit = isHits[0];
33.     if (isHit)
34.     {
35.         UnityEngine.Debug.Log("Hit");
36.     }
37.  
38.     rayCommands.Dispose();
39.     rayResults.Dispose();
40.     isHits.Dispose();
41. }
42.  

 

It does take 3 hours if you want it to be robust for gameplay. There's a big difference between a chain simulating properly and being able to bat it around, stretch it, etc... without it breaking and blowing up everything. Plenty of games don't have everything explode because they take the time to babysit joints, or remove stuff that causes those explosions. It's unshippable. that's kinda my point.

 

Pardon me but if we're suddenly talking about shipping an actual game, 3 hours is actually not that much if it's robust in the end. You really should spend more than "2 minutes" on your physics setup & physics fine-tuning before shipping.Otherwise that's exactly how you end up with funny physics bugs in Youtube videos (with any physics engine).

I suggest we continue this discussion after anything has shipped with Unity Physics. I don't think we can already claim that this one is going to be problem-free (already heard that with Newton, was the exact opposite).

 

Okay. Download Unity Physics. Try it. Make a cube chain in PhysX, make one in Unity Physics. Unity physics has taken everything i have thrown at it without breaking once. That's really cool. I praised that and was sharing my experience with Unity Physics. PhysX in my experience takes a long time to get gameplay worthy. Unity Physics is better out of the box than what i get with hours of tweaking and custom scripts in PhysX. Try it for yourself, it's not hard. No unity physics isn't ready to ship yet. I never said it was. I'm not talking about the whole physics engine, just joints. If you don't share my experience, fine i don't need you to. I was just sharing my experience.

Anyway, let's stop this here. I don't feel it adds anything to repeat myself.

 

But I did. Just not through Unity. And my point was that it worked fine.

Again, I think there's something fishy going on in the Unity wrapper/version. I am not trying to dismiss your experience: I completely believe that Unity Physics works better out of the box (I don't need to try it myself, I believe you).

But it seems that people using PhysX directly have an easier time than people using PhysX wrappers. It could be useful for Unity users to go to the bottom of why it is the case. Especially with PhysX 4 focused on robotics, joints have to be robust out of the box. They don't randomly explode after an hour training a robot, they're rock solid. And they're not "tweaked" for gameplay either, the params come right out of the robots specs and that's what you use period.

Anyway this is all off-topic (sorry, I got side-tracked by that Newton video). Should move to a PhysX thread really. Let's stop indeed.

 

Ok i see your point more now, sorry for being defensive (I need to not reply to threads at 4am). Yes you should start this up on the physX 4.0 thread. This is a totally separate team working on Unity Physics to the PhysX integration. I'd be interested to see what's causing the joint instability if it's coming from unity's integration.

 

So the changelog.md for Unity Physics references this:

* Physics systems are tied to (variable) rendering frame rate when using automatic world bootstrapping. See `FixedTimestep` examples in ECS Samples project for currently available approaches.

Does anyone know where these "FixedTimestep' examples are? I can't find them.

 

I've found a weird behaviour. I have a very simple scene with a dynamic rigidbody entity. I'm using a system to set the angular velocity. I'm setting

velocity.Angular.xz = 0;

and

velocity.Angular.y = 1;

This functions exactly as expected (rotating about y) unless the shape type is set to cylinder, in which case it rotates about x.

I assume that this may relate to the orientation properties on the physics shape. It appears the rotation is relative to those. Is that correct? I find that behaviour unintuitive. When I set

velocity.Linear

that appears to be in world space but

velocity.Angular

appears to be in some rigidbody space. This is clearly designed behaviour because your examples handle the necessary transforms and you provide extensions, but it caught me out.

ComponentExtensions.SetAngularVelocity

looks like the correct API to use here and indeed seems to work. I find it unexpected and clunky that I need to provide a

PhysicsMass

and

Rotation rotData

to set the world space angular velocity. I did not expect to need access to those components for this simple operation. I find the use and existence of the

entity.SetAngularVelocity(float3 angularVelocity)

variant to be distasteful and risky because it lacks type safety. That should not be encouraged behaviour because that way bugs lie.

As a side note, the source code appears to include basic comments for the API methods but they're not documentation comments, so they don't show in intellisense. That seems like a usability oversight. While this is still in preview, it would be useful to have access to those development comments as a stop gap until you have full documentation comments written.

Oh. I just thought to check the source for the

PhysicsVelocity

type and there's a comment explaining that you already intend to make the change I'm suggesting by moving the angular velocity into world space. That makes this whole comment redundant. I've written it now, so I'll submit it because maybe there's still a little value in it.

 

I see that you have a few places in the API where an int is used to denote an axis and an assertion is made to keep that int between 0 and 2 inclusive. I presume that this corresponds to x,y,z. Would it not be nicer to have that as an enum?

 

From a brief spin on 2019.1 this is looking very promising, having source access I hope some of the wider physics community run with this (Obi Physics and the various Vehicle Physics asset creators).

Is there any roadmap for when UnityPhysics is expected to be production ready?
The infographic from the DOTs roadmap talk suggests 2022, are you 3 years away from this project being included in a LTS?

 

We are betting on it now so I hope it won't be 2022

 

How can I make the Unity Physics Ragdoll Joints in 2019.1 work with an imported FBX with a skinned mesh renderer? I get some rather uncouth results: