Hi there! Sorry for the delay in replying, messy days here.
Yep, my character controller has other colliders as child but - they’re “dormant”, disabled and waiting to be used for ragdoll when dead (and when it happens I disable the charactercontroller entirely).
You’re mentioning that there’s differences between the rendered world and the physics system world, I would like to tag @Augustinas-Simkus on it, that’s where Physics Debug enters, right?
I’ve used it on this example, it shows this capsule but, the raycasts are passing by, returning 0 errors. There’s something else that may be checked out?
@tjmaul , you’re mentioning slowdowns… are they related to Physics.SyncRigidbodyTransform calls? Your project uses lots of physics objects on the screen?
One thing I’ve tested briefly was to disable the autoSyncTransform. The performance looks better, but I do need to test it more (I think you’ve disabled autosync already, using the manual SyncTransform calls, right?)
Hi. Yes, as @tjmaul pointed out, there is the “Unity world”, where Transform components tell poses of objects, and there is the “physics world”, that is inside the physics engine (in this case PhysX). The Physics Debugger uses data directly from PhysX to draw these shapes and therefore generally provides the ground truth (as opposed to the gizmos) of object position and geometry.
That’s the reason we always advise against moving Transforms of GameObjects with physics components directly. It causes a conflict of interest and the physics engine often sees those Transform changes as teleportations instead of smooth movement. As an example, this is how data flows inside the Physics.Simulate call:
Pending Transform changes are applied to the physics components.
The simulation step is performed.
Poses from the simulation are applied to the Transform components. Physics-related events are dispatched.
As you can see, if there are no pending Transform changes, the data flow is pretty much one-sided but I guess I’m going a bit off-topic for this thread
Regarding the attached screenshot, it’s a bit hard to tell from that perspective but at first glance, it kinda looked like the raycast is scrapping the edge of the deflated Character Controller like this (I could be easily wrong, I can only see the 3D world from 1 perspective there):
Hi, I remembered a bug that was fixed in 2022.2.0a11, it actually sounds a lot like your problem and I’m not sure how I did not think of it earlier. Is there a way you could clone your project and try to upgrade it to 2022.2.0a11 or newer (just to check if the fix works for you)? The fix will be backported but it’s taking a while.
I was expeting next 2020 version to fix it first, but since it was updated yesterday without this fix on it’s patch notes, I did finally tried to test the game on Unity 2022, on a playable build sent to players.
Unfortunately, 2022 did not fixed the issue. It’s the same as before.
Only the flaregun works, because it uses rigidbody/sphere collider. They raycast (including the on used in enemy view test) fails.
The 2020.3 stream indeed doesn’t have the fix yet, it’s still on its way.
If the 2022.2 fix did not help you, the 2020.3 fix will not help either. There’s something else going on in you project it seems I’m not sure how I could further debug this issue without getting my hands on the project.
A colleague was able to find the issue on another project: a rigidbody way beyond the safe floating point world pos, making the physics system garbage collector to go FUBAR (did not showed on the profiler).
I’m pasting his findings:
Dynamic objects probably use some kind of optimization structure for broadphaseand when you stretch it at that size, it doesn’t work anymore. PhysX is probably logging a shit ton of error messages (I was getting 400ms GC collect calls!) but we can’t see it because Unity doesn’t show it to you
It would be nice to add more error reporting related to PhysX issues.
I will still need to test if that’s the case for my project, but I’m optimistic - there was an pickup/collect-able item falling indefinitely on the game.
Well first of all, I’m glad that you found the underlying issue and got yourself unblocked!
I ran through our logged bugs and found the exact same issue resolved as “Won’t fix” back in 2019 To be honest I would like to revisit it, the bug seems preventable with a little bit more effort and time.
I definitely agree, but the problem with that is that most PhysX errors are only logged in debug builds of PhysX and since the binaries are linked statically, we can only distribute Unity with 1 versions of PhysX. So obviously a release build is used for that. That’s the same reason you can’t use PVD with Unity.
Also, PhysX does not allocate any garbage but perhaps something else was writing to the console/log file furiously
I’m not sure how I could further debug this issue without getting my hands on the project.