More specific, Unity 2019.1.0a7
I certainly see allocation from these methods in Unity 2019.4.12
How do we know if this is a regression or if the improvement was reverted further down the dev cycle?
More specific, Unity 2019.1.0a7
I certainly see allocation from these methods in Unity 2019.4.12
How do we know if this is a regression or if the improvement was reverted further down the dev cycle?
There was a checkbox in the project settings to enable sharing the Collision class instances among the callback invokes. Could you check if you have that enabled or disabled? I haven’t heard of a regression like that yet.
Anthony
ah ok. Testing that!
Im guessing its this one? ¨
Any potential pit falls? I mean the render thread is singlethreaded. Only if we keep references to collision outside of the method we should see problems?
Exactly. The intended way to go forward with this flag is to always make a copy of the data you want to use from outside of the callback. As long as you’re doing that, should be pretty safe.
This sounds crazy useful, I didnt even realise it was out yet! Maybe a blog post about how to use this should be made, and the official manual + scripting docs should be updated to recommend this usage over default to ensure others do not miss it too.
Yeah, we dont use the collision reference outside the collision method. Seems pretty edge case todo that.
I think its enabled by defualt for new projects. It was not enabled in our project that started its life on Unity 5
Btw, I agree the reference manual for the 3 collision methods should be updated to reflect this change.
As others mentioned, it’s the default setting for all new projects since we shipped this flag. I had it mentioned in the official blog post for 2018.3 here: https://blogs.unity3d.com/2018/11/12/physics-changes-in-unity-2018-3-beta/. However, should totally update the doc entries for the callbacks. Thanks!
Just had a little smile remembering the good old Unity 5.0 days, and shipping the PhysX 3 upgrade.
The Unity 5 days for us was broken mixed mode lighting
As to the future of those callbacks, I’d love to introduce some sort of raw access to the contacts buffer for users to iterate really, instead of subscribing like we do right now. There are plenty of potential perf savers here. Design-wise, something like this: Experimental contacts modification API - Unity Engine - Unity Discussions
I wish we could subscribe to these methods more lightweight than being a monobehavuour. We have sorted it with having a component that only does the collision subscription and then bubbles this. So if you need to listen to collison you add this component.
Yes, that’s exactly the design with contact modification in another thread I linked to. You just supply a pure function callback to be invoked off the main thread to iterate and change the impulses, points etc. In the case of just reading contacts, it could be even simpler than that – just an accessor to the internal buffer of contacts that is not copied anywhere unlike right now.
Additionally, I’m looking into exposing a thread-safe static function to generate contact points between two shapes at given poses, based on this: PhysX/physx/include/PxImmediateMode.h at ae80dede0546d652040ae6260a810e53e20a06fa · NVIDIAGameWorks/PhysX · GitHub.
Essentially, you’ll be able to call that from a job, for instance.
Solid idea. Most cases just wants the event (and maybe the collider it collided with). Others also need the force. like
public void OnCollide(NVRHand hand, Collision col)
{
if(IsLockedBack)
{
var force = Vector3.Project(col.relativeVelocity, SlamDirection.up);
var angle = Vector3.Angle(SlamDirection.up, col.relativeVelocity);
if (angle < 60 && force.magnitude > 0.25f)
{
ReturnSlide();
hand.ForceGhost();
}
}
}
Very edge case to need contact points
@yant while I have your attention. You (You as in Unity) changed so that toggle iskinimatic true/false triggers/exit callbacks. Fine, I dont agree on this, it has not left trigger only toggled iskinimatic state. So I think its wrong from a domain standpoint,
But whats more confusing. If I enable a gameobject that happens to be inside a trigger the enter trigger callback fires. But if I disable the gameobject while inside a trigger it does not call the exit trigger callback. Thats not a very consistent behavior