Experimental build with the PhysX 3.4.1 upgrade

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

 

https://twitter.com/AnthonyYakovlev/status/1015938287243005952

 

Let the regressions begin...

Spoiler

 

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.

 

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.

 

Where to turn on the ‘enhanced determinism’ flag?

 

This issue still persists in the Experimental Build. Is it too late to correct that?

 

if possible, that would be great, yant. Thank you very much!

 

ohhhh, as far as I know, anyway. WE need #fix_wheels_&&_suspention; && one more one. more thing, one more thing : ну сделайте демку танка с тем как поворачивает настоящий танк, а он тормозит одной гуссенницой посмотрите кокой этот wheel коллайдер бесполезный и вообще ниодной игры с ним не вышло нормальной, все костыли пишут

 

We prefer using english on these forums, here's what google translate gave as transtalation for the later half of your message:

 

@yant is PhysX 3.4 still on track for 2018.3?

 

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.

 

@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.

 

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?

 

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.

 

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.

 

Setting target velocity for dynamic conveyors like this:

The SetPosition / MovePosition trick only works on kinematic rb.

 

@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).

 

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.

 

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).

 

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.

 

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 :|

 

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.

 

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...

 

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

 

Look!
This dev, whose system I use ate the very bottom of my code has ilustrated the issue.
https://twitter.com/chobi_luck/status/1034415765254893569

 

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.

 

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.

 

I'm testing and reporting already, got to say I'm overwelmed by the ammount of issues with the preafabs system.

 

Any info on if we'll be getting any of the new Vehicle related 3.4 features?

 

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

 

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.

 

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.

 

Looks like the whole vehicle system has been overhauled in 3.4, I wish we could get all of those mentioned features.

 

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

 

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:

2018.3:

 

If this issue is new to 2018.3 beta, then it's from advantage if you post that information in the beta forum:
https://forum.unity.com/forums/2018-3-beta.163/

 

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.

 

@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)

 

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.

 

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 ?