Feature requests for physics in Unity

I really like how the development of Unity physics has been going ever since 5.6. ComputePenetration(), ClosestPoint(), Simulate(), manual transform sync, kinematic contact pairs, multibox pruning, etc.... have allowed me to solve many long-time problems I've had with Unity physics

However I still have a list of features that I think would be extremely useful:

• Physics.Sweep(shape, pos, rot, direction, distance, layers, ...)
  I often find myself in a situation where I'd need to sweep test with a convex mesh (a cylinder, most of the time), and this would allow me to accomplish that. This is much different from Rigidbody.Sweep because it can start at a specific pose, and it is not tied to the rigidbody's collision layers or to all of its possible child colliders. It also doesn't have the overhead of requiring a Rigidbody component. A SweepNonAlloc() version would be necessary too.
  The "Shape" parameter could be a new unity struct/class representing a PhysX shape, or just a Collider component if "Shape" would require too many changes
• Physics.Overlap(shape, pos, rot, layers, ...)
  Similar to the point above, although not as crucial because it could always be replaced by an OverlapBox + a ComputePenetration. But it could be used to overlap test with convex meshes
• Immediate mode
  ComputePenetration has served me very well in my projects and I am eternally grateful for it, but there are cases where I'd need to have the actual contact points of an overlap at a specific moment in the frame, which I cannot get. Immediate mode would give me that possibility
• Jobifiable physics API
  This is more of a question than a request, but I wonder how job-compatible unity physics is? Even if actual physics queries are not easily jobifyable, I could still get some massive performance gains if I could get/set rigidbody.position and use rigidbody.MovePosition() through jobs. I guess this would require some kind of "RigidbodyAccessArray"?
• Expose generic Heightfield Colliders to allow Unity users to build their own custom terrain systems
  I'm actually unsure about this one. PhysX documentation seems to suggest that heightfield colliders are now basically the same as concave mesh colliders in terms of calculations. Is that really true? Is the performance cost really the same?

@yant I'd be curious to hear your thoughts on these points, if you could spare some time.

PS: any updates on the rigidbody interpolation bug?

 

Also interested in this one in regard to performance.

 

I only now saw this, if you bring out PhysX 3.4, could you please consider using 3.4.1 and implementing PhysX Collision Modification callbacks for the Unity API so we could finally modify these special collision cases outselves?

The ability to spoof the collision data is priceless: for example when the lean the vehicle towards railing at high speed and you hit the collider seam there, this is classic example you see on many indie racing games where vehicles just bounce to the sky etc as they couldn't solve it properly. Or just think of any other surface leaning object when it reaches collider seam and physx interprets one of the collision pairs contact point as 90 degree normal, another classic example for this is when you do any kind of rolling ball and have a level that has modular ground objects, ball is prone to bounce on parts where colliders has seam/overlap (I'm aware of the workarounds for this with changing contact offsets or using customized collision shapes for situation like these but it's not always easy or feasible solution to do at full project scale). Or ability to limit the collisions impulse on objects that aren't supposed to be 100% rigid (yes, you can do softer collisions with these too). There just are countless edge cases that would be much harder to solve with traditional workarounds. Also the reason why I request 3.4.1 to be used is that it exposes additionally friction and restitution mods for contact modifications.

At the moment, if you want to have similar control over collisions with Unity and PhysX, you'd have to use shadowed collision triggers for object pairs that you want to have custom collision with and then implement the collision resolving yourself for those, but this is out of reach solution for most of the users here. It also requires way messier setup as need to implement additional kinematic rigidbody with that trigger that follows your actual dynamic rigidbody. Also setup like this would only work with few edge cases, otherwise the complexity of the setup could just get out of hands.

 

Do you have any more information on this? I'm trying to solve this very problem. I tried to go with a simplistic controller with just a PhysX ball controlled with AddTorque and it's working so well except for this one thing.

I did actually solve this before, but in a rather insane way. I was making levels in Blender and had a script to create colliders from the blocks that I was putting together. It would go through this long sequence of Blender commands to copy all the level data, combine them all, remove internal faces, decimate the meshes, separate up-facing faces and finally create a bunch of contiguous colliders without seams. I was hoping to make levels directly in Unity this time though, and am looking for a more organic solution to the seam problem.

 

As long as we don't have contact modifications available and you want robust movement, implement the ball physics yourself and use only physx queries to check for it's collision. Good thing is, sphere is the easiest shape to implement.

If you have to keep using physx simulation for the ball, then your options are somewhat limited, you can try minimizing Project Settings->Physics->Default Contact Offset, it's set to a relatively small value already on recent Unity versions at least (0.01 on Unity 2018.2), you can try putting like 0.00000001 there and see if it helps (you can't set zero). When you change this, physx will not try to solve collisions further away, which leads to less false data fed from the collision seams.

Additionally, you could fix all your collider shapes manually when it's known you'll have a tiled shapes there, having 90 degree wall on the border (cube) or flat plane that just stops on the seam is worst case scenario. In such case physics engines can't always interpret what's going on as they get only single frame of physics data at the time. So if you have like flat plane, make a collider that extends it a bit but so that extending polygons are bent a bit downwards, this will create a small ramp and prevent physics engine mistaking it bumped the ball into 90 degree wall there. Make sure that you sink and overlap the bent parts so that seam would go on the leveled part only. Same trick applies to cubes, make small ramp after where they should end normally, it probably don't even need to be long.

If we had physx contact modifications, we could just examine the collision data and normals for the shapes we know will cause issues and simply ignore or spoof the bad data to make the problem goes away.

 

@rizu Currently my character is a rigidbody based where I set the velocity manually and rely on ComputePenetration to determine "contacts about to happen". When a wall is found, I manipulate the velocity to prevent sliding up the wall, and allow the Physx solver to fix everything else. I think your suggestion would probably allow me to just use and modify the contacts directly.

 

Thank you for this. I actually discovered this messing around with the physics panel tonight but had no idea what it did. I want to say this setting wasn't there in the previous rolling ball game I worked on in ~2015 or I wouldn't have spent 2 days writing that Blender script, but setting it to nearly 0 does the trick. I haven't seen a single skip and in the primitive test levels I have now I don't see any adverse effects.

 

Would it be a good or bad idea to expose the contacts themselves so we can do our own manipulation (for example I might alter the normals so that a rigidbody naturally acts as a character controller). Would it be poor performance?

 

That sounds pretty awesome actually. I love how Physx works, and only really need to nudge it to the behaviour I need. Currently need to replace more of it than I should.

The whole On-Stay etc stuff is so tiring, most of my code pain working with physics is indeed avoiding that too.

 

@yant Most painless way to setup this in Unity would be IMO to:

- first expose a boolean for each rigidbody you want to use contact modifications, which will internally adjust the physx filter for the same thing
- have a boolean in project settings for including contact modify callback for physics scene creation
- setup internal contact modify callback so that when it gets called, you only convert the PhysX contactmodifypair data into NativeArray (etc) having custom ContactSet for each pair as entry for that array. This would replicate the actual PhysX callback and work exactly the same, only difference is that you'd need to reconstruct the contactset so that you get the PhysX stuff like PxActors wrapped to use Unity rigidbodies instead
- make wrappers for accessing the contactset itself, how PhysX itself exposes these are bit silly (you'll know what I mean when you look at the relevant code) but you can for example have single setter and getter for each thing you want to access and have the pair index as parameter to simplify the API.
- at this point, users could just get a single OnContactModify etc and iterate the provided array of contactsets from there as they see best (using those wrapped contactset accessing methods).

Main issue on the NativeArray thing is that to actually use the contact sets, you need to call functions from PhysX api and I'm not sure if you can actually do it multithreaded manner (I have zero clue if the internal contactset is isolated thing that you can access from threads). Of course you could still iterate that NativeArray from single worker thread at a time (which honestly wouldn't be all that bad idea for a special feat like this).

Alternatively one could cache all the actual data inside the contactset into Unity specific C# structure but that could be heavy and mean a lot of allocations (I'm not very experienced on dealing with the managed <-> native border so I could be mistaken here), but if one did this, you'd probably want to modify physx a little to get the raw data faster than going through individual getters and setters for all the contactpoints data (normals, separation, position etc).

 

As totally different thing, has there been any mention on what new physx queries will be exposed to job system on 2018.3? I know you get raycastcommand now but would love to get overlap checks and sweeps too

 

@yant I realized that Unity doesn't even have separate sweeps on convex, nor is there an overlap check for such. PhysX itself supports box, sphere, capsule for both sweeps and overlaps.

EDIT-> https://docs.unity3d.com/ScriptReference/Rigidbody.SweepTest.html supports also convex so this could be used as workaround (proper ConvexCast/OverlapConvex would still be handy). Ok, next question, could the SweepTest be jobified?

EDIT 2-> I forgot that PhilSA already requested convex sweeps and overlaps on original post

 

I do get that you guys have to prioritize but for physics side, people who actually needed more exposed out of Unitys PhysX implementation has always had to move to third party physics engine integrations for small missing things on built-in integration.

This has always been a painpoint with Unity on my use, hence finally asking for more advanced feats (I'm still using Bullet on my project for reasons like this). I guess it's same for this threads original poster @PhilSA as he started making his own ECS physics engine instead of waiting for Unity add more things from PhysX side.

Convex sweeps would be super handy for anyone doing custom physics stuff. Sure, for most movement controllers, box, sphere and capsule are enough but there are cases where you need something more elegant, like if you do custom solvers for vehicles and want to manually check the collisions, now you are limited to Rigidbody sweep or need to rely on built-in events which complicate this kind of code a lot.

 

Any news on the mesh collider -> multiple convex? I guess it will come in 2019.x but still hoping it is in the roadmap

 

Because you are our only hope obi wan

 

@yant
I just recently learned that the contact modification is actually possible in Physx and I think it would really be a great addition to the unity API.
So I wanted to chime in and ask whether adding the contact modification to the Unity API has been considered in the meantime and if so, whether you have any idea when the work will be started or available for testing in an alpha?

 

@lmakor I've been asking the same here for a quite good while but there hasn't been any promises if it'll arrive. We do have a feature request here:
https://feedback.unity3d.com/suggestions/physics-contact-modification

This level advanced physics features will never attract that many users so vote counts tend to be small. Then again people who need this stuff will be left out and have no other option to make crazy workarounds or use something else than built-in physics engine.

IMO in cases like these it shouldn't be about catering the majority of the userbase but providing support also for teams that need more exposed out of PhysX to be able to achieve the best quality for their titles (this would also increase Unity's reputation on being able to support more advanced physics games).

 

@rizu Yeah, I know, I also vote for that feature today.

I don't expect too much, but maybe yant can surprise both of us