Assets NWH Vehicle Physics

Could map brake/accel to the gamepad triggers? I can't test it properly the way you have them bound to the left joystick which is also steering. Not possible to test brake/accel use together either, which is a key driving technique.

 

Due to Unity failing to fix its SerializeReference problems (of which are about 7 right now: link to that thread)
and NVP2 using SerializeReference for its module system (SerializeReference allows for derived types to be added to a list without casting them to the base type) I am left with two options:

1. Trust Unity that they will fix SerializeReference soon. Has not happended over last 5 months I have been developing the asset and despite them working on some major issues ETA is not known - thread in the link above.
   
2. Move the module system to Unity's component system (modules would be MonoBehaviors) and lose all the benefits of the integrated module system - namely copying does not require copying all the modules, using the base VehicleComponent class for every vehicle component (including modules) so the code is unified, performance improvements and better control over code.

Unfortunately, it will be most likely second option as that would also allow for me to roll back required version to 2018.4 and that will take a few days of development time since the modules are finalized at the moment and taking that part of code apart will not be too fun.

Thankfully the miniature inspector GUI framework that was developed for the asset allows for easy embedding so the look of the editor will be kept about the same with the access to all the modules in one place (you can see the warning for one of the Unity bugs at the top, ignore that):

 

Unity has this tendency to start working on a dozen major new features and then it takes years for them to actually be implemented properly. Just look at HDRP, it was around since 2018 (or even 2017?) and is nowhere near stable, still being completely changed constantly, to the point where most asset devs can't integrate it, otherwise it would mean they have to change everything with every update. And the list goes on with Input, Dots, ECS .. and even when they are implemented they tend to be half arsed and then move to the next major new features. Like uGUI, the JSON helper etc.

So yes, I wouldn't hold my breath they will fix it soon. Is a good thing that you messed around with it and you have the code for when is gonna be usable, but don't base your asset on a beta feature. I think 2019.3 is the buggiest version in a long time. Too many big changes packed in a single version.

Personally I don't care too much about fancy editors. Is nice to have some basic tabs so data is organized a bit instead of endless lists of variables or some managers that are easy to access from the toolbar, but otherwise I'm just interested in actually using the asset itself.

 

Just reverted to 2018.4 LTS and will stay there for the time being. Since the asset was developed in 2019.2 and 2019.3 the compatibility will also be good with those two and as you said the code is there so when Unity sorts it out, and as you said that will probably take quite some time, I can always revert.

The issues with SerializeReference are just so severe that I really can not see it being put into production anytime soon. Some most glaring issues (how does that even pass through testing?):
- Any script that has [SerializeReference] in it and is attached to prefab instance will actually revert to its prefab values each time play mode is entered (all the fields, not just SerializeReference field).
- Any object that is in SerializeReference list will have its non-public variables reset to initial value each time any field in the whole of that object's inspector is changed. That means that if you initialize a private field at Start it will reset if you change ANY value in the inspector.
Just those two are enough to ruin a good project and therefore I can not release an asset with those two present. Besides, the benefits are not that huge so going back to MonoBehavior for modules will not really be a step down - maybe just a bit messier from the code standpoint on my side.

TLDR; Unity messed up with SerializeReference and are taking their sweet time to fix it.

Now back to work. Since many things such as Terrains can not be rolled back I have to redo the demos.

 

I'm having major Deja Vu with Unity again. The last time something this buggy and untested came out was when they ditched Unity 5 and made it Unity 2017. It was no doubt the slowest and buggiest editor to ever come out. But part of me has some faith in Unity because 2017 was dubbed one of the worst editors on release, and now it is the most solid and bulletproof version for developing on right now. 2018.1 and 2018.4 come in right behind it. The whole 2019.x lineup has had more bugs and problems than I have ever experienced in the last couple years of Unity. Even with 2017.1 being the disaster it was, I never had half the problems I did with 2019.x. I think Unity is trying too hard to catch up to engines like Unreal, CryEngine, etc too fast. They were way behind in the game engine race and are now boosting themselves with massive amounts of steroids in order to compete.

What baffles me most is that the Unity team isn't very consistent. The part of the team that handles physics or MOBILE are very responsive. Always answers threads, and fixes are pushed out quickly. But for other teams like networking or general editor, it's a desert. There are still bugs from 2018.4 that I'm fighting with in 2019.2.20f1. And then they release 2019.3 which has been the worst version to date and say it's production ready? It's ridiculous and I really hope Unity doesn't continue going down this path. Many of my dev friends are switching to Godot because of the stuff Unity keeps pulling, and I can't say I blame them.

However good luck with the changes for NVP2, I can tell it will be a great asset either way.

 

Unity QA doesn't seem to be either Quality or Assurance now. Really disappointed with the way Unity has gone downhill.

 

Will be there easy interface to override vehicle settings during runtime?

 

In which way? Of course you will be able to do something like

Code (CSharp):

1. vehicleController.powertrain.engine.maxPower = 200;

I am trying to make sure that all the fields can be changed at runtime.

If you ate thinking about the whole vehicle configuration being a scriptable object so that you can do vehicle.config = someOtherConfig then no. I did think about it a lot but in the end there are a wide variety of users and this would possibly bring more complications that it would solve problems.

 

you could convert a terrain to a mesh and then import the mesh in 2018 and convert to terrain again

 

Already did. There is the Export RAW option and it is not the first time I am doing those things (or second for that matter). Thank you for the tip anyway.

 

Great. The more then better (if it's possible). I was thinking about changing elements when:
1. user is upgrading his vehicle in garage
2. set vehicle elements like before rally stage
3. vehicle elements are depending on scripts in scene, that during game can set engine off or turn on lights automatically

 

The benefits from SerializeReference aren't that attractive for me, for me the second option is fine, this is my opinion. Also moving the modules in monobehaviours would allow to easily copy them when setting up vehicles, i suppose.

 

In your latest demo are there any toggles for any driving aids etc, I cant get the car to do doughnuts properly, is there some traction control or something to turn off so it behaves correctly?

 

It is not a demo, it is a development preview and as such changes are constantly being made. I will be releasing another one shortly so try that one. The issue should be solved.

 

I have actually managed to move the modules system to MonoBehaviour without any major architectural changes by using simulated double inheritance and MonoBehaviour wrappers. This will allow for very easy move to [SerializeReference] when that matures just by iterating over the wrappers, getting modules and adding them to a SerializeReference list. The only downside is that each module type requires its own MonoBehaviour wrapper but apart from those few lines of code everything works as it should have with SerializeReference:



And the wrapper itself:


I have also debated about drawing modules in their own editors but that has gotten irritating fast when there are many modules attached.
There is also an empty template module for easy start for those that want to make their own.

 

Here is development preview 6: link
This time with mouse controls:
- Mouse left and right - steering
- Mouse up and down - throttle and brakes
Should be a bit easier to control than with keyboard.

 

Performance testing and final optimization done.



Testing was done on 20 identical vehicles with all the components enabled on all of them and solver settings set to medium. WheelController was set to single ray.

Results per vehicle:

• FixedUpdate - 0.042 ms
• Update - 0.02 ms
• LateUpdate - 0.00 ms

So total of about ~1.24ms.

 

Has there been any improvements for the skidmark generation in NVP2?

Currently I'm getting very bad performance degradation because of skidmark generation. If you drift enough (I drifted for about 20 seconds in this picture), you can take the game down to half of it's normal frame rate. Mostly due to batches. I don't have this problem with other skidmark solutions.

Skidmarks Disabled


Skidmarks Enabled


I also sent you an email, but I don't know if you have seen it or it slipped through the cracks.

 

Could be that it slipped through as I do not remember seeing one, could be that the email is different from username.

Anyways - the skidmarks have been rewritten but if you are using persistent skidmarks it will still impact performance
as persistent skidmarks do not get deleted until the player gets far enough from them.
In v2 I have implemented FadeOverDistance option which allows for non-persistant skidmarks to fade further in the queue they get so instead of hard cut you get a smooth transition. This combined with high enough "Max Marks Per Section" value will get you better result than using persistent skidmarks with very little performance impact. Besides that there is a bug in NVP1 which does slow down skidmarks to some extent.

 

I just tried the new demo, and the driving physics seem great! It was quite odd using a mouse (I actually use a trackball...), but got used to it enough to make a full lap on my third try.

Where it is really falling short though is the collisions - it just feels like you're in a weightless balloon every time you hit anything or take a tumble. Even going off the vertical jump it looked like a balloon landing softly.

 

Noted. The collisions are standard Unity and I also noticed they are not the best. I will see what I can do. The issue seems to be the fact that the vehicle is not eating up energy by deforming as it would in real life and instead acts as a rubber object that bounces back, instead soaking up all that kinetic energy. E.g. if you hit a wall nearly head on the car would crumple and maybe bounce back a little but most of the energy is actually absorbed by the car's structure.

 

I want to override the method without modifying the NWH's code.
However, it is not easy to redefine in the current version.
I want to know if this part is improved in NWH 2 and when it will be updated.

 

Without knowing which function that might be I can not say for sure but the code was improved a lot, especially the architecture. Around 70% of it is new.

 

All these updates are looking great, do you have an estimated release date for the new version?

 

It was supposed to be 3 days ago but that did not happen so I am pushing now to be done as fast as possible. There was a setback with modules and at the moment what needs to be done is:
- Finish up multiplayer (which is 90% there)
- Make setup easier
- VehicleComponent states need some work as putting vehicle to sleep does not work at the moment.
- Documentation

 

I have managed to improve the collisions. They work much better now and the vehicle does not fly off at the slightest hint of collision at high speeds.

 

Thanks for the reply! I don't need it urgently or anything (I'm just looking forward to using it in a project) so don't push yourself too much please

 

People are expecting and waiting on the asset so I am trying to put in as much work as possible. I already had a major feature creep which postponed the release from what was supposed to be a minor update to what became a half a year update. The script count went from 75 to 224 in the meantime (granted, half of those are editor scripts) and the testing is taking a lot of time to go through all the options, combinations, etc.

 

Great, looking forward to checking it out! I can see it being partially due to the lack of absorption of energy, but it was also the simultaneous weightless feeling that I saw in the demo. I'd be interested in knowing what you had to change from the default Unity collisions (and likewise what we can tweak ourselves to customize it).

Thank you! It's very appreciated, no matter how demanding or perfectionist we sound!

 

For example, I want modify Steering class's Steer method's 3 line or replace Steering class to other class.
However, I can't do that it unless you modify the NWH code.
The reason for doing this is to remove the dependency.

Code (CSharp):

1.         public void Steer()
2.         {
3.             float maxAngle = Mathf.Abs(Mathf.Lerp(lowSpeedAngle, highSpeedAngle, vc.Speed / crossoverSpeed));
4.             targetAngle = maxAngle * vc.input.Horizontal;
5.             angle = Mathf.MoveTowards(angle, targetAngle, degreesPerSecondLimit * Time.fixedDeltaTime);

Is there anything good other than virtual & override?

 

Since ALL the vehicle components (except the vehicle itself) inherit form VehicleComponent base class, and that includes modules too, you can in fact override every function that is inherited from VehicleComponent.
For example this is what the Steer() function from above looks like in NVP2:

Code (CSharp):

1. public override void FixedUpdate()
2.         {
3.             if (!CanUpdate)
4.             {
5.                 return;
6.             }
7.  
8.             float horizontalInput = vc.input.Horizontal;
9.             if (!returnToCenter && horizontalInput > -0.1f && horizontalInput < 0.1f)
10.             {
11.                 return;
12.             }
13.  
14.             float maxAngle = speedSensitiveSteeringCurve.Evaluate(vc.Speed / 100f) * maximumSteerAngle;
15.             targetAngle = maxAngle * horizontalInput;
16.             Angle = Mathf.MoveTowards(Angle, targetAngle, degreesPerSecondLimit * vc.fixedDeltaTime);

Functions that can be overridden on each VehicleComponent:

• Awake
• Start
  
• Initialize
• Update
• FixedUpdate
• LateUpdate
  
• Enable
• Disable
• OnDrawGizmosSelected
• Validate
• SetDefaults

Where last two are intended for editor use only.

 

While testing NVP2 I have realized that having VehicleComponent state settings in the header of each component is not the best idea because of two reasons:

• Settings are not global meaning there is a need of adjusting all the vehicles one by one. Big no-no.
• Hunting all the settings can become bothersome fast.

Old solution (with SoundManager as an example):


To fix this I have moved all of the state settings to a ScriptableObject. I can really not think of many cases where each vehicle would need to have its own settings for things like LODs so this should be much better.
This is what the new solution looks like:



The fields are auto-fetched so this will work fine with all the 3rd party modules too as long as they inherit from VehicleComponent.

 

Here is the latest and final development build for race car.
The behavior is where I am happy with it, it acts as it should and everything is pretty much polished.
Download Link (Win64)

 

Any chance you can get it working with an Xbox controller, the mouse control is not something I can get the hang off. And if you do please please don't do the usual putting throttle and brake on the stick as that is next to useless as if you are steering hard you cant accel or brake and vice versa.

 

This feels SO much better than v1. Me wants.

 

It is way better, however there are still scenarios where car's rotation stays same after impact. Why is this still hapening even in V2??

EDIT: Yeah, i just Bumped into a cliff in high speed and the car just went flying like a baloon. The wheel benting feature is nice tho

 

Because in the demo it is still stock Unity collisions. I had some issues with car catching on flat surface way too easily with the 'improved' collisions so I disabled that for the demo. Quite hard to tackle with the limited Physics API.

 

Not exactly sure what you expect from a box collider. When you make your own cars, you also make very simplified meshes of the actual model which will be used for mesh colliders.. Then you make sure the collider is not a 100% copy of the model because you don't want low clearance. Look in any good game that is using cars and you'll see that on step corners or bends in the road the lower part of the car goes through ground, because otherwise you'd be stuck on every leaf.

You also set a bunch of triggers all over the car in order to handle damage and collisions properly. You wouldn't use the dmg solution that comes with the package. Is nice to have it there and see how it works, but you'd make your own and bend each part on its own. That's how games like GTA do it. An army of small parts, each with triggers and a mix of both modeled damage and some procedural, for a bit of variation so it wouldn't always bend or use the same joints all the time, but still have believable damage. Otherwise if you just rely on code for damage, it will never look good, no matter how much you try to tweak it.

 

You are correct. I was doing the damage system the way I am because of both complexity to set up (and the requirement to have the model up to spec which is extremely hard if you are not rolling your own) and of the complexity to develop. In fact this is a whole new asset territory. Or it could be taken even further with crazy amounts of work - say BeamNG.

But we were not talking about mesh deformation / damage, we are talking about how Unity is handling collisions and the fact that the vehicle does not crumple (not visually, physically) which results in a bit of a rubber ball symptom, especially when catching the wall which is at a low angle which will result in vehicle flying in unrealistic manner.

 

You can fix a lot of collision issues by setting the vehicle physics material to not have friction. (Everything to minimum and 0 for all values) Unity is pretty infamous for having some very wonky collisions out of the box compared to other engines that also integrate PhysX, Unreal Engine for example. Of course you will still need to do your own extra logic because no friction results in being able to wall ride like in old NFS games, but you can still detect the collision and apply your own custom friction. This is how I do it because you can't rely on a general purpose physics system to give you all the features you want. All of these racing games that have specially built engines don't use general purpose physics. They are all made specifically with things in mind. You have to do work on your side too and can't expect an asset do to everything for you.

 

That's why I mentioned the box collider and said about having custom meshes as colliders. There can't be proper collisions with the box collider, which I know was used in v1 in the demo scene, and probably still is. I have a custom mesh that is also smaller than the model, so the car can properly go over hills and whatnot and I don't have any issues. Sure it still stops in a weird way sometimes when hitting a wall or an obstacle, but that's how all games go. Even AAA games have that problem. The most recent game I'm aware of having really really weird collisions is NFS Heat.

Then as I was going further I also thought I should mention how damage would be done, because in my opinion they go hand in hand, when you check collisions you also apply damage, so users don't have unrealistic expectations from an asset. Some things need to be done by the user, based on their own project. Sure, I'd love it if someone else would do everything and have all I want out of the box, so I'd have less work to do, but that's not how it works.

But going back to the demo, I'm more concerned about the car creeping. When the demo starts is already creeping forwards, even if the engine is not even turned on. This was a HUGE problem for me in v1, since it would never stand still on slopes. Depending on angle, it would sometimes do while handbrake was on, but sometimes even that wasn't helping. I understand there's gravity, but I'm not talking about ridiculous angles. Just parking the car on a hill and such.

 

The creeping in the demo is because the option "BrakeWhenStill" only works when vertical input is ~= 0 which is practically never with mouse input and the car is on the slight slope at the start without the brakes applied. If you try the demo for the newest WheelController version on the asset store which uses a snapshot of the WheelController from a month back you will see that the creep is fixed. The only issue is to have it fine tuned at all fixed update times which is what I am fine tuning at the moment.

 

Something else that has crossed my mind while trying to the latest development build is that it would be nice to have a shift time for the manual transmission as well. Car's don't usually shift instantly in games, unless you are using an actual shifter with a wheel setup. But having a simple shift timer where the revs fall would be ideal.

 

This is available and is available in the first version as well. I wanted to get DCT like behavior in the demo for the sports car but the other vehicles are getting longer shift times.

 

That's good to know! I wasn't aware it was possible in the first version. I haven't seen anywhere to change explicitly how long the car shifts, aside from using automatic transmission type, but manual isn't affected by shift time variable.

 

Ah, you are correct. I misunderstood you there. Actually there was in the earlierst versions the delay for manual but it felt unresponsive. I will add it as an option.

 

Okay, so there is one more development build: LINK
Input this time is keyboard / controller.
The focus since the last build was to get the friction calculation fully sorted out. The slip friction calculation therefore got thrown out of the window and the iterative method was implemented instead.
The testing has been done for the most of the afternoon and together with fine tuning the result should be much better friction from the last build.
I have done tests for acceleration, braking distance and cornering and compared with the real world data for similar vehicle and not it should be on point. Previous slip calculation had a nasty tendency to grip too hard on acceleration / braking. There is a bit of wizardry at velocity ~= 0 but I have yet to find a solution that can run at 50 ticks/s near that value.
Feedback is welcome as always.

 

Is there anyway to change the controller inputs, there is no Unity start window it just goes to full screen and wonderfully the steering and throttle are on the same stick so cant test it properly. Also does it have any aids on? If so can they be turned off? I am having trouble getting it to do doughnuts.

 

Since Unity 2019.2 there is no window and I am using Unity 2019.3 to develop due to much faster script reload that they implemented, along with other goodies. Final version demo will be on 2018.4 and the good old settings window will be there.

The controller change will be in the demo as I have just finished reworking the InputProvider system.
V2 supports old Unity input system (standard), new input system, mobile controls and also features easy way to implement your own through interface so it should fit any game.

I have set up the vehicle to be more on the stable side for the racetrack and high speed testing but am not having problems with them as it is, although the current setup is definitely not biased towards doughnuts.

 

Ok thanks for that, it drives nicely if a bit odd having to use keyboard and controller to test properly. Though I am a little confused since every race car, or high performance car that drives and handles well on a racetrack can also do doughnuts, so can you explain why they seem to be mutually exclusive with your physics? I would have thought if a tire model is doing what it should then doing doughnuts should just work when the tire is in a high slip ratio state? No matter how stable the car is, or does this car have some artificial aids turned on?