Search Unity

  1. Get all the Unite Berlin 2018 news on the blog.
    Dismiss Notice
  2. Unity 2018.2 has arrived! Read about it here.
    Dismiss Notice
  3. We're looking for your feedback on the platforms you use and how you use them. Let us know!
    Dismiss Notice
  4. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  5. Improve your Unity skills with a certified instructor in a private, interactive classroom. Learn more.
    Dismiss Notice
  6. ARCore is out of developer preview! Read about it here.
    Dismiss Notice
  7. Magic Leap’s Lumin SDK Technical Preview for Unity lets you get started creating content for Magic Leap One™. Find more information on our blog!
    Dismiss Notice
  8. Want to see the most recent patch releases? Take a peek at the patch release page.
    Dismiss Notice

Feature requests for physics in Unity

Discussion in 'Physics' started by PhilSA, Jan 24, 2018.

  1. PhilSA

    PhilSA

    Joined:
    Jul 11, 2013
    Posts:
    892
    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?
     
    Last edited: Jan 25, 2018
    Edy likes this.
  2. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    22,538
    Also interested in this one in regard to performance.
     
    GameDevCouple_I likes this.
  3. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    181
    Thanks. I'm a bit busy right at the moment, and probably have to return back with a more thorough description, but in short there is this big task on-going where we try to bring you PhysX 3.4 update in the best possible quality. Once done, there is a whole lot of interesting things we'd be pushing out. Immediate mode. Speculative CCD. More async query types. Being more ECS (and thus job/thread) friendly. Less dependences on Components/GameObjects. Multi-scene simulation. Stuff like that is coming, stay tuned for more.
     
  4. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    284
    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.
     
    lauhonyeung likes this.
  5. UziMonkey

    UziMonkey

    Joined:
    Nov 7, 2012
    Posts:
    206
    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.
     
  6. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    284
    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.
     
    UziMonkey likes this.
  7. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    22,538
    @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.
     
  8. UziMonkey

    UziMonkey

    Joined:
    Nov 7, 2012
    Posts:
    206
    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.
     
  9. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    181
    Indeed, we exposed contact offset settings some time around Unity 5.0, which was out in 2015 I recall.
     
    hippocoder likes this.
  10. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    22,538
    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?
     
  11. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    181
    It's a pretty good idea honestly, and I hope we can do that soon. Just need to come up with a good API that doesn't go through OnContactEnter/Stay/Exit stuff that's impossible to implement allocation-free at this moment in time. It would be something like an iterable NativeArray of contacts.
     
  12. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    22,538
    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 likes this.
  13. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    284
    @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).
     
  14. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    284
    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 :)
     
    Antypodish likes this.
  15. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    181
    18.3 beta should come not long from now. You get BoxCast, SphereCast & CapsuleCast. Only the single-result stuff for now as we're figuring a good way to expose the multiple-result ones in the meantime.
     
    rizu likes this.
  16. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    284
    @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 :D
     
    Last edited: Aug 19, 2018 at 10:50 AM
  17. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    181
    It's my understanding that the demand for convex sweeps was rather low-ish, that's why we don't yet have a variant for that.
     
  18. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    284
    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.
     
  19. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    181
    I think you're right.
     
  20. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    22,538
    Any news on the mesh collider -> multiple convex? I guess it will come in 2019.x but still hoping it is in the roadmap :)
     
  21. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    181
    This thread's turning into an unofficial "ask anthony about the upcoming features channel" :) Kidding ofc.

    I can't confirm dates on this one, unfortunately. Sorry about that.
     
    hippocoder likes this.
  22. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    22,538
    Because you are our only hope obi wan :)
     
    Edy likes this.