Assets NWH Vehicle Physics

All the materials (except the water and car paint shader) are standard Unity shaders and so I think you can do an auto update.

 

Skidmarks just got a major rework, pretty much a rewrite. Appearance has not changed much but performance is (according to deep profiler) 36x times faster and 0 garbage is generated. A lot of the functionality has been moved to custom skidmark shader which will also make using skidmarks easier. Also, all of the known bugs/glitches have been fixed and the skidmarks no longer lag one section behind.

Skidmark manager:


Ground entity settings (per-material skidmark settings):


Skidmark shader:


There will probably be some small changes before release to the skidmark system but this is very near to final.
As always, if you have any requests/ideas they are welcome.

 

So I'm working through my first attempt to set up a vehicle with NWH physics (or anywhere for that matter). I believe I've got everything rigged up correct (first time for this as well, as you can tell by the errant upper tread bit). Followed through the guide, however after setting the recommended values (including those in the treaded vehicle section) the tank jumps around quite a bit. I've got the body/collider set to the layer that is ignored in the wheel controllers, could I be missing something else?

 

Hello and sorry about your problems. These are almost always related to ignore layers (which have been removed in v2).
Make sure that under ignore layers both the body collider layers and Physics.IgnoreRaycast are ticked for starters. If that does not help send the scene over at nwhcoding@gmail.com and I will take a look at it.

 

Appreciate the quick response. After some time messing with it today, I found the culprit (that I should have seen much earlier). The scale on my wheel controllers were set to '100' instead of '1', which I'm sure threw a wrench into all sorts of things. With the fixed scale, the wheels are working perfectly! Had some funky export/scaling when I first imported my model, so scaling went over when I duplicated the wheels to position the controllers.

 

Glad you got it sorted. Scales and physics are a tricky thing because transformPoint and similar return scaled versions but I do have an unscaled versions of those functions made for other project so I will look into scale independent physics for WheelController.

 

How will upgrading a project from V1 to V2 go? I assume lots of things will be broken as there are things removed and added, which is fine by me. Have you tried it out? I'm working on a pretty early project so it's not a big issue for me since I'm still in prototyping stages. But if V2 is as close as it seems, I want to stay away from doing any big integrations with the physics until it comes out.

I'm just curious.

 

You can count on V2 being a pretty much new asset. Sure, some settings will be similar but the powertrain, module systems and many things are completely different. Still, I am putting in work to make vehicle setup easier and less problematic. There will be a setup wizard of kinds for setting up the vehicle, ignore layers on wheel controller have been removed, etc. so hopefully this will make the transition less painful.

 

I have decided to spend an hour or two to make WC3D scale independent for v2. The wheels will not automatically resize or anything like that but if you decide that you need to scale your vehicle like this:



It will work.
Just to make things clear; this is not the intended way to use the asset and it is still best to use scale of 1 on both the vehicle and WheelController objects but if you really really wish to do so it will be possible. Just bear in mind that things such as wheel radius, suspension travel, damper settings, center of mass and similar will not auto adjust and will need to be adjusted manually from external script if you decide to shrink the car at run time. Doing it automatically would require keeping a lot of 'initial' variables, add complications and clutter to the asset logic and more for the 0.1% of the users that will actually use the run time resizing.

 

good day
thanks for your help the character can now enter the prefab car, but the camera wont follow the prefab car it just take off with no camera. can someone tell me how to fix?
thanks in advanced

 

Make sure that under the target field of the camera you have assigned your vehicle, otherwise it will not know what vehicle to follow.

 

I was considering NWH, it looks good but I don't think it does motorcycles? I need car, truck, and motorcycle. Any chance NWH2 will add it?

 

Yes it will. Motorcycles were part of the reason for the v2 but they will be sold as a plug-in module and not on release of v2.

 

Hi,
I think this new version will be great, and i might be glad to pay for it.
But my concerns are three:
- Will the code be easy to read and edit? the current version seems a bit messed, i mean it lacks proper organisation from my point of view, i get however that it might just be a matter of you own coding style
- Will the slipping wheels while stationary bug be fiixed? please it's annoying as hell
- When the new version is coming? (i've been waiting haha).

 

New version will be free, but the motorcycle and tank modules will be extra when they come out.
- Yes. This is one of the reasons for v2. It is not my coding stile, just the asset showing it's age (at the point of writing it I was not that invested into Unity)
- This is not a bug actually - it is more of a downside of slip-based approaches to tire simulation. Have you tried ticking 'freeze when still' option? It should solve it.
- Getting closer every day but I have already missed all the previous dates but not that much because of setback but because I broadened the scope of the update by (quite) a bit. Decided to go all in and see what comes out of it and unfortunately the to-implement feature list is still quite long. Core is all but done but Mirror support, force feedback, setup wizard, demo upgrades, etc. still need need to be done. Then there is documentation (this time in a form of a wiki), etc.
All these take time and I want to do it properly. Upside of this for the customers is that each day something is improved or added, so basically free features. I will be posting updates here every few days so people can get the idea what is happening.

 

I'm glad to see al these improvements, and thanks for the freeze when still tip, i'll try it later.
Given that the new version will be free, will there be "upgrade paths" for people who bought the previous version to these new separate modules?

 

Wondering the same since I bought this asset recently. Afterwards I read about the upcoming v2.

 

Everything included in v1 will be included in v2, minus the tank demo vehicle. In fact, the modules will not even be necessary as v2 will support motorcycles out of the box - it is just that you will need to write your own balancing and other motorcycle-related things. The motorcycle module is just intended to do that for you so you can have a plug-and-play motorcycle solution for a few dollars. Same with the tank module.

 

As promised some time ago here is the development preview build. It is very barebones and has some bugs, but should be representative of the new physics system.

Vehicle setup: 190kW engine with an automatic clutch connected to automatic sequential gearbox. Center diff is open with 10/90 torque distribution. Front diff is open (50/50 between the wheels) and rear is viscous (VLSD).

Download link (Win64)

 

It looks like you made engine stalling feature or is it just me?? Anyways there are some scenarios where skid sound stays after definitive stopping. Car doesn't struggle when going up the hill. For my needs this should be awesome update. Looking forward to this !

 

Quick progress update:

A lot of work has been done in the past week on improving the code base, cleaning things up and resolving bugs.
Also, there has been a move to Unity 2019.3 which will be a requirement due to the just introduced SerializeReference attribute (a.k.a polimorphic list serialization is now possible) and the changes in Unity GUI which have been large enough that some parts of the editor needed tweaking and fixing.



For those that do not know yet Unity 2019.3 went with the new look and those are mostly default Unity field styles.
Also, the modules section that is nearing completition:

 

Uh oh. I guess I won't be able to use version 2 anytime soon. Too many problems and performance regressions to make the move to Unity 2019.2 or 2019.3. I'll be waiting for 2019 LTS to release before I ever consider moving over. I will still be following your progress though

 

Yep, there are still a few issues but already in f3 it is much better. Still, I am not too happy with the amount of bugs they introduced but hopefully the will get fixed soon.

Also, while the [SerializeReference] attribute has been introduced there are severe Editor bugs related to it, especially when used with UnityEditorInternal.ReorderableList.

 

After the spawn (Instantiate game object) of the trailer there is no way to attach it, what could be the reason?
If you place a trailer in advance on the stage, it attach successfully.

 

This is because the code to find the trailers is ran only when the vehicle is initialized. I would suggest moving this part of the code (it is just one line) out of the Initialize function of TrailerHandler into a separate function that you can call each time you instantiate a trailer OR you could just run it each or every few frames (not good for performance).

I have added 'autoSyncTrailerObjects' option to upcoming version 2 of NWH Vehicle Physics along with SyncTrailers() function that allows for manual sync.

 

I would like to hear what parts of the vehicle would you see moved to ScriptableObjects.
So far in v2 scriptable objects are used for:
- Friction presets (WheelController)
- Transmission gearing profiles
- Surface maps (previously known as Ground Entities)
- LOD/State settings

I was toying with the idea of moving WheelController settings to a single scriptable object but on the other hand this is something that is usually specific on vehicle-to-vehicle basis and even on axle-to-axle basis so it would probably introduce mode problems than it would solve.

 

Could be possible to atleast partially port vehicle settings from V1 to V2 so they match as much as possible? I need especially suspension settings kept. I already have progressed game and it will impact development time, if these values will have to be ported from scratch... Wheel controller is still same so it should not have any impact right??

 

WheelController serialized field names have not changed much or not at all. There are a few new ones but most of them should carry over. The rest of the asset however has changed much more and it will not just 'copy over'.

 

Merry Christmas everyone!

Just a small update in regards to Editor GUI. I have just finished with nested Editor and ScriptableObject drawers which allows for this:



Being able to editor WheelController settings inside the VehicleController editor was requested a few times in the past so here it is. The helper script for GUI went from a few functions to a mini framework but it allows for things such as nested Editors which also means that ScriptableObjects can be embedded. In the image below scriptable object FrictionPreset is being drawn inside WheelController editor which is in turn being draw inside VehicleController editor (image above):



There will also be a disclaimer just below the header warning users that they are editing an (embedded) ScriptableObject to prevent any confusion.

That is about it for the GUI and the base asset - next come all the requested features that are waiting on the TODO list.

P.S. If anyone from Unity is listening please fix the nasty bug that happens when [SerializeReference] and UnityEditorInternal.ReorderableList are used together. Still happens in 2019.3.0f4. More about the bug here.
You also have a bug report from me in your support system.

 

Appreciate the development insights. Are you considering an example of a vehicle powered by an electric motor for the new version? Could become more and more useful considering the way things are nowadays.

 

And when will the update be released? =)

 

I will be away from office next week but as soon as I come back I am adding in new features that have been requested (mainly compatibility with other assets and steering wheel support), fixing and testing things, updating the demo, setting up test vehicles, etc. so I can not really say the exact date. Two months ago I said it would be out end of December but in the meantime the scope of the update grew so much that I have to say two more months to get it all done and done well.

 

I tested the demo you posted but it seemed to have some very unrealistic physics behaviours, flipping the car many times when just hitting obstacles at medium speed. .

 

Ignore that one as it will not be there later. I was playinf with a different code for bottoming out and the suspension is very soft so bottoming out happens a lot. Just something to do before release. It was supposed to be more of a powertrain demo.

 

Is tire wear going to be part of v2?

 

As a module, yes. Was not planned on release but should easy enough to implement that I will. This was the point of having modules - being able to make one and integrate it into the asset while keeping the code isolated and easy to maintain while not causing a performance hit for people that do not use it.

I was thinking about a relatively simple model where friction coefficients would be changed depending on tire wear and can be adjusted through a curve. Tire wear would be dependent on slip. Would that be good enough?

 

Yeah it would! I’m making a sprintcar game and trying to get the physics of your system to work is it better to have mesh surface or terrain surface?

 

Ground detection will work the same. Surface type detection (used for effects and changing friction profiles) is the only difference:

- Terrain: Uses splatmap to determine which texture wheel is on.
- Mesh: Uses tags (color based surface type detection has not been implemented yet).

So if you use meshes at the moment you will need to have a separate object for each type of surface.
Also, make sure to disable "Queries Hit Backfaces" if your mesh is one-sided.

 

Another question the cars have stagger the right rear is larger than the left rear and its rear drive the asset seems to not have a natural drift is there setting I need to play with?

how is power calculated the cars have 900hp in real life what is the max power measured in?

 

All the units are standard SI (International System of Units) units meaning the power is in kW.
The drift aspect is a bit problematic in version 1 as it does not normalize slip meaning that lateral slip does not influence longitudinal slip and vice versa. If you need to release the project soon contact me over email and I will send you instructions on which lines of code to modify in current version to make it better at drifting.
If you try the demo for V2 from a few posts above you can see the end result and if you like it.

 

Email sent thanks!

 

Any way to make the collision work for the complete wheel instead of just the bottom half? at the moment, if tire's cover is disabled and vehicle is pushed against a flat wall, the wheel doesn't detect collision and goes inside the wall and only detects the collision when its halfway into it and then for some reasons, it throws vehicle in the air.

I'm looking for wheel behavior exactly like this:
https://twitter.com/StudioTatsu/status/1162044620034981888

 

I have to say that the folks at Studio Tatsu did a great job. Upon some investigation it seems that Unity has opened up some interesting methods in regards to physics which could be used to achieve this. Will investigate for sure as getting rid of raycast and having the wheels detect over whole surface are two things I have been trying to achieve from the start - but unfortunately was not possible due to physics API limitations. Thank you for the tip.

The throwing vehicle into the air is because ray will immediately hit resulting in wheel thinking it is under a surface which will in turn fully compress the suspension. Unfortunately a doenside of raycast based approach.

 

to my very limited understanding, I think it is rigidbody on the tires, connected with configurable joints to drive and steer the vehicle, I cannot possibly think of any other way to pull this off.

[/QUOTE]The throwing vehicle into the air is because ray will immediately hit resulting in wheel thinking it is under a surface which will in turn fully compress the suspension. Unfortunately a doenside of raycast based approach.[/QUOTE]

agreed. yes. this indeed is the case.

 

The throwing vehicle into the air is because ray will immediately hit resulting in wheel thinking it is under a surface which will in turn fully compress the suspension. Unfortunately a doenside of raycast based approach.[/QUOTE]

agreed. yes. this indeed is the case.[/QUOTE]

I can think of a way with the new API
But there usually is a large downside or some large problem to prevent usage is all scenarios. Anybody remembers that one function that is supposed to tell you in which way to apply force to depenetrate two colliders? Yeah, does not work properly at shallow angles.

 

ended up creating my own custom solution, took me a couple days and lot of caffeine, though.

 

Awesome. Could you share any details on how it's done? (or even better, some code)

 

Due to the large amount of improvements, bug fixes and other changes present in NWH Vehicle Physics 2 I have decided to move the development of features that will be released as modules (either free or paid) to after the release of NVP2. This will move the release date of NVP2 to under a month from now. All the features of NVP + many more will be present in NVP2 on release (minus tracked vehicles).

 

If I understood correctly you want to move wheel visual (mesh) to be differently positioned to the wheel (represented by debug gizmo)?

 

it appears that rotation pivot does NOT change when i use rim offset, however the green little dot is still at the center of the wheel collider. It feels little bit messy. I would personally keep the green dot in position where center of steering is...