[RELEASED] Truss Physics for Unity3D. Soft-body simulation plugin.

5:25 I don't understand it, according to the video I'm doing it right and I did not see the yellow beams :/

 

Your deleting the Tx Designer, open and close it using the Edit button only.

 

No i dont deleting Tx Designer i dont know why i dont see Yellow Beams

 

Did the issue with higher speeds ever get resolved? Still looks like the redcar demo gets unstable (like driving on ice) by only 170kph.

 

I have no idea sorry.

 

No, the fastest I've got is about 70-80mph with correct car weight, gear ratios, wheel radius and power output with Substep power set to 3, power 4 get me another 30mph with 10fps. I haven't yet got tires to handle realistically.

 

I'm afraid it'll be necessary to transition to another tire friction model and keep the actual "truss" tires rotating at a lower angular velocity. By using the the softbody for the contact patch, I think you could skip pacejka and do something pretty simple with as good or better results.

In a perfect world you would allow the truss tire to continue handling collision and just adjust its friction. as long as there's a good way to get collision info (faces in-collision and force I guess?), and adjust friction... it might not be that hard to pull off.

 

This might be possible if the engine was made open source, you can't gain any info on the physics code, other than manually adjusting the matter values maybe? And regards to none soft body code the only decent one I've seen is Vehicle Physics Pro, all the others are rubbish.

 

Yeah, I took a few minutes to mess with it. Setting matter friction to zero is easy enough and the Txbody still handles collision. so that part is good to go. ApplyImpulse has overloads to apply force to a specific node or even face (I'm not sure what "point" is unless it's the position on the face) ...but I don't see an obvious way to get from the "Contact" object of a collision (which gives you position and normal) to a node or face.

Without a good way to apply the force to the correct part of the softbody, you'll lose the softbody (especially tire deflection) goodness... and I gather the single parameter overload applies the force to the center of the TxBody so that'll be wrong too. Anyone know how to get the node or face involved in a collision?



Funny somewhat related story, I once had the dev for one of the popular car "simulation" packages (at the time) tell me that not only was it not a problem that he applied tire force to the center of the wheel (instead of the contact point) but that "it would be more realistic if he applied the force at the position where the suspension met the car." ...also the package featured no Ackermann steering geometry so you could see the steering tires fighting each-other to the death; it produced some wacky oversteer behavior.

 

Do you mean this:

private void OnCollision(TxBody.Contact _contact)

{

TxBody txBody = (!(wheelHit.bodyA == this.wheel)) ? wheelHit.bodyA : wheelHit.bodyB;

 

Sorry that was supposed to be _contact

 Vector3 velocity = _contact.relativeVelocity - _contact.averageNormal * Vector3.Dot(_contact.averageNormal, _contact.relativeVelocity);

 

_contact is what I would hope to use. You can see TxBody.Contact has lots of information about the collision including force and approximate position... but I need a performant way to get get a node or preferably a face so that I can apply the friction force to the correct part of the tire using ApplyImpulse.

 

Yeah first you need to get all the faces on an object which is in contact with bodyA and bodyB, usually bodyA will be the soft body, then debug draw those faces, from there create a function to ApplyImpulse in whatever direction the user wants on each face, I think this would be a good way to simulate tire tread, or any application which requires more friction in a certain direction. So can you not adjust the matter in realtime?

 

Oh I see what your thinking of doing now, have no matter and create your own tire physics using ApplyImpulse, this would be in essence your own Tire Controller, I'd say this will be quite complicated.

 

You will also have to set up your own friction preset, this is a huge job.

 

I didn't wire it up but I would hope those two fields are public. ...if not maybe you could just swap out the matters. I was playing around with it last night -- 200' skidpad and a g-meter -- and I'm afraid you might need to transition away from truss friction at a surprisingly low speed, like 10 or 20 kph worth of wheel speed. At least with the low detail tires in redcar.

Without access to the faces/nodes involved in TxBody.Contact - or at least a way to find/approximate them - I think it will be hard to use it for even moderate speed simulation unless I've missed something.

 

What kind of test was it you made then? And what were the results exactly?

 

You have RedCar Controller ?

 

I apply my shock forces where the shock is mounted to the chassis (strut mount), and apply my wheel forces where the wheel is mounted to the chassis (hub).

Are you sure you want to apply the tire forces at the tire contact point? The contact point is only used for properly calculating your tire data, but forces of each part should be applied where the part meets the chassis.

I've done a lot of thinking and testing on this subject and driving a car where the tire forces were applied on the tire contact point felt very wrong.

 

It sounds like you have it right. The example I was talking about was on a rigidbody that effectively had custom wheel colliders. Instead of friction being applied to the car where the tires met the ground, it was applied to the center of the wheel which reduces your moment/arm applied to the car... effectively makes the care more stable that it should be. ...which is a good thing if you are making an arcade racer where cars can pull two or three G's and keep tipping over "for some reason".

For Truss, the easy answer is to use a truss link to do your damping. Truss would take care of the rest and all the forces would go where they need to go. ...of course then you can't do different rebound damping rates, bumpstops, or non-linear rates so that's out for all but the simplest models.

The next best answer would be to use truss nodes for your shocks/dampers. Sounds like this is what you're doing. The nodes can be your shock attachment points, you use them to measure your distance/acceleration for the shock calculations and then you apply your impulse to them. Just like the native option, all your forces go where they need to go, truss just takes care of it.

Worst case here would be to measure the distance to the ground, apply damping to the body somewhere... then you've just got phantom forces occurring that the tires don't know anything about.

 

The test was pretty crude.
1) Confirm that I can set tire friction to zero and apply my own friction force.

Result: Yes, you can set tire friction to zero, allow the tire to continue to provide normal force and collision detection. You can apply force but I didn't see a good way to use the ApplyImpulse overloads that would allow us to accurately apply the force to the tire truss so that we can retain tire deformation, and generally keep the simulation accurate.

2)Evaluate truss tire friction. I laid out a 200' skidpad, wrote a geforce display (in terms of 9.8m/s^2 gravity), and manually drove a car around the skidpad while adjusting tire friction in an attempt to replicate plausible real world measurements.

Result:
a) even after setting all tire/wheel links to extremely high values (9x10^20, I didn't actually try "Infinity"), the tire and wheel was still too floppy. I recall that Rigs Of Rods had a similar problem and many of their models used "hidden" rods that supported the tire laterally from the center of the axle.
b) At even moderate speeds, 30/40 kph, the Redcar demo tires start have less friction that you would expect. I was forced to set friction coefficients that would produce 3 and 4 G's as the car came to a sliding stop and transitioned to static friction; even then the car became loose at low speeds on the skidpad.
c) I don't know how Truss handles friction. I assume it does not attempt to calculate surface area (since that would be less applicable for materials that don't have adhesion/mechanical locking). If it does, maybe the extreme tire deformation (from result "a") contributes to reduced friction at speed.
d) I think it's more likely that, especially with the not-very-round low-detail redcar tires in combination with deformation, at higher speeds the truss is spending time bouncing off of the node "corners" and not in contact with the ground. I haven't confirmed this yet but I'll try tonight.

 

Just had a go with this in the RedCar project. The ApplyImpulse() function does exactly what I had hoped, it applies a Vector3 force at a given point (node ID), so every custom tire/suspension package could be made to work with a truss based chassis.

The reason I'd like to use a custom tire model is because they are based on real world values (diameter/width/aspect ratio/load/pressure/load index/speed index) for calculating realtime stiffness & friction, guaranteed stability on different vehicle speeds/framerates and force feedback support, however I really like the idea of using a truss based tire for the deformation. (currently using pre calculated deformation with a vertex shader)

 

Do you see a way to find the node that produced the contact/collision? I really like the idea of using that "face" overload... and even that isn't really enough. I'm pretty sure things will get weird if you apply all force to a single node. ...unless you are just willing to apply it to the wheel hub or something and then you've got the exact same inaccurate moment/arm issue I described with the rigidbody.

 

No I agree when using a full truss based wheel it would be better to apply it at the correct position and let truss take care of the rest. I've also looked at the contact averageNormal and averagePosition but I can't seem to come up with a way to get the nearest node/face from the contact averagePosition.

In SkidMarks.cs, the m_wheel.truss.nodesSet.Where() might be a good starting point, but I'm not sure if the node closest to the average position is what we'd like..

 

If we could get that node, it would be a pretty good start. I'm afraid that locating the node in Linq (based on an approximate location no less) will be pretty costly, especially for a more detailed tire... but that may be all that's exposed.

Pretty clear that the Contact already has the nodes involved... Really need HeartBroken to come back and and add this last piece... There's $100 in it for you, guy.

I'm willing to open source work on an alternate tire model.

 

Oops. Yeah. It looks like this is what's happening. Confirmed initially by looking at contact events and found many physics steps where 3 or more tires were not in contact with the ground. ...then I played around with timescale and it's easily visible.

Quickly verify for yourself with no code, In the editor, Get redcar up to speed, maybe 60kph (although it's visible much lower), pause the player and go to Project Settings>Time. Set time scale to .01 and resume the game. Watch the oscillations where often a tire node will rebound away from the ground and the next node does not touch down for a while. The tire spends maybe nearly 50% of the time not touching.

It's not a mathematical instability problem, it's just what would happen if you had a tire shaped a little too much light a stop sign. More nodes would help; not sure how many it would take to be good, maybe not that many.

If there was a path to adjust the elasticity for collisions with those nodes (need them to be pretty inelastic) that might be a good option but of course without source code I don't think that's likely.

 

So are you saying after all this time it's not actually a physics calculating problem that's stopping the tires from handling properly(friction) and getting up to correct speed, but the fact that not all the nodes are contacting the ground surface properly? Wheel Truss design problem? In the redcar demo you can press z to slow the timestep down, this is what I've added to my project, just change the value to almost nothing to slow it right down.

 

See if this helps, timestep set to 0.001

 

I can't see much exciting happen in that. I found that .001 was less useful, the oscillation frequency is relatively low (at least for the redcar tire) so you've got relatively long periods of good contact and with somewhat shorter periods where the tire has pulled away from the road. For me it's easier to see at .01. Once you've found one and see the pattern you can slow it down more but it's easier to see in motion. (or it's possible I guess that your tire doesn't have the problem... but if you're car is getting loose at speed, I'll bet you will see it)

I noticed that as delivered the truss UI Gizmo doesn't update very often and really just ends up being distracting and blocking your view... I had good luck just mouse-looking around and zooming-in with the game camera. edit* I thought it would be trivial to just get the gizmo to redraw more often but the gizmo is redrawing fine, it's just that it does not update the links; they never show deformation just the original state of the truss.

I haven't spent much time on this; I'm assuming that as we slow down the timescale, truss physics steps are still occurring at the same frequency so we are getting a super accurate simulation with 100 (.01) or 1000 (.001) more steps per frame. ...but if I can see the oscillation setup and start running with more steps, it's going to be there with less steps (and more interpolation) but probably much more exaggerated.

 

Especially watch the rear tires. There's a huge rebound starting at 24 seconds on the right rear tire.

This video was done with much higher friction coefficients in the "Wheel Matter". I didn't realize. This issue may be even more visible with lower friction values.

 

No mine don't do this, it's the Redcar tire truss which is causing this issue, mine rotate smoothly.

 

Do you not have issues with too little grip at higher speeds? I don't see any big oscillations in your video (looking past the truss gizmo), but it does look like it spends time with nodes not in contact; I'm wondering how Truss handles that.

 

Here is a better view and at 0.1 timestep.

 

No this seems to be fine, but I can only reach about 70mph anyway, it's almost impossible to get realistic donuts though, I'll do a video showing it.

 

It does look pretty good... My only suggestion is to put it on a big flat plane, go as fast as you can in straight line (I assume you reach a point where the car may a well be on ice, I didn't mean to capture my video with the car turning, it's not required or helpful) definitely don't drift, we want to see what's happening when the car should be pretty planted, go to .01 timestep... and try to get the camera just high enough off the plane/ground so that the ground is still visible. See what there is to see. I'm suspicious that even when there isn't a huge oscillation running, it may be that Truss is capturing the percentage of time between tire nodes contacting the ground? Otherwise I don't know.

 

Here you go, my top speed.

 

Looks pretty suspicious to me. I see a lot of vibration between the tire and ground. Is that .1 or .01? Looks like 1 tenth but either way it might be too fast to really see what's happening.

*edit, and if I'm not mistaken, even with that video, by setting youtube to .25 playback, you can see some periods where the entire tire truss is clearly bouncing and spending nearly half of the time not in contact with the ground.

I think the endgame here is that this will be a limitation of this type of physics simulation... it will probably require a workaround, e.g., alternate physics model for tires at speed... I'm just trying to identify the root cause before attempting to fix it.

...unfortunately it may require some creativity to come up with a good solution given the tools we have available. I was digging around the in the TrussPhysics c++ dll and can see some more goodies in what I expect is the "contact" object that aren't being passed back with the rest of the data from TxWorldContactGetInfo... possibly what we need. Trivial to expose with the source code. ...not so much without.

 

It's .1 So this could be the route of the problem, that small time the truss spends off the ground could mean that extra 20% speed the vehicles need. Yeah it's just a shame we can't gain access to the source, this could be fixable then, which would make it more viable for racing games.

 

Agreed, or maybe we could try an inverse lookup by checking which of the tire's nodes are colliding with the road, but yeah, you're basically working around a problem (in a costly way) that wouldn't be there if we could access the source.

 

It might be worth contacting him, if he's abandoned Truss surely there isn't much sense in keeping it close sourced, unless he has a future agenda. It's a powerful tool and it would be a shame to waste it.

 

I imagine he still get's $100 every now and then for it. I suppose it's not technically "open source" if you have to pay to license it for commercial use but... I'd be fine with paying for commercial use.

 

Trouble is it's not really quite ready for commercial use, is there not a way of buying it, gaining access to the code then writing extensions to get it to do what's needed for different applications? Like fixing it for Tire models.

 

It is what it is, and I think it's an okay starting point, but If it's not open source we can't really work on it as a community.

I wish the BeamNG guys hadn't gotten so pre-occupied with .Drive, there was a time when they planned to release a plugin for Unity. I assume they have no plans for that now.

 

I tried in September, i even asked for licence purchase disponibility , no success unfortunately.

Considering the support they will have to provide for said plugin, the competition it will generate against them, and the asset flippers making a bad use of it, i think they most likely will not.

 

I suppose we could fork RigsOfRods for use with Unity. ...keep it in a dynamically linked library and the GNU license isn't a problem.

 

Sounds good to me lets go for it, it's open source, I could test it with my project using high speed vehicles. Wouldn't it be a lot of work to create editors for it?

 

Pretty big project. I wouldn't want to do it alone but I've been waiting for 4 or 5 years for someone to bring softbody physics to Unity and it kind of never happened. It's probably time to get the opensource community involved. Ironically I've got to work some overtime tonight but I'll make a thread with a link tonight or tomorrow.

 

I'm actually working (lazily) on a new system from scrach

But i don't know what will be the outcome, for now there is a long way to go.

 

Let's do that then, see how it goes, it'll be worth it because I think Unity and the community will benefit a lot from it. Truss is awesome but lacks the support.

 

That's really impressive! Looks just like Truss but you can modify settings on the fly, huge project.