Edy's Vehicle Physics - official thread

All sounds are referenced from the CarSound component on each vehicle.

All impacts are managed at the CarDamage script. Actually, the wheel's orientations are deformed when the impacts are located near them, so the vehicle gets more difficult to control. You can increase the "sensitive" radius and/or the amount of deformation (deformNodes). Also, you might count the number and/or intensity of the impacts and reduce the amount of "power" of the engine (by reducing the motorInput values accordingly, for instance).

All this belongs to the specific gameplay of your project.

Other people already did this:
http://www.youtube.com/watch?v=dpA6jPrj9u8
(see min: 1:10)

 

Logitech G27 is supported in the Asset?
Could you put in a ZIP file the C# version inside the package? Then we dont need to ask every time.

 

Hello All,

I am stuck with how to modify the GUI comming with Edy's vehicle physics.
Where I am now:
-I know that Car Main controls Gui enabled/disabled and Big Text, Small Text, Box Styles
-Skin (Gui Skin) sets further details for text formatting
-And the question is: Where can you set the following things:
1. The GUI to appear in top-left corner instead of middle-bottom
2. Order of each button separately, text on label etc.

Thank you for any hints in advance.
Kind regards,
Balázs

 

Hi Edy,

The ferrari model appears in your webplayer demo is not included in your package. The model is nice. Where did you get it?

 

Hi Edy

After seeing some videos of the BeamNG.drive, i was wondering if it could be possible to implement this type of damages system. That would be awesome

I do not know if this would be difficult to code. As far i know, it seems that this type of damage is based on Rigs of Rods, which the source code is open source, if i'm not mistaken.
Quite frankly i've never been very satisfied with the " torn" look of the cars when collisions occur. Furthermore, the parameters are not very easy to tweak, in my opinion.

What do you think ?

 

Yes. If you configure the accelerator-brake as a single axis then the G27 will work out of the box. You would need to do a small modification to CarMain::SendInput in order to support separate accel - brake controls.

The package uses the standard Input system from Unity, so anything that works there will will work with Vehicle Physics.

It's not a problem to be asked for the C# version, really

These user-made videos explain how to adapt the vehicles to Edy's Vehicle Physics. The comments are in russian, but the videos themselves are pretty self-explanatory. I'm going to add them to the docs.

http://www.youtube.com/watch?v=0fri9JEXyHE

http://www.youtube.com/watch?v=89Lw5CywfKI

Thank you for the add-on! I'll keep it here for now so anyone could use it and propose changes.

 

Find the OnGui function in CarMain. This line controls where to place the GUI in the screen:

Code (csharp):

1. var rc = ScrRect(0.25, 0.89, 0.35, 0.2);

Those are relative coordinates in the screen: left, top, width, height. For placing the GUI in top-left corner it would look like:

Code (csharp):

1. var rc = ScrRect(0.01, 0.02, 0.35, 0.2);

The order of buttons and captions are specified in the code within the OnGui function (GUI.Label, GUI.Toggle, GUI.Button). Note that all positions are relative to the variable rc.

It was provided by a customer for a separate project (this one, exactly: http://www.youtube.com/watch?v=bD9JTobqQZA). I got permission to publish a web version of the game, but not to provide the assets.

This type of damage is based on softbody physics, which is nearly an independent case study by itself. Softbody physics is based on the assumption that everything is flexible to some degree, which is true. Thus, each vehicle must be configured independently for each and one of its components (mass, inertia, softness, joints with other parts, softness of each joint...). Surely creating a new vehicle is not trivial at all.

In Unity physics are rigid-body based. Softbody physics would require Unity Team to implement it inside Unity as a separate physics system. I don't think it's possible to implement them as add-on, or at least it would be pretty difficult.

 

I bought your Edy's Vehicle Physics pack for $60 from asset store and when I tried to get the C# package from git it asked for a username and password. I have not received any email about the username and password and feeling frustrated..

 

Sorry for the situation. The problem is that I don't receive any information from Unity on the package sales apart of the number of them. So I must request the customers to mail me directly (edytado@gmail.com) with the invoice number. I can then create the account and reply with the user pass required to access the GIT repository and the project's files.

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

Please note that the GIT repository and project's files is a "bonus" service I decided to offer to customers on my own, without having to do with Unity or the Asset Store.

 

Some additional thinking on this.

We might try to implement a "barely similar" damage system in Unity by constructing the car using many rigid bodies linked with joints. Each rigidbody could also implement the actual impact-based damage system for deformation. These joints would be configured to support impacts of a defined magnitude before breaking.

But we would face a big visual problem: in Unity all joints are "soft joints", where the constraints are not strictly enforced. In other words: joints are implemented as "very strong springs". For example, a hinge joint implementing a door allows the door to move away from his hinges. The joints put it back to them when the force on the door ceases. Building a car using Unity joints would mean that all breakable parts would be "shaking" against others at all time, which is something we definitely don't want.

An intermediate solution would be to construct a car normally with a single rigid body, but keeping a list of all parts that are breakable. When receiving an impact strong enough to affect one of the breakable parts, we would then give that part its own rigidbody and, depending on the magnitude of the impact, we would either detach it directly or keep it connected to the main rigid body via a breakable joint (so an additional impact would finally detach it).

 

Well if you look at this page : http://unity3d.com/unity/quality/physics, there is " Soft Bodies, such as semi-deflated beach balls that interact realistically with the environment ". So i do not know if this is the same type of softbody physics

I have encountered this problem in a demo i made, here is a video :

In some of my videos, that's what i nearly did, by adding a rigidbody at runtime. So some parts of the car can fall off to the ground.

 

No, these Soft Bodies are a particular type of Interactive Cloth. Even at the highest stiffness settings they still behave more as a cloth than as a body. They are not suitable not even for simulating deformable tires (I've tried!)

The problem in that video looks related to the rigidbody's Interpolate setting. Try either configuring all rigidbodies to the same interpolation value, or disabling interpolation in all of them.

 

Well thank you, indeed it was related to the rigidbody's settings. No more shaking ha ha

 

Great!

Still, you can notice a kind of "jitter" on the attached part when the vehicle moves and the parts should firmly move with it. This is the problem caused by the joints being "soft-joints" in Unity.

 

You are referring to the left door i guess ? Yes, using a hinge joint to open/close a vehicle's door is not the better way.

Edit: in fact i have forgotten to remove the rigidbody and its joint. There is already a script for the opening/closing lol.

 

hi edy!

why dont u work with thy guy to have easy way of importing vehicles into you asset

RapidUnity Vehicle Editor
https://www.assetstore.unity3d.com/#/content/216

ive created a post asking he add support for your asset in his asset

if not, why dont you do your own easy editor addon to yours

basically you select the model, the wheels and move them where they should be. same for steering wheel and then have sliders for the parameters

i ask this cause i saw couple posts and i saw i have to import a bunch of vehicles and i hate doing things manually, i rather have nice editor gui, drag and drop kind of tools

thanks in advance!

 

Thank you Edy for the reply, you made my day.

 

Hello Edy,

Please help me out with an other thing regarding car damage.
I checked your sample, your settings and applied them in my project the following way:
I want car body to be damaged in case of a collision. I set a box (BrakesCube) below my high poly mesh acting as a Deform collider. If I set the Van as a deform mesh, nothing happens. But if I set BrakesCube as a deform collider it works properly. What can be the problem? What should I do to deform the van? Thank you for your help in advance.

 

The Van should get deformed on impacts regardless of the deform colliders. These are intended for deforming the colliders as well as the mesh, so they "follow" the deformed shape of the visual mesh.

Can you send me screenshots of the scene where both Van and BrakesCube are visible? Send them to edytado@gmail.com. Please include your invoice no. so I could give you full tech support and assistance.

 

Dear Edy,

I sent you the information to your gmail account. Kind regards,
Balázs

 

Hello Edy,

Your plugin is really nice but I have an encountered an issue with the brakes on mobile.

Everytime I slow down using the brakes (even for a second), my steering is affected and my car does not turn half as well as before.

I was wondering if you had already seen this bug on mobile or if you had a clue of what was going on.

Thanks,

F.

 

Well, I reimported the plugin and my brakes are no longer broken!

 

Hi, I'm considering purchasing this plugin for my game. I've got some questions though:

1. Can I manually chose the gear and change gear ratios?
2. Is there a rev limiter or something equivalent at maximum rpm's?
3. Is wheel spinning implemented?

Basically I'm looking for a physics engine to simulate a drag race. Player starts in neutral gear. Can rev the engine, change to other gears and accelerate off the start correctly based on the chosen gear applying wheel spins if necessary. Looking over the features quickly, I'm not sure how to achieve that with this engine. Do you think it's possible?

Thanks.

 

Hello,

I bought the pack and i'm trying to achieve movement like Track Mania 2. From what i can tell the physics aren't that realistic. The cars need to bank to the left and right when turning corners and dont flip over as easily from what I can tell. Do you recon if i give the car's body some extra weight it would keep it on the track and still have the banking?

http://www.youtube.com/watch?v=AxI3gM3RIm4 But without the jumps.

 

Can anyone confirm or even point me in the director of a rigging wizard script for Edys system, just the amount of time I'd save setting up my cars, I really need to try and find this (my mission for the weekend).

 

regarding the above post this is what I'm talking about

http://www.youtube.com/watch?v=5qBSKrU6A5w&list=TLHUHldcqkZtHe9Cb2mbKZDYCMfaPLu1Y7

Is this kind of rigging wizard script available on the GIT repository ?

 

In Edy's Vehicle Physics there's no real engine simulation because of the (in)famous bug at the WheelCollider component. Engine acceleration and top speed are simulated by applying constant torque at the wheels, and a properly configured aerodynamic drag to allow a maximum velocity.

So in your case, you might prefer to start with your own engine implementation, then adapting the wheel component of Edy's Vehicle Physics at the end. I'm now developing a full-featured vehicle simulation that will overcome this problem, but I cannot estimate a release date yet.

I'd better recommend you to manually apply additional downforce instead of extra weight. This will greatly increase the car's responsiveness without increasing the inertia. A nice trick is to simulate your own gravity: disable the Use Gravity checkbox in the rigidbody, then add the following line to the FixedUpdate function:

Code (csharp):

1. rigidbody.AddForce(Vector3.up * -9.81 * 1.5);

This will simulate a gravity 1.5 times the real value. Feel free to experiment with that factor. You might need to increase the suspension spring values as well.

Note that if you are simulating Trackmania-style scenarios, you might also want to tweak that gravity vector in real time to fit the scenario the car is onto (i.e. when doing loops or sidewalls).

For preventing the car to flip over you should carefully adjust the height of the center of mass.

The package provides an empty rigged car where you can simply place your own meshes and adjust the positions (wheels, center of mass, suspension distances). I know it's not the exact solution you're looking to, but actually I don't know about any released product that fits that functionality.

Once the cars are rigged and the dimensions adjusted (wheels' positions, CoM, etc) you will have to set up the parameters anyways in order to get the exact behavior you want for each vehicle. While developing my package, I spent way more time testing the vehicles and fine-tuning the parameters that actually writing code or rigging the vehicles.

 

I was already tweaking friction settings and messing with the CoM to get a feel. But what you propose seems to be a better solution. The GTA example that you did comes close already, don't you think?

So:
- Add custom gravity in FixedUpdate
- I do not think loops or sidewalls will be part of the gameplay; but you mean adjust the vector based on the cars upright rotation yeah?
- If you look at some of the trackmania 2 footage on youtube you will notice that the cars bank slightly in turns. WHat's the best way to simulate that?

Thanks for your time already, Edy!

 

I'm trying to add Turbo Pop Off Sound Effect When Changing Gears. But i can't seem to find the spot where i would put my audio code. Any suggestions?

 

How do you link the joystick to control the car on a IOS build ?

 

Hey edy,

I bought the vehicle physics because i thought it was really cool and wanted to make a racing game. I wanted to import 3D models in from Google Sketchup, but i found it really hard to switch the mesh objects of the car. Is there any way to switch the models so that they match up without scaling and is there an easy way to do this? Thanks

-Garrett

 

well i was close to buying this... but sadly i found one huge flaw with ur coding...

and i mean huge...

basically normal wheel collider is s**t. because it uses raycasting so it only checks for 1 point if it is touching the ground... now this is all fine when we are driving on flat surface,

now what happens when we try to drive up on pedestrian sidewalk for example.
we all know that wheel is round, and it cant touch the surface only at the most bottom point of the wheel... the wheel has to have raycasts going out on all angles of the wheel not just the most bottom point. because when you try to go up the sidewalk, the wheel will go through sidewalk, until it reaches most bottom point of wheel, and then it will go up the sidewalk...

this really is not acceptable. because when you are doing jumps and other stuff, it feels so weird, at all like proper car. because you hit your bumpers far too often than you would with normal wheel.

here are some pictures:

this is where the wheel should start to go up the sidewalk


this is what happens instead. wheel goes through the sidewalk, until it reaches most bottom part of the wheel, and then it goes up.


as you can see... this is not realistic at all, and major gamebreaker if you try to make some sort of driving game



now this video of unitycar 1.2 shows how this can be done with spherecast http://www.youtube.com/watch?v=hbaPUZDJpl8

anyways, i like your physics engine better than unitycar, thats why im writting this here... i hope you can fix this tire problem?

 

I meant tweaking the vector based on the floor's "up" vector for developing the gameplay (i.e. doing a loop allows 2 seconds of fake gravity pushing the car on the loop's road). If you are not using loops or sidewalls then you simply point the gravity vector down and adjust its magnitude.

For the car to bank in turns it's enough to keep the Center of Mass above the surface (i.e. a realistic position around the middle of the chassis) and adjust the suspension distance/springs to allow banking.

CarSound script. The calculated gear is stored at the variable currentGear. You can monitor for changes on it.

Find the function SendInput in the script CarMain. It actually reads the input from the standar Input methods. You can rewrite this method to your convenience for linking the joystick at iOS.

 

Can you post a link to one of the 3D models you've tried?

Recently (and I meant last week) I've developed a script that imports 3D models from Blender perfectly without having to tweak or fix anything in Blender nor Unity. I can now import a vehicle, add the rigidbody, the WheelColliders, the control script, and everything works. The 3D model must fit a few simple requirements that are easy to configure in Blender. So maybe we could import the model into Blender, give it a little massage, then import it in Unity.

Yes, yes, I'm fully aware of this problem. Spherecast is a rude method that have lots of drawbacks. I recall a version of UnityCar that used them, and the vehicle trying to climb the walls when you approached them. I have some ideas of how to overcome the problem in the next version of my vehicle physics, but actually I believe it's far more important to properly simulate the tire friction. That's what I'm actually working on. The visual problem of the wheel going through sidewalk is evidently noticeable to perfectionist freaks like you and me But it's not a problem in most cases.

Simulating a tire in 3D is far from being trivial. In fact is a huge difficult task if you want to do it right. The best approach so far is to keep the contact patch as a single point (RayCast), then use other workarounds to mitigate the visual problem.

I'm open to any other ideas and suggestions on this

 

I was just reading some stuff about how the Forza 5 guys were going about tyre simulation, and went so far as to end up knowing more about Pirelli tyres than Pirelli did! To have that sorta money to sink into a simulation! ahh well i'm pretty sure i bumped my contribution towards the Get Edy Some Serious Tyre Mojo quite a long time ago, i'm sure you'll do a fine job.

 

i dont think its only a matter of cosmeticsm or am i understanding this wrong? the raycast is always send directly down Y axis on WORLD coordinate, or is it LOCAL coordinate?

this is what it says in docs "The wheel's collision detection is performed by casting a ray from Center downwards through the local Y-axis."

because when you jump with car, and the car is aproaching the ground at lets say, 30 degrees angle... the LOCAL Y axis of the wheel wont be at the most bottom part of the wheel when the wheel touches the ground right? it will be pushed back because local coordinates will change when car is at 30 degrees angle... or will they?... :S

man i dont know this is some confusing stuff and i cant test it in unity right now, you probably studied this more... is it just visual problem, or is it performance problem too? meaning that the tyre doesnt behave realisticly as tire should...

basically what im asking: is raycast always send directly down on world Y axis, or does raycast gets all weird and S*** when the car is at an angle?

let me just say this in Top Gear style, "how hard can it be, to make a proper tyre that has, i dont know... 30 contact points? "

the problem is there for like i dont know 5+ years... ever since they introduced wheel collider into unity... and no-one came up with solution or what?


sure traction is more important, i agree... finish that first and then try to make this tire better

try this demo of unitycar 2.2 http://unitypackages.net/unitycar/joomla/demos.php?id=city it has 3D tires... press H to enable/disable it... i mean from my testings it works great...

 

Well... this is GTA 5...



There are workarounds for mitigating the visual problem. Some examples:

• A proper scenario design, so there are few elements suitable for exhibiting the effect. It won't be noticeable unless you're specifically looking for it.
• A proper vehicle design, so it's not easy to drive onto big sidewalks.
• Additional raycasts that detect when the tire is approaching an obstacle, then adding additional forces and moving the visual mesh upwards (the visual mesh only, the main contact raycast is still away of the obstacle). This seems the main trick used in GTA 5.
• Spherecasts (please, no).

 

Sure!! And it's going great! Expect some teasers soon (I mean in 1-2 months).

 

About the " sidewalk issue " , i have tried this : i have created a sidewalk with a curved edge to see if the problem remains. I have added a mesh collider set up as " normal " and " convex ". Well no luck : the problem is still there, as shown in these images :

 

Hey Edy!
first: great job! i bought the package and iam verry happy with it.
The only thing what i am missing is some kind of feedback/effects. for example some particles when the car is hitting another car or sliding against a guardrail. have a look at VS racing 2 for iOS. they made a good job there.

Are you planing to integrate something like this? or could you maybe show me how to do this on my own?

Cheers,
Kev

 

And another question: i have scaled up the empty prefab car to a factor of 25. so scale XYZ from 1,1,1 to 25,25,25.
because iam doing this for a 2d racer and using 2d toolkit. there is the value 1 in the scale settings one pixel. so you can place your 2d sprites pixel perfect onto the game canvas. so, if my car should be 25 pixels long i have to scale up the prefab to 25

but now the car is ultra slow. is there a way to adjust the parameters all at once?

 

You could try extending the collider beyond the visual mesh. This trick is also used at some locations in GTA 5.

Thank you! I plan to add this feature in a future version, mid-term. You could do it now in a similar way as the tire smoke. The basis is simple: create a particle system with the effect of sparks. Play with it until it shows the sparks in the way you want them. Then configure it not to emit particles by its own. Instead, you can monitor the impacts and enable it by scripting. The impacts are monitored and processed at the CarVisuals script, but you may find more useful to look at the CarSound script (search for "body drag" and "body impacts"). Here the audio effects are played upon contacts. You could use the same data for positioning the particle system and enabling it.

Well.... not recommended. Really. Vehicles using rigidbody and WheelColliders are highly recommended to use scale 1:1. Otherwise you need to re-configure them from scratch, and even then it might not behave as you expect, specially using so huge scales.

So 2D Toolkit imposes this scale? I'd try placing all the 2D Toolkit objects as children of a main gameobject with scale 1/25. Then you could use vehicles with scale 1:1 and the 2D Toolkit should keep unchanged. NGUI uses a similar techique: The root gameObject for NGUI automatically calculates the proper 1 = 1/pixels scale, so all children gameobjects assume 1unit = 1pixel.

 

hey edy, can you reply to my post too? you probably missed it

it is a bit up, from 4 days ago, and it only showed up like 1 hour ago because it was held in moderation -.- hehe

 

Well thank you for the tip, i will try it.

 

I've been messing around with Unity's wheel colliders for a while now but I've come to the conclusion that programming realistc, semi-realistc, or even arcadey vehicles that are also stable is pretty damn complex. So I think getting an asset for it would be best. Of the one's I've tried this one feels the most "right" to me.

I'm also impressed with the damage simulation. Are there options to adjust vehicle damage? And how does this feature work in relation to custom meshes?

 

It's sent down using the LOCAL vehicle reference. The angle with the surface can be considered as well for calculating the tire force (ej. camber).


The raycasts are actually the vertical lines. They start at the middle of the circle. If they collide with something inside the circle then a "hard contact" is generated and the vehicle is immediately pushed up with an impulse force. If they collide with something outside the circle, then a "soft contact" is generated and the suspension parameters are applied.

Why not? You can make as much contact points as you want (it's all just about CPU time). Even the entire mesh can be the contact object. The problem is to calculate and apply the forces for making the tire to behave as a tire. You can make all sorts of guesses, estimations, and arbitrary calculations in order to apply forces. Then you'll have lots of tricks and fixes for specific situations that will cause their own sideways artifacts each one affecting the simulation in some way, and the tricks still don't fix the situations perfectly. In the end, you'll have an overall simulation that *seems* to work nice and you can advertise as "fixes all your problems", but it just doesn't feel right.

I have a single reason for keep using WheelCollider in my simulations:

WheelHit.force

Here you can play with an early development draft of my upcoming tire simulation. This simulation disables all the force calculations in the WheelCollider making it friction-less (WheelFrictionCurve.stiffness = 0). Then I use WheelHit.force for calculating the tire forces myself.

http://www.edy.es/unity/prototype/webplayer.html

Summary of controls:
- arrows or adws: steer, throttle, brake.
- ctrl + down/s: reverse.
- space: handbrake.
- ctrl+space: lock/unlock all brakes.
- hold shift and move the mouse for moving the camera.
- c: change camera.

You would be surprised with the small code for the complete tire simulation in this draft (~50-60 lines of trivial calculations). Note that there are no friction curves -they are just clamped slopes, shown at the left side-, nor complex torque simulations, motor, etc at this draft. Just constant-torque powered wheels. Still, you can see how realistic can be a tire simulation when it's based on solid principles. Everything else in my next product is growing up from this base.

According to the specs in the page:

A previous version tried to implement them with spherecasts, with funny results (vehicles trying to climb the lampposts when approaching them, for example). Current version seems to use refined tricks, but still you have evident and unpredictable artifacts with wheels (mostly shaking wheels and vehicles) when approaching obstacles in certain common situations, negatively affecting the feeling of realistic simulation.

Referencing GTA 5 again, they seem to use raycasts with very selective and unobtrusive tricks for the most evident situations. I'm using the same philosophy in my upcoming tire simulation.

 

Thank you! Yes, all damage options are fully customizable.

The basis is simple: when an impact is detected, each vertex of the mesh around the impact point inside a given radius is displaced proportionally to its distance to the impact point. The direction of the alteration is given by the impact velocity vector. A random factor is introduced when modifying each vertex.

This work with any given mesh. The colliders may be deformed as well for fitting the new shape of the visual mesh.

In addition, you can configure "Deform Nodes". These are regular Transforms that get altered in position and orientation when impacts occur near their position. These are used to alter the wheels, so impacts near the wheels might affect the handling of the vehicle.

 

The problem with proper tyre modelling is - its slow, even for console games. You don't think about having 1 car, you think about having 20 + cars. With 80 proper tyre simulations it's a no go. In fact it's a no go on desktop games as well. So we need a fast option and a slow option.

An alternative is that you keep with a simple raycast wheel, but the tyre itself has it's own collision rules with the floor, say a sphere, so the visual moves up to compensate while the physics stay pretty much as they are. This is considerably less expensive and most of the time within reason should look just as good.

 

hey edy

thanks for reply, im a bit hangover right now, so ill have to re-read it tomorrow but from my understanding of it, its true what i was afraid, that it does affect performance when you jump


let me show it with this poorly drawn picture

basically when your car is about to land, the tire goes through ground instead of making contact when it should, because ray is sent at an angle, so basically car hits his bumper sooner as it would with real tire... right?



oh and btw... i played that prototype, real nice stuff you got going on there, i think when car jumps it actually behaves like real tire? or atleast better than regular unity wheelcollider
well yes the tire is too slippery, but thats another matter