(Case 951618) Physics: Raycast hits ghost collider

[Peter77]

Physics.Raycast hits colliders at their position from during scene activation, even when those non-static objects have been moved to another location.

Please see the provided video, that shows how Physics.Raycast used to work in 2017.1 and how it does work in 2017.2.0b11.

(Case 951618) 2017.2.0b11: Physics: Raycast hits ghost collider

Reproduce

1. Open user attached project in Unity 2017.1.1p2

2. Open Assets/Scene.unity

3. Press Play
   Observe the line that represents the raycast and the red sphere that represents the hit point.

4. Move ‘Player’ GameObject around
   Observe the player capsule does not get hit if the raycast does not intersect it.

5. Open project in Unity 2017.2.0b11

6. Repeat from Step 2.
   Observe the player capsule is hit even if the raycast does not intersect it.

Expected
‘Ghosting colliders’ should not be hit.

[PhilSA]

Does the problem occur when moving with CharacterController.Move()?

[Peter77]

@PhilSA

Does the problem occur when moving with CharacterController.Move()?

Thanks for the idea, just tested it!

It does occur when using CharacterController.Move() as well.
It does not occur when I remove the CharacterController and add a CapsuleCollider instead and write to transform.position.

I should also mention that I turned off the auto-sync features.

Physics.autoSimulation = false;
Physics.autoSyncTransforms = false;

Turning on Physics.autoSimulation fixes the issue. But I wonder why does it work with a Collider in either mode, but not with a CharacterController.

3225228–247374–Case_951618_Physics_Raycast_hits_ghost_collider.zip (22.8 KB)

[hippocoder]

A character controller is raycast based so it would need the physics bodies to be refreshed before the raycast occurs, does that sound similar?

[Peter77]

Here is the reply from QA:

@""

Our developers resolved this case as by design, and I will explain you why.

The thing is, that when we set the position of a character controller, it will only be available once the simulation is called. This is because a character controller is a shape and a kinematic actor internally so its movement is carried out through the analog of Rigidbody::MovePosition.

You disabled autoSyncTransforms(that will disable automatically writing the changes done to transforms over to the physics engine). You have also turned off autoSimulation, which means that you don’t do any physics simulation.

That said, nothing is syncing the transforms to the physics engine.

Many things for providing an explanation!

[hippocoder]

Yep thought that would be the case. They should make sure that they update the physics viz if they aren’t already, and draw colliders for things where they logically are rather than where the mesh appears to be.

I’m sure they thought of that. Right? I hope. In any case someone should think about updating the physics vis or a lot more reports like this will be soaking up QA time.

[Peter77]

What I actually don’t really understand is this:

@""

You disabled autoSyncTransforms(that will disable automatically writing the changes done to transforms over to the physics engine).

I have a hard time wrapping my head around this, because If I understand MelvMay’s reply regarding autoSyncTransforms correctly, Unity does do a sync always, no matter whether autoSyncTransforms is set to true or false. The only difference seems to be when this happens.

@""

From the physics system POV, a SyncTransform is done prior to updating the simulation during fixed update or a manual physics simulation. This always happens.
…
Therefore, the best performance is when AutoSyncTransforms is off i.e. it’s only sync’d prior to updating the simulation. Only call SyncTransforms if absolutely essential and avoid calling it if not needed.

My thought is or was, because Unity does seem to sync transforms even with autoSyncTransforms set to false, the CharacterCollider changes on the transform should find their way over to the physics engine. But they don’t seem to, which is why I submitted the bug-report.

[hippocoder]

Well that’s 2D and this is Physx, so maybe it doesn’t happen with Physx? @yant @MelvMay
Would be nice to have some tips or ref I can advise or help forum users with

[PhilSA]

Here’s my guess: the SyncTransforms that is always called once per fixed update even when autoSyncTransforms = false is actually called by the Physics.Simulate that is internally called when autoSimulation is true

Edit: I’d be curious to see what happens if you set both autoSyncTransforms and autoSimulation to false but call Physics.SyncTransforms manually once per frame in your example project

[yant]

Hey. I commented the fogbugz case, but putting something similar here, for better transparency.

So the CharacterController is actually two things in one internally, in PhysX. It’s both a shape (ie Collider in Unity-speak) and a kinematic actor (ie Rigidbody with “isKinematic” set). Calling CharacterController::Move results in something similar to Rigidbody::MovePosition really, and the result of that is only available after a simulation was run. In this project, the simulation is never run (Physics.autoSimulation=false), and nothing is calling Physics.Simulate() either. That’s why the CC’s shape doesn’t happen to be where you expect.

[Peter77]

@yant

That’s why the CC’s shape doesn’t happen to be where you expect.

Thanks for the reply.

I wonder why does it work if I remove the CC and add a Capsule Collider then? In this case, it’s still Physics.autoSimulation=false and Physics.Simulate() isn’t called either, but the Capsule Collider position if where you’d expect it.

[yant]

That’s because a builtin-in collider doesn’t include a hidden implicit kinematic actor, so its pose is reflected as soon it’s been written to.