Search Unity

  1. Calling all beginners! Join the FPS Beginners Mods Challenge until December 13.
    Dismiss Notice
  2. It's Cyber Week at the Asset Store!
    Dismiss Notice

Experimental build with the PhysX 3.4.1 upgrade

Discussion in 'Physics Previews' started by yant, May 7, 2018.

  1. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    256
    Wooo! On a slight sidenote thanks for all your hard work, it doesn't get said enough, but i'm always grateful for all the work you peeps do making cool stuff for us. Even if our first reaction tends to be to ask for more stuff X3
     
    yant, Kirsche and JimmyCushnie like this.
  2. JakubSmaga

    JakubSmaga

    Joined:
    Aug 5, 2015
    Posts:
    416
  3. Peter77

    Peter77

    Joined:
    Jun 12, 2013
    Posts:
    4,252
  4. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,217
    While moving to newest PhysX is tad risky, it's important to understand that PhysX 3.4.0 was released in Spring 2017 and even then it had been used for two major UE4 versions in pre-release state. UE4 users got a lot of early adopter bugs but most of those issues have been fixed along the way. Changes in 3.4.1 and especially in 3.4.2 are minor, they had to bump the version numbers due to small API changes so I wouldn't be worried about going into latest there, they got most of the bug fixes too.
     
  5. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,217
    Additionally, 2018.x cycle is bound to be less stable as previous Unity versions anyway due to the large changes underneath so throwing latest PhysX in the mix now rather than later is probably a good idea as they got whole 2 years of LTS to fix the remaining bugs and that way 2019 will get more solid start.
     
  6. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    337
    Based on the feedback from the users who tried the upgrade on 18.2 during the closed alpha testing, as well as during the 18.2 open beta cycle here in this thread and the ones who I sent the build directly to, I wouldn't expect any big problems to be honest. However, if anyone feels like some particular thing exposed in the build above is causing issues -- please do speak out, we still have some time to address that before too late. Thanks for your help.
     
    JimmyCushnie and matteumayo like this.
  7. lauhonyeung

    lauhonyeung

    Joined:
    Apr 29, 2017
    Posts:
    17
    Where to turn on the ‘enhanced determinism’ flag?

     
  8. nikescar

    nikescar

    Joined:
    Nov 16, 2011
    Posts:
    102
    This issue still persists in the Experimental Build. Is it too late to correct that?
     
  9. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    337
    Check out the physics settings in the editor please, it's right in the bottom of the list.
     
  10. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    337
    I think that plan is to make an iteration on cleaning up the joints code later. Get on that, and re-write some old historical code that deals with anchors, activation and deactivation. Perhaps, would make it into 19.1. However, things you are talking about are more or less by-design in physx, unfortunately. The first one for sure. I have your report on the list of todos btw, but thanks for the heads up anyways.
     
  11. nikescar

    nikescar

    Joined:
    Nov 16, 2011
    Posts:
    102
    if possible, that would be great, yant. Thank you very much!
     
  12. 2pa

    2pa

    Joined:
    Nov 8, 2013
    Posts:
    4
    ohhhh, as far as I know, anyway. WE need #fix_wheels_&&_suspention; && one more one. more thing, one more thing : ну сделайте демку танка с тем как поворачивает настоящий танк, а он тормозит одной гуссенницой посмотрите кокой этот wheel коллайдер бесполезный и вообще ниодной игры с ним не вышло нормальной, все костыли пишут:(:(:(:(:(:(:(:(:(:(:(:(:(
     
    Last edited: Aug 5, 2018
  13. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,217
    We prefer using english on these forums, here's what google translate gave as transtalation for the later half of your message:
     
  14. JimmyCushnie

    JimmyCushnie

    Joined:
    Jun 7, 2017
    Posts:
    66
    @yant is PhysX 3.4 still on track for 2018.3?
     
  15. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,217
    They haven't removed it from 2018.3 roadmap at least and there would have to be a huge showstopper for them to back off from the plan of converting into physx 3.4 on 2018.3. Work for this has been ongoing for a long time already so if they had to postpone it, it would mean a lot of work getting redone and it would have been likely that we would have been informed for it too as its not a small change.

    First 2018.3 betas should arrive any time soon (this month) so then we'll know for sure.
     
  16. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    337
    FWIW - PhysX 3.4.2 made it to 2018.3, it's going through the alpha testing stage now. Open betas should come shortly. Thanks for your interest in physics.
     
    matteumayo and JimmyCushnie like this.
  17. goncalo09

    goncalo09

    Joined:
    Oct 26, 2017
    Posts:
    5
    @yant Nice work. Thanks!
    I also want to emphasize that having access to contact modification would be a really great addition for the future. It's the reason why we had to use Bullet instead.
     
    Cynicat likes this.
  18. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    337
    Could you elaborate why do you need contact modification? Buoyancy? Sticky constraints? How would you imagine using that in Unity?
     
  19. strich

    strich

    Joined:
    Aug 14, 2012
    Posts:
    282
    Sounds great, thanks for the hard work! Could you confirm whether all 3.4.x features are included such as the new wheel physics, or just the ones tested here?
     
  20. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    337
    Only the ones tested in this thread I think. It was planned to be light on the features and to ship exactly what was tested and confirmed to work (see the beginning of the thread).
     
    JimmyCushnie likes this.
  21. strich

    strich

    Joined:
    Aug 14, 2012
    Posts:
    282
    Yeah I figured that would be the case. Would be great to see those features come in after 2018.3 - one of my projects is on hold indefinitely until modern wheel physics are in.
     
  22. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    337
    What makes you think the 3.4's additions to wheel collider make it so much more modern? Shape-casts instead of raycasts?
     
  23. strich

    strich

    Joined:
    Aug 14, 2012
    Posts:
    282
    Correct. Modern was the wrong word. Without shape casts bigger vehicles in a game with rough surfaces is just not an experience you can develop without a lot of hacky work arounds.
     
    JimmyCushnie likes this.
  24. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    337
    Yes, makes sense. Thanks.
     
    JimmyCushnie likes this.
  25. goncalo09

    goncalo09

    Joined:
    Oct 26, 2017
    Posts:
    5
    Setting target velocity for dynamic conveyors like this:

    The SetPosition / MovePosition trick only works on kinematic rb.
     
  26. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,217
    @strich besides new suspension sweeps and antirollbar, there's example of doing contact modifications for the wheels (which seems even more niche feat to have vs regular contact modifications). Rest of the PhysX 3.4 vehicle changes are small tweaks, but in general your physx vehicle should feel somewhat the same as before (so don't expect miracles).
     
  27. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,217
    Why would those only work on kinematic rb? I quickly tried putting a trigger box right above the plane surface and attached following script to it:
    Code (CSharp):
    1. using UnityEngine;
    2.  
    3. public class Conveyor : MonoBehaviour {
    4.     public Vector3 conveyorSpeed = new Vector3(0, 0, 2);
    5.  
    6.     private void OnTriggerStay(Collider other)
    7.     {
    8.         other.transform.position += conveyorSpeed * Time.deltaTime;
    9.     }
    10. }
    this works just fine on my testing with dynamic rigidbodies and dynamic collisions between them on the belt. I do admit that doing this on contact modifications would probably be tad more robust though.
     
  28. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    337
    FWIW - MovePosition on a dynamic rigid body will just directly set new pose to physx. Kinematic targets are only for, well... kinematic bodies.
     
  29. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,217
    also worth noting that docs imply that Rigidbody.MovePosition and transform.position do the same thing if you have isKinematic set to false. Manually moving dynamic rigidbodies will have it's issues but for slowly moving conveyor belts, this is probably not an issue (PhysX will have enough time to solve clipped collisions on next simulation pass without things visually glitching).
     
  30. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    256
    Just being able to read contacts would be good. Currently there is no reliable way to get how many objects a rigidbody is touching. since exit messages don't fire on destroyed or disabled objects. there really is no way to accurately acess collisions. one example for my own use case is i have an element system where elements can effect eachother/the world, this requires accurate enter and exit messages, i currently use expensive physics overlap checks to guarantee i know what is effected by an element, this limits me to primitives, while also harming my performance a lot due to the lack of overlap check multithreading. contact lists would be nice.
     
    yant likes this.
  31. TokyoWarfareProject

    TokyoWarfareProject

    Joined:
    Jun 20, 2018
    Posts:
    503
    I'm updating a unity 4.7 project. In there vehicles had a joing structure for suspension wheel sim. All did run smooth at time0.03. In 2018.2 runs like crap once vehicles get some speed and I've to lower timestep to 0.02 to get rid or bouncing wheels.

    Tested the experimental editor and I'm impressed. No flaws with 0.04 or 0.04 timesteps. You can even abuse to 0.08 and while obviously vehicles will jitter, the crazy joint issues are gone.
    Sadly, I won´t be able to use this on time as I'm targeting Xbox platform with release date in less than 2 months :|
     
  32. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,217
    AFIK, Unity 4 used PhysX 2.8 which had very different solvers. I'm surprised to hear that 3.4 made such dramatic difference over 3.3 as I don't remember noticing similar thing myself.
     
  33. TokyoWarfareProject

    TokyoWarfareProject

    Joined:
    Jun 20, 2018
    Posts:
    503
    Itsi night & day. I wish I was not in a rushh and I could document but imagine the wheels of tanks jumping in all dir chaotically once they start to spin at somewhat high speed, all the tank bouncing .... absolute break filling. That with 0.03 timestep, ok with 0.02. But absolutelly clean with 0.03 & 0.04 timesteps with this experimental editor build. Absolute same project, copy paste the project folder and open in the experimetnal bild. (got to say that the lack of regression issues was a breeze, I had to switch platform as experimental editor supports no consoles so I lost some precious time in the switch... :p
     
  34. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,217
    I can imagine, I've done numerous prototypes with joint based vehicles as well. Most robust solution (if you absolutely need to use use joints) is to not rotate the wheels at all on physx but handle the wheel rotation on code, like you would do with raycast suspension and only animate the spinning while wheel rigidbodies slide with 0 friction (this also lets you do proper tire friction where spinning physx cylinders/spheres can give pretty undeterministic grip levels due to how they work). It probably still can work for slowly moving things like tanks though.

    Again one thing that would help on rigidbody on rigidbody dynamics is that already mentioned contact modifications (which we don't have atm with Unity) as with it you can filter violent collisions and smooth the ground contact a bit with it :)
     
    Last edited: Aug 27, 2018
    TokyoWarfareProject likes this.
  35. TokyoWarfareProject

    TokyoWarfareProject

    Joined:
    Jun 20, 2018
    Posts:
    503
  36. TokyoWarfareProject

    TokyoWarfareProject

    Joined:
    Jun 20, 2018
    Posts:
    503
    Tested 2018.3, nice mess. The new prefab workflow is gonna cause plenty of pain on upgrading projects.

    Please avoid us the paing and release one last 2018.2 with 3.41 or 3.42.
     
  37. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,217
    2018.3 is just entered beta, it doesn't reflect the quality what we get when it finally releases. If you don't want to try early version and can''t accept it may have issues, just wait for the final version. Otherwise, do test and report the issues you have so Unity can actually fix them.
     
    JimmyCushnie likes this.
  38. TokyoWarfareProject

    TokyoWarfareProject

    Joined:
    Jun 20, 2018
    Posts:
    503
    I'm testing and reporting already, got to say I'm overwelmed by the ammount of issues with the preafabs system.
     
  39. Lahcene

    Lahcene

    Joined:
    Jun 18, 2013
    Posts:
    24
    Any info on if we'll be getting any of the new Vehicle related 3.4 features?
     
    strich likes this.
  40. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,217
    If they arrive, that will happen on 2019 cycle earliest, yant has told many times that 2018.3 will keep new physics feats to minimum (I think to make smoother transition from PhysX 3.3.3 to PhysX 3.4.2).

    As for the PhysX vehicle improvements, there are at least two things I can imagine people would want:

    - antirollbars
    - contact mods and sweeps for the wheelcolliders as alternative to raycasting
     
    Lahcene likes this.
  41. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,217
    I personally still wish following will appear in some form at some point:

    - support for contact modifications in general
    - convex overlap and sweep checks, preferably with job system support

    Until at least contact mod support is there, I can't even consider built-in physics myself.
     
  42. TokyoWarfareProject

    TokyoWarfareProject

    Joined:
    Jun 20, 2018
    Posts:
    503
    Whant to report that , 3.4.1 was regression free, 3.4.2 after manually fixing the minimum number of prefabs for my test project "run" it seemed to drop no issues either, yet I did was not able to notice the performance boost due to a new issue related to UI I'll be reporting.
     
    Lahcene likes this.
  43. Lahcene

    Lahcene

    Joined:
    Jun 18, 2013
    Posts:
    24
    Looks like the whole vehicle system has been overhauled in 3.4, I wish we could get all of those mentioned features.
     
  44. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,217
    Sorry to correct but this is incorrect assumption. That note is explaining what happened from PhysX 2.8 to PhysX 3 in general. Whole vehicle system changed on PhysX 3 which is main reason why Unity 4 (PhysX 2.8) and Unity 5+ (PhysX 3.3) wheel colliders work differently. You can find the actual PhysX 3.4 release notes here: http://www.physxinfo.com/files_new/PhysX_3-4_release_notes.html

    Vehicles
    • Added:
      • Anti-roll suspension has been added. The class PxVehicleAntiRollBar and the functions PxVehicleWheelsSimData::setAntiRollBar, PxVehicleWheelsSimData::getAntiRollBar, PxVehicleWheelsSimData::getNbAntiRollBars allow anti-roll bars to be configured and queried.
      • A new function PxVehicleSuspensionSweeps has been introduced. This sweeps the PxShape that represents the wheel along the suspension direction. The hit planes resulting from the sweep are used as driving surfaces similar to those found by PxVehicleSuspensionRaycasts.
      • A new snippet SnippetVehicleContactMod has been added. This snippet demonstrates how to use sweeps and contact modification to allow the wheel's volume to fully interact with the environment.
      • A new function PxVehicleModifyWheelContacts has been introduced. This function analyses contact in the contact modification callback and rejects contact points that represent drivable surfaces.
      • A new function PxVehicleSetMaxHitActorAcceleration has been introduced. This function sets the maximum acceleration experienced by a PxRigidDynamic that finds itself under the wheel of a vehicle.
    • Changed:
      • In checked build the functions PxVehicleDrive4W::allocate, PxVehicleDriveNW::allocate, PxVehicleDriveTank::allocate, PxVehicleNoDrive::allocate all return NULL and issue a warning if called before PxInitVehicleSDK.
      • Tire width is no longer accounted for when computing the suspension compression from raycasts (PxVehicleSuspensionRaycasts). Instead, tire width is incorporated into the suspension compression arising from swept wheels (PxVehicleSuspensionSweeps). It is recommended to use PxVehicleSuspensionSweeps if there is a strict requirement that the inside and outside of the wheel don't visibly penetrate geometry.
    • Fixed:
      • Suspension force calculation now applies an extra force perpendicular to the spring travel direction. This force is calculated to satisfy the constraint that the sprung mass only has motion along the spring travel direction. This change mostly affects vehicles with suspension travel directions that are not vertical.
      • PxVehicleWheelsSimData::mThresholdLongitudinalSpeed and PxVehicleWheelsSimData::mMinLongSlipDenominator are now given default values that reflect the length scale set in PxTolerancesScale.
      • Unphysically large constraint forces were generated to resolve the suspension compression beyond its limit when the suspension direction and the hit normal under the wheel approach perpendicularity. This has been fixed so that the constraint force approaches zero as the angle between the hit normal and suspension direction approaches a right angle.

    While this list may seem long at first, these won't change the vehicle handling that dramatically. Key points are those two things I mentioned earlier.

    Unity only implements the suspension and tire physics from PhysX vehicles and not the whole vehicle model (which is optional with PhysX 3 vehicles). UE4 does the whole thing and it's a huge issue for UE4 users as it makes the whole thing even more hardcoded (https://forums.unrealengine.com/unreal-engine/feedback-for-epic/19243-horrible-car-physics). I think Unity made the right call here by letting users implement the actual vehicle engine and drivetrain themselves as it gives more freedom on implementation.

    There is a feature in PhysX vehicles that isn't exposed in Unity WheelColliders that could help a bit called Tire Shaders: https://docs.nvidia.com/gameworks/c...physx/guide/Manual/Vehicles.html#tire-shaders. Tire shaders were available even on 3.3 that Unity used between 5.0 and 2018.2, but I do get it might be difficult to expose these efficiently as it's a really low level change. Exposed tire shader would allow people to change the tire physics altogether instead of relying on that super simplified tire model they have there now.

    But in the bigger picture, the tire physics is just one thing, a lot of the implementation isn't that great when you do need more control over things: it makes no sense in building state of art tire model there but still keep the somewhat linear and not actually physically correct suspension model from PhysX vehicle implementation.

    IMO, if wheelcolliders aren't good enough for your purpose, just implement the similar functionality yourself and you can get full freedom what you can do with the system. Expecting WheelColliders to suddenly get superior now that Unity is using PhysX 3.4.2 is only setting you in for another disappointment: it's not going to fundamentally change things even if Unity implements the new inclusions. This is why I gave similar advice at https://forum.unity.com/threads/let-us-do-our-job-please-wheelcollider.559147/#post-3707185 to @2pa and @Deeeds
     
    Edy, Lahcene, yant and 1 other person like this.
  45. KillHour

    KillHour

    Joined:
    Oct 25, 2015
    Posts:
    27
    Has anyone actually noticed a physics query slowdown? After updating to 2018.3.0b3, I actually had a very severe slowdown of about 2 orders of magnitude when doing physics queries. I made a report here:

    Fogbugz #1086243

    2018.2:
    physics 2018.2.PNG
    2018.3:
    physics 2018.3.PNG
     
    Last edited: Oct 1, 2018
  46. Peter77

    Peter77

    Joined:
    Jun 12, 2013
    Posts:
    4,252
    KillHour likes this.
  47. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,217
    He did post benchmark of 2018.2 vs 2018.3 so it's pretty safe to assume the regression happened on move to 2018.3.
     
  48. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,217
    @KillHour you may want to only tell the fogbugz issue number here instead of the link. Once Unity replies to you, that direct link will show your real email address there (just mentioning this in case privacy is important to you)
     
    KillHour likes this.
  49. TokyoWarfareProject

    TokyoWarfareProject

    Joined:
    Jun 20, 2018
    Posts:
    503
    I also noticed slow down on spherecast but thought it was due to project running poorly due to the many import issues of the b1. Hope I can re export for testing to try in b3 or b4.
     
  50. TokyoWarfareProject

    TokyoWarfareProject

    Joined:
    Jun 20, 2018
    Posts:
    503
    Upgrading from unity 4.7 I've discovered that physic material no longer allow per axis friction. Wth!! Is it possible to bring this feature back on 2018.3 ?