Edy's Vehicle Physics - official thread

@CoderPro The package includes a vehicle prefab configured for stable drifting (blue sport coupe). The actual VehicleController class can be configured for drifting as in that example.

Here's a video on a third-party project using EVP for stable and controllable drifting:

 

@Edy I did try to make drift behaviour with easy mobile control. But not success ! Could you suggest me how i could config to make drift behaviour like above video ? Thanks in advanced.

 

@CoderPro Open the Demo scene in EVP ("The City - Vehicle Manager") and check out the car named Sport Coupe Drift. You can also find the drag&drop prefab for it at the Prefabs folder.

 

@Edy I mean, how i can config like the video that you did share ? Thanks in advanced and sorry if i don't understand.

 

I kind of have to laugh at this. I watched that video and that car gets to about 35 mph and starts sliding before it even hits a curve. You call that control? Maybe it's just me, but my car doesn't slide out of control going straight at 35 mph.

Anyway, I'm sure you can do a car like that in EVP by just adjusting various parameters. Edy can help you get them right.

 

I'm curious if anyone has any networking guidance for this. For fun I added vehicles to my game using Edy, allowing users to enter/exit vehicles, have multiple passengers, etc. This was easy enough. However, I am just syncing the transform of the vehicle via an interpolated transform to proxies as kinematic rigid bodies. While proxies are positioned/rotated correctly, they do not exhibit any of the stuff like correct sounds/tire tracks, etc. I tried trivially syncing over the control inputs to proxies (steerinput, throttleinput, brake, handbrake), and while this solves some problems (like being able to show breaklights, wheel rotation, etc), since the RB is kinematic I'm sure the simulation requires RB not be in order to derive these results.

Is there a minimal subset of information I can sync over, or some sort of proxy mode, to expedite this? Or do I need to figure out all of the events that can happen like "I am sliding" and "I just changed gears" and sync all that stuff over manually?

 

@DirtyHippy It should be enough with syncing position, rotation and input. The kinematic RB must receive coherent and continuous position/rotation values on each FixedUpdate in order the velocities to be properly calculated. However I haven't tested this in depth so I cannot tell for sure whether this solution would work out of the box.

 

@CoderPro Open the Demo scene in EVP ("The City - Vehicle Manager"). Check out the car named Sport Coupe Drift. You can also find the drag&drop prefab for it at the Prefabs folder. Either selecting the prefab at the Project window, or the Sport Coupe Drift gameobject at the Hierachy window, the Inspector window will show you the drifting setup used by the car (VehicleController component).

 

Hi @Edy
So, in the VehicleController component, what the parameters which affect to drift behaviour that i should config ? Could you tell for me ? Thanks @Edy so much !

 

@CoderPro I've added it to the current documentation draft:

http://evp.vehiclephysics.com/faq/#how-to-configure-a-car-for-drifting

 

For a number of reasons sending input won't work for everything. This was flawed from the start and I'm not sure why I didn't see it. Since I use an area of interest for all scoping, vehicles can enter scope of a player at full speed rendering this approach flawed with respect to throttle. So I think I will need to sync some of the engine state values (like RPM), and potentially some bits to tell I am skidding etc. And then based on that skip your entire physics simulation and basically just feed them to your other components. In the end I will probably need to rewrite them to make this work.

 

I've run into a perplexing problem. I've done something to mess up my vehicles, but I have no idea what. Earlier I was setting my vehicle's Max Forward Speed to around 180 and I was seeing that it seemed to regularly ignore this and I could go into the high 200s even approaching 300. I was so confused that I set the speed down to 10 to see if it would do the same thing, but it seemed to obey that fairly close. Anyway, at some point, and I have no idea what I did, I ended up with a car that could top out at about 135 on a flat straightaway pushing acceleration the entire way. Even when I have my vehicle set to Max Forward Speed of 300. So somehow I've hit some sort of cap that is preventing the vehicle from going over 135 and I can't figure out what setting might have caused this. So at first, the vehicles went well over my limit and now it caps well under it. Any ideas on just what I might have done to get this hard cap?

 

So I have everything networked now pretty well.

A few questions / suggestions:

1) It would be great if you could format all the code in Visual Studio using ctrl-a to select all on a file and then ctrl-k, ctrl-f. The format you are using is not standard practice nor frankly any practice I have ever seen. It makes the code highly unreadable. In addition, remove all the random white space between comments. This might seem like minor stuff but it really is frustrating.

2) Why are you doing one-time initialization in OnEnable? All of this stuff should be done in Awake. This means that every time you disable and re-enable a vehicle, which is common practice for any number of reasons, you have to do all this one-time setup stuff over again.

3) There are something like eight audio sources continuously playing per vehicle even if it is stopped. Your audio component plays sounds for skidding even if there is nothing playing but at a zero volume. Internally the play position is still moving at a zero volume so there is still cpu load and still a virtual sound playing. Why not stop the audio source if the ratio you calculate ends up at a zero volume and only start it if it goes above that?

4) There needs to be a concept of the engine being on/off. I have implemented this concept in my abstraction layer, but this such a critical concept for a vehicle. This should affect things like the engine and transmission sound playing, the ability for the engine to supply power / brakes, etc and likely an event should be exposed when this changes.

5) Your audio component only stops the engine audio source, but not any of the other sounds, when disabling it so you cannot turn off the audio component reliably. Since the audio component updates sounds dynamically in FixedUpdate/Update, which won't fire when disabled, having the other audio sources playing without these updates seems at best a bug. It seems likely there needs to be a delineation between the engine sounds playing (when it is on/off) and potentially when collision based sounds play (not related to the engine being on/off but should be stopped if there is no event ongoing like "I am not skidding").

6) Your ground material manager depends on a collider supplied phsyx material. This means in your sample scenes your "sandy" ground is actually a mesh collider you must have made custom for the sample. Collider supplied physx materials are fine for static geometry like highways, etc, but don't work for terrains. You should add a splat map list for each ground material, and if your query collider is the terrain collider, lookup the main splat map under that position from the terrain and look it up in your ground material manager. This would allow linking splat map textures to ground materials.

 

Quick question, does anyone have this working in multiplayer. Looking to purchase this from asset store but need to know how well it integrates in a multiplayer game.

- Edy great job man very impressed so far

 

Hi Edy. Have you any tutorial for settings (Vehicle Setup, Motor, Vehicle Balance, Driving Aids) ? Thank you!

 

@Edy I'm currently developing something that requires taking the forward and sideway slip data from the WheelHit, but I'm coming to realise that with your Vehicle Controller you're setting all the Wheel Forward and Sideways Friction settings to zero on each wheel. Is this intended? Do you perform your own calculations? If so, how do I access them?

 

@DirtyHippy Great to know that you've got the system networked!

Also, thanks for your feedback. My comments below:

Whitesmiths indentation style | Why

In my opinion it's much more readable than "standard" K&R and its variants that pretend the braces shouldn't exist so they put them out of the way and rely on the visual indentation.

I agree on the spaces between comments should be more coherent.

OnEnable / OnDisable is the most consistent event pair for initializing a releasing stuff in all possible situations present in Unity. It's not necessarily "one-time initialization": it might also be changing settings, loading / unloading, instancing, hot script reloading, and many situations for which other initialization paths fail. I've seen many packages fail in the Editor because their scripts don't support hot script reload.

You're right, it's a possible optimization. It just haven't reached a significant position in the profiler so far for recalling my attention.

This simulation model itself doesn't use nor require the engine concept. Cars in EVP are configured in terms of acceleration, braking power, etc. directly.

For a strictly realistic vehicle simulation where the engine is properly simulated and affects all other parts in the way you expect, please take a look at Vehicle Physics Pro.

Oh! Yes, that was a bug, sorry. I've just fixed it in my repo. Disabling the audio component now disables all audio sources managed by it.

You may include two VehicleAudio components, one for the engine and the other for the other elements. Disabling the component playing the engine won't affect the other audio effects.

I fully agree. The problem here is that accessing the terrain maps is not straightforward. But I'm keeping an eye on this part and will take any good opportunity for improving it.


Thank you very much for your detailed feedback!

 

I agree that k&r style is just wrong, but I totally disagree on the use of Whitesmiths style. In fact, I've never seen this style in professional practice. I read the Why link and Whitesmiths style is an abomination. The other style presented in the Why link, BSD, or apparently also known as Horstmann style according to the first link, is far superior. I've been working as a professional programmer for over 26 years and 15 years in my current position. The BSD style is the only style encouraged by our standards committee and just about every programmer we have, and we have a lot, are in agreement. Now I don't want to start a style war, but I think that even you would have to agree that this Whitesmiths style is rarely, if ever, seen in the programming world. That alone should make you think twice about using it. Personally, just looking at it is very unnerving. Hope I didn't come off as harsh.

 

Max Forward Speed is m/s. This setting defines the speed at which the drive wheels stop producing force.

The aerodynamic drag is the other setting affecting the top speed. Most probably you've raised/modified the aerodynamic drag so the top speed gets limited by it.

I've put together a quick reference on which parameters affect each vehicle feature here:
http://evp.vehiclephysics.com/faq/#which-parameters-affect-each-vehicle-aspect

 

Thanks! DirtyHippy (above) tells to have networked the system. It's definitely possible to have EVP working multiplayer. I've only done some quick tests using the standard network component, so I'm afraid I might not be entirely of help here.

 

I'm working on the documentation page. For now, I've compiled some useful hints and tips here:
http://evp.vehiclephysics.com/faq

 

Yes, and yes.

Check out the telemetry component (or search for tireSlip in the vehicle controller). The wheel data is exposed in the wheelData array. You may read there the tire slip of each wheel.

 

No, that's the Allman style. According to the first link, Allman is also known as BSD style.

 

Yep, you are correct. I didn't look that closely and they are similar. But, yeah, BSD is pretty much been considered best practices by just about every company I've been with over the past 26 years.

 

I in fact just found it myself too. Cheers. However I'm curious - Why perform the calculations yourself? Is the PhysX implementation incorrect? I've scoured your documentation and although all your code looks great, I am wondering why it is reimplementing some of these things. I'd love to know more about what benefits you are gaining.

Thank you for the information.

 

PhysX implementation is TERRIBLE. The entire design is flawed because it relies on a wrong interpretation of the sprung-mass physics model. Additionally, it contains severe implementation bugs (such as this, this and this). I've been able to tweak the suspension to barely work as an actual vehicle suspension, but I was unable to extract any logic out of the tire friction settings.

 

Correct and realistic tire friction

Also predictability and coherence. In PhysX, just moving the position of one wheel (or any of the other possible small things related) may entirely ruin a previously correct setup.

 

@Edy well that is certainly a fair enough reason to implement your own! Thank you for the insight. One further question for you - I'm implementing some terrain deformation to approximate mud under the wheels and it works quite well. However I'm finding that modifying the terrain under the wheels creates a large amount of subsequent downforce on the wheels - The default audio component parameters cause the bump audio to play every frame, for example. The movement per frame is small enough that the wheels are still considered grounded.

Is this because the springforce creates a huge down force across the small gap? What can I do to smooth that? Should I move the wheel down manually with the movement of the terrain? Or should I implement some kind of damping on the downforce, etc?

 

In one comment you mentioned manual gears. That would be an excellent addition! That got me wondering if it's possible to modify Vehicle Controller component in so that instead of giving Max Speed Forward etc., vehicle power would be calculated in more realistic way by torque curve and revs? In my project you are able to upgrade your car with some engine performance parts, and currently I need to have some self-made arbitrary calculation on what kind of boost to Max Speed Forward and Max Drive Force that "+50BHP port polish" will give.

So, if instead of those values we would have that torque curve by revs (or having possibility to alter between those), that would be some fantastic addition to semi-realistic vehicle physics! Or is this something only VPP will have?

 

It's difficult to say. The audio arises when the downforce experiences a sudden change in a single FixedUpdate interval, even while they're grounded (same happens when passing through road bumps in your car). You may play with the bump settings at the Audio component (Wheels section) in order to find less sensitive values.

 

As you know, cars in Edy's Vehicle Physics are configured in the most simple way possible. But its very easy to extend it. You may write your own component that reads the engine rpms from the Audio component (or simulates them in the same way the Audio component does) and modify Max Drive Force accordingly based on your own curve.

 

Great thought and sounds like a nice challenge, I'll look into it. Thanks!

 

I need to setup the speed of wheels turning so then I can sync it with my Steering wheel.
But seems there is no option for this

 

@Crossway EVP uses the standard Input in Unity. The speed of steering is configured at the Horizontal axis (Edit > Project Settings > Input)

 

Hello,
I've been keeping an eye on this asset package for months, and I'm seriously considering to buy it very soon.
I have a question: beside all the great features offered as separate components (such as Damage, which is a very complex and important feature), the basic VehicleController component, which implements core vehicle physics if I understood correctly, what advantages does it have comparing it to the Unity Standard Assets' CarController?
Thank you in advance for your answer.

 

VehicleController implements a physically realistic vehicle simulation, while CarController implements something else that tries to resemble a car. If you've already tried CarController, then try the vehicles here:

http://www.edy.es/dev/vehicle-physics/demo/

You can switch among different car types with PageUp / PageDown.

 

Thank you for your answer @Edy . I've tried your demo and your vehicle simulation is definitely much better than Standard Assets' CarController, indeed! :O
I have other questions which I would like to ask you, if you don't mind.

1. How much difficult would it be, using your package, to use a kart-like car model, in which the pilot is visible on the vehicle and should move arms to turn the steering wheel? I mean, are there any constraints on the compatible car models that may make it difficult to use a model of this kind?
2. Is it possible to apply attractive or repulsive forces to a vehicle affecting the physical simulation? For example, applying an attractive force from behind a vehicle that is moving forward to slow it down.
3. Is it possible to manually set the vehicle's current speed from code? To force the vehicle to immediately reach a given speed.
4. Are VehicleController properties accessible from external classes in code? Can they be changed at runtime (for example changing at runtime the vehicle's Max Speed Forward or Force Curve Shape)?

Sorry for asking all these questions, but I want to be sure that this package would fit my project before buying.
Thank you again in advance for your answer!

 

There are a few special considerations on this kind of cars:

• The car collider should enclose the top half of the wheels, plus a margin, for ensuring that the WheelCollider's top half is always inside the car's collider. This is required for preventing weird collisions reactions as result of the WheelColliders directly contacting other objects.
• The animations should be driven by a custom script. This script would read VehicleController's steerInput parameter and translate into a specific animation state.

Vehicles are plain Unity rigidbodies. Edy's Vehicle Physics applies regular forces to the rigidbody as result of the wheels state. You can apply your own forces, or imposing your own speed constraints to the rigidbody in the same way as you would do with regular rigidbodies.

Indeed, the aerodynamic drag is simulated by a force that slows down the car

Yes. All properties except the number of wheels may change at runtime with immediate effects.
.

 

Thank you very much for your quick and detailed answers @Edy !
You've got a new customer: I finally bought the package!

 

Thank you very much!! Feel free to drop me an email if you need further help or run into any problem with it.

 

Hi Eddy. When you upload EVP pro?)

 

Why do you not update EVP anymore? When will we get two wheel vehicle feature for bikes etc?

 

Hi, I'll be pushing an update to the Asset Store within next weeks.

@FlyHigh You may already have two-wheeled vehicles, but you'd need to write a custom script for controlling the equilibrium.

 

@Edy did you get my email ?

 

Updates are always welcome! thanks.

 

Are you updating the Pro Edition as well. Do purchasers get an email or whatever so we know? I need me some bikes.

 

@ippdev I'm also working on completing the Pro edition. The main announcement channel is Twitter, as there's no way to reach the purchasers of EVP.
https://twitter.com/vehiclephysics

@antoripa Yes, I'll be replying today

 

Is there a change log of sorts for the new version?

 

I do not do twitter or facebook. Hence why I don't do games if that is part and parcel. What about email? Or will there be an announcement on your site which I have bookmarked?

 

Nice to hear getting an update soon.

But could you not implement a "script for controlling the equilibrium" so the two wheel vehicle part is fully included in EVP? I am a beginner in coding and dont know how I could do such thing and I think many would benefit from this when you would include this. Thanks.