Official Unity.Physics 0.5.1 breaks through!

Samples doesnt work for me

 

When did you try the samples? They were updated just recently, please make sure you got the latest version.

 

I'm on the latest version of samples and 2020.1.2f1 version of editor.
Edit: Restarting editor fixed the issue

 

Debug draw sounds really nice.

Interpolation is sort of what I guessed it would be. We rolled our own which we will stick with some notes on what I think is problematic with the built in solution.

We have a fairly complex interpolation setup. Moving platforms where other bodies have to move relative to them but in different ways. Characters that move independently, bodies connected via joints, some that move relative to but don't use joints.

We also have to access interpolated positions long before where physics does interpolation. Interpolating at end of frame leaves very little time to do anything.

We chose interpolate early right after physics runs. So that everything else has access to interpolated positions. But we also have an InterpolatedBody abstraction that physics logic has to write to. This means it's not automatic but it's also inherently more flexible. Like moving B relative to the interpolated position of A is easy. We don't have to be a frame behind on anything either. The cost is everything has to reason about interpolation and whether it is working with an interpolated position or not.

I feel like there is a better middle ground. Our solution is overkill for a lot of trivial cases. But complex cases using the built in flow best case force unnecessary compromises like being a frame behind.

 

So why do integrity checks include kinematic bodies? The caveats for updating between build and step don't always apply. This sort of screwed us and unnecessarily it seems. How badly I'm not sure yet as I'm going to have to dedicate a significant block of time before upgrading.

 

Is there a way to both have fixed physics updates and the ability rollback and re-simulate physics worlds? If so, how? I want to develop a game with rollback and this would be very helpful.

 

Integrity checks are there to help you, they are not mandatory and can be easily turned off.

However, some of the checks do apply for all bodies, since the problems you can see are really serious. For example, imagine adding a component data to your kinematic body. And sadly, in some case, it can get moved to a new chunk. Then ExportPhysicsWorld comes, presuming an order of entities from when the BuildPhysicsWorld ran, and writes back totally wrong data to a bunch of entities.

So bottom line is, you need to be careful. Integrity checks are there to let you know what can happen, and it's in your best interest to be extremely careful about the things you are doing during the step.

 

We will be providing a rollback example, we just didn't get to it yet.

In short, if you need to do rollback, you need to take control of the step, not let StepPhysicsWorld take care of it. What you need is the utility to copy the ECS data at certain points, and then when you decide to roll back, you copy over the frame ECS data and execute the build-step-export combination a number of times.

 

Ok good to know turning them off won't break stuff.

FYI why we were doing that is because if you run before BuildPhysicsWorld and access bodies you have to just use Run(). After export and it's a frame late. And the use case was kinematic bodies we move directly so sort of an easy choice.

On that note what do you think about cloning the Collision world post export as a way around the whole bodies reset issue? Make a fast copy of the bodies clone the broadphase.

 

As a temporary thing I say why not. But I'll work on fixing the issue with the BuildPhysicsWorld you are seeing to provide a proper fix for this.

 

It seems that you have forgotten to generate the browser documentation entry for physics 0.5.0-preview.1. In the package manager it only links to the local md files of the package.

 

Any news on Joint Motors?

 

Gosh, Burst was turned off.
Gotta always checks it first.....

Spoiler: Original comment

I just downloaded the updated ECS example repo and it is doing weirdly slow, for instance the ragdoll example starts at 100+ fps, then quickly drops, eventually stays at 2.5 fps when all the ragdolls lies still on the stair.

The profiler says it's the EndFixedStepSimulationEntityCommandBufferSystem waiting for several physics jobs to complete.


Other demos I tried (Planet, ForceField) are also very slow. I thought I was overestimating the power of the Physics package, but got suspicious.

The PC spec is Win10 pro on i7-9700 + 32GB Ram + GTX1080 4G

 

Updating to 0.5, I noticed that two colliding dynamic bodies manually stripped of PhysicsVelocity no longer produce a colliding bodypair for IBodyPairsJob. Sounds like some internal optimization, though it's still a perfectly valid use case, at least for me. Wonder whether it's intended or not.

 

Are you sure this started in 0.5 (you upgraded from 0.4.1?)?

There is nothing in this release that relates to this, so maybe it's just a matter of timing (when you remove the PhysicsVelocity)? I think this was never the case - 2 static bodies (bodies with no velocity are treated as static) never report a pair, simply because they are in the same tree that never gets a self overlap.

Now if there is something that happens that keeps them kinematic/dynamic (like a wrong timing of removal of physics velocity or something like that), they would get a pair.

 

I've upgraded from 0.4.1 and it definitely behave differently now. Can't say 100% it's precisely due to upgrade as I had to tweak some stuff here and there to accommodate for fixedUpdate, but the core issue is definitely about body pairs not being generated.

I'm a bit confused of terminology; is mere absence of PV makes a body static? What about kinematic bodies? My setup is "Motion type: Dynamic" in PhysicsBody authoring and then I add/remove PhysicsVelocity, PhysicsCollider and/or PhysicsExclude based on my heuristics.

I'm doing some optimizations around colliding bodies to make it 60fps on mobile, part of that is processed in BodyPairs job. Before 0.5 update it correctly processed colliding bodies stripped of PV in the same frame by other systems.

 

Missing PV definitely makes the body static. Kinematic bodies do have PV, but their physics mass is set to infinite to avoid them being affected by impulses. But they will overlap correctly. PhysicsExclude completely removes stuff from simulation. My guess (I don't have a lot of info, so sorry it's basically just a guess) - timing/ordering issue. And yes, fixed update upgrade probably caused it, we had to tweak a bunch of samples demos a lot to accommodate for this properly.

 

I see, thanks for the clarification! Any advice then how to make an event similar to OnCollisionStay for objects which might loose PV anytime?

 

Why don't you keep them kinematic instead? Just set inverse mass and inverse inertia to 0. They keep all the events but nothing will move them. Just make sure velocity (both linear and angular) is 0.

 

Something in 0.5.0 is preventing the export of motion data from PhysicsBodies that do not have a collider. It seems like the entitygroup hasn't changed so I'm still investigating the problem.

The motion data is definitely calculated but the export system never runs:

 

Update:
Its evidently only affecting the initial query for whether the system should run. if theres at least one entity with a collider, the system will run and all valid dynamic entities will be exported.

Dont know what happened that caused the PhysicsCollider to gatekeep the ExportPhysicsWorld system. probably an easy fix @CookieSalad . Ill let you know if I find it

 

This was my initial setup back then with Physics 0.2 and it was super buggy. Reworked my code now with 0.5 to use zero InverseMass and unfortunately it's still weird and buggy. The one issue I cant work around of I've reported as Case 1282300. Kinematic body is affected by gravity.

 

Kinematic bodies by default get a gravity factor of 0, meaning gravity isn't affecting them. Now if you are making them manually, please make sure to add PhysicsGravityFactor component data with a value of 0 to the bodies.

 

Ok, that's counter intuitive at least, but please check the bug report. The behavior is inconsistent between Unity and Havok physics and is depending on PhysicsShape component as well.

 

Just upgraded from the the april preview release and the improvement in stability is awesome. Phenomenal work!
(Also tried the Havok backend for the first time and the conversion was seamless. Super impressive stuff folks)

 

Yeah, the independent frame rate of gpu render and cpu physics is the best! I hope another calculations in dots can be configurable like this one!

 

Ok, have tried the new smoothing along with the fixed update and it's really helpful! Even when physics loop drops below 10fps, the game feels waaay more responsive and smooth compared to 0.4 . And surprisingly the only thing broken by smoothing is direct Translation animation, which I had to rework to LocalToWorld.

 

There will be minor improvements to this in the coming release, but I'm glad you like it even now!

 

After updating I noticed objects now fall out of my world or sink into objects. I have different subscenes for static stuff and dynamic bodies. With previous versions this was not an issue, but now it seems the order of subscene loading or maybe physics happening in parallel with subscene loading can cause issues.

 

Physics systems have moved to the fixed step group in this release, so any code relying on them or interfering with them needs to adjust to that. Minor sinking of bodies can also be due to the interpolation (motion smoothing). We would need more info to investigate this.

 

I did notice that if you try the samples on actual build (with the default launcher), fixed time steps only apply if you load the scene from the launcher menu, if you refresh the scene or swap the scene from the left and right UI arrows, it will run the physics uncapped again.

Edit: Apparently it does have some catchup kinda situation where it does go to fixed timesteps eventually but in most examples the demonstration of the scene's physics has been done at that point.

 

We've fixed the issue with kinematic bodies having gravity applied, it will be available in the next release (soon). Still looking into the inconsistency between the two engines.

 

Seems like it's the integrity checks we just added. For the time being, you can comment out the CheckIntegrity() call in the ExportPhysicsWorld, should be enough to get you moving.

We're already working on a proper fix.

 

Why isn't Unity.Physics showing up for me? Am I blind?

[edit] I had to manually add the com.unity.physics URL...

 

Input stopped working for me in sample scenes after release 0.5 or so

 

Thanks for BuildPhysicsWorld.AddDependencyToComplete()!

Final item on my pain point list is Mesh being internal. We use this similarly to how the debug tools do, to iterate over geometry in physics.

 

I had to remove `#if UNITY_INPUT_SYSTEM_EXISTS` (am a Unity noob and not sure yet where to set pre-processor directives)

 

Thanks, it's working. You can set it in Project settings> Player> Scripting define symbols