Assets NWH Vehicle Physics

FYI : After importing the latest NWH Vehicle Physics update it didn't compile, throwing err Assets/VehiclePhysics/Scripts/Wheel/WheelController.cs(4,23): error CS0234: The type or namespace name 'Policy' does not exist in the namespace 'System.Security' (are you missing an assembly reference?)

Seems to work ok (from what I've played until now) if I just removed that particular import from line 4 in WheelController.cs

I'm using Unity 2018.3.0.f2

 

Hi, I both own NWH Vehicle Physics and Realistic Car Controller.

I'm sure NWH has a lot more to offer but when it come to performance comparison, RCC is much faster. (6ms vs 1.5ms spent on FixedUpdate() on my machine with similar setup)

For a user who don't have powerful CPU, I would like to make NVP to as little CPU as possible.
Is there a way to make it a such switch in NVP? Otherwise, I probably have to use RCC.

Thanks.

 

Hi everyone,

I'm developing a game with affinity for sliding motions (not necessarily drifts). Noticed in the demo that the car sometimes (not all of the time) comes to a sudden stop almost at the end of the slide, you can see it like a snapping motion.

I've uploaded this unlisted YT clip for best understanding the phenomenon :

Does anyone know if this can be corrected ? And how ?

Thanks

 

It is a known bug. Until the upcoming update just untick "Freeze When Still" under General settings of NVP or you can replace "speed" variable inside VehicleController.cs, line 497 with "velocity.magnitude". Both will do the trick.
I will push a small update now to fix that and the include from 3 posts back.

 

Awesome, many thanks for the quick reply

 

Noted, expect a small update with this fixed - I will upload it immediately and it will be live in a few days.

 

Hi, there.

I'm curious what you thought about this.

It would really nice if the performance can scale. Having more than 10 vehicles really slows down and I would like to turn off some non-critical features dynamically depends on the number of vehicles in a scene.

Thanks.

 

Good idea. Turning on single ray mode on the wheel controller has already been implemented. I have to say that this is quite a good idea as skidmarks, audio and particle effects (and possibly some other aspects) could be useful. Added to TODO.

 

Great! NPV is getting sexier and sexier. I can't wait until what you will bring next. ^^

 

hi, great asset, i have a lot of fun with it but a question, how can i script a repair mechanism when the car hit a trigger ? i get more than 3 hours to achive this but with no result... i can't access the fonction Repair()
oh and a happy new year

edit with my code it's more explicit:

Code (CSharp):

1. VehicleController other = (VehicleController)gameObject.GetComponent(typeof(VehicleController));
2. other.damage.Repair();

the error :

NullReferenceException: Object reference not set to an instance of an object

NWH.VehiclePhysics.Repair.Update () (at Assets/Repair.cs:29)

 

OK i found my problem XD noob problem

 

i put the same code for the refuel XD it's so easy when we know the code now i try to do a fuel gauge XD

 

Just for idea, i added a fuel gauge
add this line in DashGUIController.cs
line 21 :

Code (CSharp):

1. public AnalogGauge FuelGauge;

and this one line 44

Code (CSharp):

1. if (FuelGauge != null) FuelGauge.Value = vehicleController.fuel.amount;

do't forget to add the gauge i the GUI and attribute this gauge on the DashGUIController
and voila i'm so proud of this XD only a few hours like 5

 

how to add rev limiter i like unitycar pro ?

 

Simply go to "Engine" dropdown and set the Max RPM field. Rev limiter will activate automatically when engine RPMs exceed this value. Note that if you are using automatic transmission in some cases it will not be possible to hit the limiter since automatic transmission will shift before the limiter activates, but this is entirely up to how you set the transmission up.

 

Expect 1.8 to be out in a few days. This one will be quite a large performance update since all the raycasting is now done through Unity job system. As you might know job system is not available for 2017.4 which is the current minimum supported version so I will be moving the project to Unity 2018.3. Package for 2017.4 (current) will be left on the store for compatibility purposes.

This will improve performance greatly on multi-core CPUs when using high-resolution ground detection.
Expected performance improvement of the wheel is anywhere from none for a single ray mode (left unchanged) to 200% or more when using high resolutions on high core count CPU-s (especially mobile where single core performance is quite weak).

Changes for 1.8.0:

• Moved to Unity 2018.3.x.
• Implemented batched raycast system for ground detection resulting in greatly improved performance, esp. with high ground detection resolution.
• Improvements to the demo scene.
• Ignore Raycast layer is ignored by default without need to tick it.
  

 

I want to make a multiplayer game and i want to use your asset.
Synchronizing works fine and i send my inputs to other people.
They receive the steerAngle and the wheels steers, but the throttle does not apply and the wheels wont spin.
So the car is synced via transform + inputs and everything works fine but the wheels dont spin when the car is moving.

 

Great news. A few things i noticed
1. https://9.allegroimg.com/original/0cbb1a/606050a54d0e8597a3876445b319 this way air gets into truck engine, it's not exhaust like in demo.
2. Add automatic reverse ligts
3. Engine start is too smooth. In most cars after engine start rpm is quick getting more then this 1000 and it's falling to this start value.

 

I have come to an idea to make an automated vehicle setup wizard. Anyone likes the idea?
It would be mostly for basic setup, e.g. wheels, some vehicle parameters, etc. Mostly what the Quick Start video shows. This would also give me possibility to warn new users of some errors they might be making (improper pivot points, scale, etc.).

 

This is happening because you are setting the transform via code, while the asset pretty much relies on the rigidbody.velocity to do the things you mentioned - turn the wheels, calculate engine RPM, etc. I would suggest syncing everything manually and disabling client side calculations fully. You would need to send over vehicle transform, wheel transforms, eventually steering wheel rotation and sound. Effects could still be calculated on the client side. To send over sound modify base sound class SoundComponent.cs (which controls volume, pitch and other sound aspects) and send individual values for those to the client when they change.

I have recently been looking into this library: https://github.com/vis2k/Mirror
Any feedback? It is supposed to be a community replacement for Unet and seems to be under active development. Rather than waiting for functional replacement from Unity for their Unet I was thinking of implementing Mirror as the multiplayer solution. It is free and includes MIT licence which means that it could even be bundled with the asset itself.

 

Check the first page of the thread for the poll on which networking solution you want to see implemented.

Also, check post #469.

 

This would be a very nice feature, i tried to setup my vehicle model, and it starts bouncing sometimes

Seems to be good, i want to use TNet, which i prefer. But any kind of network implementation would be fine, to see how you would synchronize a vehicle over the network.

Player A is making all inputs localy, applies it and send his inputs + transform to the other players.

 

I started to read the manuals and customize my first car.

I run into an issue, for some reason the spring are fully compressed (scene view) and that causes the car to lift too high when pressing play (game view), as seen in attached pics.

My current workarounds are to set spring travel to a lower value (but this causes the car to bounce / jitter) if set too low like 0.05. Or I can compensate by moving the wheels (into) the car in scene view in order for it to look ok in play mode.

I'm sure there must be another solution, or I've missed something, since all the cars from demo scenes show springs only half way compressed in scene view.

Attaching pics as well :

Scene view :



Game View :



Ugly (scene view) workaround :

 

I will need some more info on the mass of the rigidbody in question.
Note that the springs are not simulated in scene view and therefore the position of the wheel in scene view does not matter. WC3D works on different principle than wheel collider and therefore when the car is in the air the spring is fully extended - as it shuld be. Unity on the other side uses target spring position which is not realistic but helps determine wheel position at runtime. My suggestion would be to set the spring strength at runtime and when you are happy copy the transform position and spring strength value. If everything else is set up correctly this will solve your problem.

Also, try not to set the spring length under 0.2 or so since bottoming out might happen with higher fixed delta times.

If this does not fix it for you send it to nwhcoding@gmail.com and I will immediately take a look at it.

 

Finally I've solved it. Forgot the manual section part with move the
duplicated objects up to a point where you want the top of your spring travel
to be, it wasn't explained in the YT clip so I overlooked that tiny detail, can see it here at 1:03

At that point you lift (a bit) all WheelControllers objects. Sort of controlling / initializing the spring tension at that position.
So, by moving the wheel controllers as shown below, I've managed to tune it perfectly :

 

In manual you wrote (in Stearing Wheels section) "go to Set up USB game controllers -> Select you wheel ....
where can I find this?

 

Sorry for not being clear there - it is supposed to be under Windows settings.
But for the newer versions of NVP you can skip this step and under Desktop Input Manager pick "Composite" under Vertical Input Type. This will make both gas and brake pedals act as one input, with brakes always overriding the gas.

 

Hello again,

I've managed to get pretty much through the entire setup, but I still have a problem with the skid sounds.

I have 2 ground entities, a road ( by tag ) & sand ( by texture). Works ok if the layers aren't one over another (road over sandy terrain). Added a logger in Ground.Detection.cs and indeed it pics both road & sand layers (on different successive calls) even if the car stays on road. Below picture should explain things pretty well :



Here is my Ground Detection Inspector setup :

Looking fwd for your reply.

 

Hi NWHCoding,
I have a problem with the old WC3D and i was wondering if the problem is fixed/improved on the NWH Vehicle Physics.

My problem is the sideway slide when a vehicle is in a slope, even if the slope is minimal. No matter how much break torque is applied, the car slowly slide to the side.

Here a gif to show the problem:

https://www.badmouse.cl/dev/slide.gif

Is there any solution with the old WC3D? is the problem still present on the newer NWH Vehicle Physics?

 

Small defect regarding Cameras scripts :

Issue : When starting the game all cameras for active vehicle are active (this causes huge jumps in Tris that are rendered, depending on the nr of cameras on that car).

Reproduce : Open playground & hit play. Sedan will be chosen and all cameras are active at the same time.

Cause : Even if CameraChanger.cs has correct code in DisableAllCamerasExceptCurrent(), the issue is caused by VehicleChanger.SetCameras() method which sets all cameras to true for the active vehicle.

 

Nice spot, added to the TODO list.

 

There were some tweaks but this will not ever be fully 'fixed' with this type of wheel physics. If you set default wheel controller substepping to (1,1) via WheelCollider.ConfigureVehicleSubsteps you will get the same behavior and unfortunately substepping of any kind is not possible on out end.
I did quite an extensive writeup a few pages back on this forum but in short this is caused by combination of relatively long time between fixed updates, friction curve needing to be relatively flat just around 0 point to avoid overshooting and floating point inprecision in general. What was implemented in NVP is "Freeze When Still" option which essentially freezes the rigidbody through constraints when velocity is miniscule and there are no inputs or collisions, which while is a hack of a kind works quite fine and without any performance overheads.

 

I had this one once before and for the life of me I can not remember the cause but it had to do with raycasting hitting the wrong surface. Could you try disabling "Queries Hit Backfaces" and try again? I do not remember clearly but I do know that it was something as unrelated as that.

 

Didn't worked, still the same.
It's quite a major setback since I generate all roads on top of the terrain with a 3rd party asset. I don't even want to think of manually erasing the texture just underneath the road.
I'll search as well for a solution, but please let me know in case you remember the cause.

Thanks

 

No, it should not be a problem. The road in the demo scene is generated in the same way. Would it be possible for you to send over the scene so I can replicate it?
Or if you want do compare the collider settings on my road and your road:



I have checked and the demo scene works with all the default Unity settings so it is not that, nor it is the code.
One thing that could be happening is that you have some kind of collider that is getting hit, or possibly a trigger so it may be defaulting to the first ground entity available.
So my suggestion is to try turning off "Queries Hit Triggers" and see if it does it. Also, try disabling "Rim Collider" option which should not be a problem since the demo vehicles are using fine, but just in case.
Ground type detection is working using single raycast at the middle of the wheel so if that raycast hit something along the way that it should not it could be causing false readings.

 

Back with great news. I've debugged the hell out of it and yes, it turned out to be an unexpected thing ... that now seems logical in restropect . The road layed by the 3rd party asset was another object in the scene that (on the perfectly flat areas) was at same height as the ground. The hitdistance being (virtually) the same there wasn't a rule for picking one first over another so they kept alternating. I've lifted the entire road object by an imperceptible amount (0.005) and the issue was fixed.

 

Interesting. You must have had terrain pixel error at 0 or that terrain is very flat since I have had terrain "eat" the road a lot of times if the height was the same, especially if viewed from distance and render queue is not above the terrains' render queue. Glad you got it solved, I totally overlooked that this might be an issue.

 

Me too, for trying stuff out I just created a simple terrain (3d object > terrain) and that was that. On the actual game this won't be the case since I use procedural generation from various heighmaps, so nothing will be perfectly flat. Yeah, glad I found out and moving on now with the rest.

 

Hello! I have some bugs in the demo. When the wheel hits the ledge or if you turn the wheel so that it touches the object, the car jumps. Looks not very nice. As I understand it, the Wheel Collider 3D is to blame. What do you think about it? Can you fix this? I recorded a short video to demonstrate:

 

Hello,
this has been explained a few times around here but I will explain it once more.
What you see is inherent behavior to this type of wheel physics and all the wheels share it. There are a few rays being shot at certain points on the wheels which determine where objects are. From the hit data on those rays the position of the wheel is calculated and on from that suspension travel. What you see in the video above is the impulse force being applied as a result of suspension bottoming out, thus preventing the wheel from going through the ground. Default wheel collider does the jump every time you pass over any curb, and they do have access to physics backend unlike me.

Now that I explained why it happens, here is how to fix it - and it is quite easy:
- Use rim colliders (option under WC3D) - this will fix most problems but if not:
- Oversize the vehicle collider a bit so it covers the top half of the wheel and a bit of the side. This will make sure that parts of the wheel that should not contact things do not actually contact them. Excuse my Picasso:

This is a side view, same with the frontal view.

Hope this helps, I know it is a workaround but Unity is really not an engine to cater to simulation and realistic physics so those are sometimes necessary.

 

On the side note: it seems that the Proton is leading the multiplayer poll 2:1 at the moment.
I will leave it open until Sunday.

 

Hi,
Could you build a demo for test drift car ?

 

Demo drift/arcade car is not yet in. The poll for multiplayer implementation will be closed on Sunday and starting Monday I will be working full time on the on a larger update implementing the requests I received over last two months, multiplayer and the mentioned car included.

 

Poll on multiplayer will close in an hour.
Photon is well in the lead so expect to see it implemented in the upcoming update.

 

Hi!

Nice asset! Are you planing motorbike(s)?

Thanks for reply! Have a nice day!

 

It might seem like a logical step forward but the asset is so much geared towards vehicles with two wheels per axle that it might be better to rip out needed modules and write a different controller. Cramming it into the same script would just cause a lot of chaos.

Motorcycles need slightly different wheel behavior, different steering, balancing, rider animation, etc.

They do not need axle setups, ackerman steering, handbrake, reverse, steering wheel, tracked steer, trailers and the list goes on.

What could be possible is a separate "motorcycle controller" script inside the asset reusing modules from the main script, but I will have to make another poll for that to see what the interest would be like. Also, one step at a time.

 

NWH Vehicle Physics uses and includes Wheel Controller 3D. The asset has been released for a year now with 14 or so updates so far.

The old OVPK and this asset have 0 lines of code in common, but since they are very similar in function I decided to offer an update option anyways.

 

Hi. Sorry for the noob question but how do I select/import version 1.7.4? I'm stuck with using 2018.2... Cheers.

 

Both versions are at the store. Unity will automatically download the latest asset version suitable for your Unity version. I would have gone with Untiy 2018.2 but I had much better experience with .3 in which I have been working for over two months (since beta) so I chose to go with .3 for the last NVP update. They have updated the physics in .3 which is very welcome, too. This is a bit more cutting edge than I prefer to go with my assets but the decision was that the performance benefit is worth it.

 

if anybody is interested here is a development build for multiplayer. Just run it twice in separate windows if you want to test the multiplayer. If two people run it at the same time they will see each other since the multiplayer is over Photon servers (not local). Also, the servers are in Europe so you might experience lag if you are far away.

What works:
- Vehicle positioning
- Lights
- Sounds
- Cameras

What does not work:
- Effects

DOWNLOAD