vehicles

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

vehicles

Postby Julio Jerez » Sun Sep 09, 2018 5:17 pm

I am opening this thread to talk about vehicle.
the vehicle in the custom joint is very cool, but it has few problems.
the first is that vehicle dynamics are better simulated in generalized coordinate using lagrangian formulation.
The model in the engine is a hybrid, it uses the rigid body solver which is a reduced coordinated system and it uses the result to adjust the main body velocity in a three dof pseudo lagragian model.
it shows sign of realism but I am not satisfiedd with it.

With the knowledge that I acquired on various implementations, my idea is to make a full lagrangian model that works the opposite way, it solves the vehicle in generalize system them calculates the net result to couple with the engine.

This is not a ray cast car, far from it, my goal is a very realistic model that can work at low and high speed.

The second problem is performance. Using the rigid body to solve connected parts with very high rotation rates, that moves a very high speed and high angular velocity is a quite difficult task.
I am surprise it works at all.

But the fact is that a full vehicle end up with about a dozen body parts and even more joints: chassis, tires, engine, differential, gear box, and any other accessory.
This makes the performance drop quite fast when adding many vehicles.
It also make the tuning difficult because any tweak must no break existing funtionality and that is a problem when use two systems.

so I am thinking to make a separate library called dVehicle that will implement this new vehicle.

what do people think?
Julio Jerez
Moderator
Moderator
 
Posts: 10954
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: vehicles

Postby Slick » Sun Sep 09, 2018 9:28 pm

It sounds interesting. When I get Newton running I use a maximum of 20 vehicles at once. I wonder how many vehicles you could realistically use at the same time.
Slick
 
Posts: 266
Joined: Sat Feb 07, 2004 7:24 pm
Location: Los Angeles

Re: vehicles

Postby Julio Jerez » Sun Sep 09, 2018 9:33 pm

20 vehicle is fine, but the performance is just one aspect.
My biggest concern is physics fidelity.
We wnat a vehicle that is fun to drive at any speed, that is not to hard to set up.
Julio Jerez
Moderator
Moderator
 
Posts: 10954
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: vehicles

Postby MeltingPlastic » Sun Sep 09, 2018 10:02 pm

So the stability/performance improvement can come from the fact that the vehicles joints are all local to the main body of the vehicle? This is what makes the math more robust?

If that's the case could that simplification be extended to generic joints? (perhaps the engine automatically picking a "root" body to build its new local coordinate from?)
MeltingPlastic
 
Posts: 221
Joined: Fri Feb 07, 2014 11:30 pm

Re: vehicles

Postby Dave Gravel » Sun Sep 09, 2018 10:47 pm

I think it is a good idea.

Maybe it can become more easy to understand the code and how to use it.
It's not a easy task to get a nice simulation by mixing multiple components from anywhere in the sdk.
The vehicle simulation in self is rarely done with only some lines of code.
In general it is pretty complexe and it's better to have it all in one place.

Currently you need to use body dynamics, joints, materials collision system, you need to fit the visual at same speed update.
Same about the input control.
Anytimes newton sdk is updated you can get different problems because you use multiple components from the engine.
All of this components have self configuration options and self specific behaviours on many differents cases or engine setup.
It can become more easy to debug problems if all come from the same (place)lib.

Like you have say the vehicle from joint is fun and you can get very good simulation by tweaking all.
It's a very good sign I think that newton can handle it pretty good, and it from far in time.

Exemple from my multi body vehicle you can get nice simulation by taking the time to tweak it.
It's hard to make a very fast car because all components have self limitations at different speed.
The only way I have success to get faster simulation with multibody is by slicing the update loop timestep.
Again it cause problems because all the scene is faster it request more cpu and it reduce the possibility to have high object count in the scene.

Others problems coming when you like to make AI or Multiplayer.
It's hard to control a multi body construction by AI, You can't cheat over all body&joint to correct the vehicle position like you can do with raycast vehicle.
I don't say that is impossible but it is a heavy task in runtime simulation.
It's not really possible to use multi body for multiplayer and predicating all body over the network. Most of multiplayer system is not able to handle dynamics object, When it can the object count is very little and easy to make it glitch.
Maybe it can become possible if the multiplayer do a complet streaming of the 3d scene, But I don't think it is currectly the case in most game they use again simple data stream compression and udp + prediction and replication.
My current vehicle multibody is good for demos, or some specific simulation cases.
It's not a real game solution or for fast simulation car, You can have many fun and pretty nice results but for big game it's not really usable.

Currently when you need AI or multiplayer you need to use Raycast vehicle, and same if you need high speed vehicle.
The problem with raycast is to reproduce nice collision responses with other things in the scene.

One thing that I love with raycast vehicle, The tire can go pretty much over all type of edges without take care. The tire can have penetration but the collision results is never really bad at the point to make explode the simulation or become uncontrollable like with multi body sim.
Just it is more hard to have real life simulation and good collision responses with raycast vehicle.

If with the vehicle lib it's possible to get a bit of both simulations in same place it can become a very nice tool.

I very love to play with anythings about physics, The vehicle is one of my prefered simulation.
One thing that I very don't like about vehicle simulation, It is when I see a simulation that you can see the vehicle frame is all calculated controlled behaviours.
It look like a kuka robot holding the car in the air, this is a very platonic simulation case to see.

I'm all yes for a new dVehicle lib and test it.
Sorry about my english.
You search a nice physics solution, if you can read this message you're at the good place :wink:
OrionX3D Projects & Demos:
https://www.facebook.com/dave.gravel1
http://orionx3d.googlepages.com/
https://www.youtube.com/user/EvadLevarg/videos
User avatar
Dave Gravel
 
Posts: 690
Joined: Sat Apr 01, 2006 9:31 pm
Location: Quebec in Canada.

Re: vehicles

Postby Julio Jerez » Mon Sep 10, 2018 3:46 pm

MeltingPlastic wrote:So the stability/performance improvement can come from the fact that the vehicles joints are all local to the main body of the vehicle? This is what makes the math more robust?

If that's the case could that simplification be extended to generic joints? (perhaps the engine automatically picking a "root" body to build its new local coordinate from?)


there is a lot to unpack there. and I am always reluctant to give answerer to those questions but here we goe.

The answer is yes the stability come from the joint been solved in local space, but that's not an absolute fact. The reason the local space solution is more stable is because the system can factor the system matrix faster.
however this is only mathematically system that we call local space can be represented by acyclic graphs (that is each child node have one parent) and there are well known algorithm that can factor the system matrix in linear time.

If you have a reduce coordinate system solver that can factor the matrix every time then it does not makes any difference and the reduce coordinate system is better simply because is more general been able to deal with loops naturally.

it just happen that simple vehicles, simple organic skeletons and most articulated contractions can be represented by a acyclic graph. while general rigid body dynamics is always represented by full cyclic
graphs, Therefore solver that work on local space offer an advantage over solver that work on global space which have to be iterative.

The advantage is only up to a point, as you start adding kinematic loops, then you end up with formalizing an full linear system to solve the linear system, therefore if the system become complex them is not longer advantageous.

take for example a very simple car, you get the chassis and for tire.
this can be represented by a simple skeleton.

the moment the tire touch the ground, the each one form a kinematic loop because of you start at the floor as a child of a tire, then the floor can have more that one tire as parent.

if you the consider say the engine connection to the tire to transfer torque, now you get each tire with the chassis and the engine as parent, and so on.
as you can see it can get complex very quickly.

The good knew is that the complexity you can manage and make assumption without having to make changes to the general solver. and that is where the biggest advantage is.

I committed the skeleton of the library already, and it place a simple chassis, there is no visual , I will add that later.

If you, and anyone is interested, it will be good if you guys adopted early so that is no as hard to figure out when is all completed, and also I can get feed back and recommendation.

It just happen in the pass that I put lot of work, and when we get something working some one come with a request that required almost a full rewrite.
Julio Jerez
Moderator
Moderator
 
Posts: 10954
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: vehicles

Postby MeltingPlastic » Mon Sep 10, 2018 4:08 pm

Thanks for taking time for the explanation. It makes sense to me that acyclic graphs must more straight forward and you can simulate solutions directly without having to use iterative methods to "massage" things into place.

The Vehicle sounds awesome. looking forward to integrating it
MeltingPlastic
 
Posts: 221
Joined: Fri Feb 07, 2014 11:30 pm

Re: vehicles

Postby Julio Jerez » Sun Sep 30, 2018 2:52 pm

I add some work on the vehicle set up, no much really
now it place the chassis and add the tire.
is will be good if the people interest it pick it up so that suggestion are taking in to consideration early.


one such issue is the coordinate system, in teh demos I use
x is front, y is up, and z is right

many engine use different systems like
z front, y up, x left

in automotive book is
x front, z down, y right

for all these the vehicle passes a locak frame the spcifi the vehicle cordinate system, but this frequently lead to bug tha can go for a long time udetected until some one use a diffrent system sees it and then I have to go back and revisit lot of stuff, this is why is good to test as we go.

next I am adding visualization, before I move to write the local solver, whi is basically copy and paste and edit of code already in the engine.
Julio Jerez
Moderator
Moderator
 
Posts: 10954
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: vehicles

Postby Leadwerks » Sun Oct 21, 2018 7:28 pm

A year later, I am getting ready to release the final version of my engine and put vehicles back in. I was planning on doing our own system with hinges and springs. We stopped using Newton's vehicles because of the problems with the coordinate system being sideways, but an update on vehicles is definitely welcome. Do you expect this will be ready to use by December 1?
User avatar
Leadwerks
 
Posts: 515
Joined: Fri Oct 27, 2006 2:54 pm

Re: vehicles

Postby Slick » Mon Oct 22, 2018 6:20 am

I am used to:

z front, y up, x left
Slick
 
Posts: 266
Joined: Sat Feb 07, 2004 7:24 pm
Location: Los Angeles

Re: vehicles

Postby Julio Jerez » Mon Oct 22, 2018 12:03 pm

I am hoping to get a working model by the end of the week.
then I will and the coordinate system conversion next,
for that I am going to switch to a standart file format.
fbx which I read over autodesk is free to used, is moder and well adopted. I added the library to the third party folder.

I hope this helps with the integration, since models can be opened by any viewer, even visual studio.
Julio Jerez
Moderator
Moderator
 
Posts: 10954
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: vehicles

Postby Slick » Mon Oct 22, 2018 12:34 pm

I'm not an expert but I have used fbx before and it works well. The latest format that is spreading and getting well adopted is GLTF. I'm not sure it is worth you investing time in it but from a graphics pipeline with meshes it seems to be doing well. I've played with it a bit.
Slick
 
Posts: 266
Joined: Sat Feb 07, 2004 7:24 pm
Location: Los Angeles

Re: vehicles

Postby Leadwerks » Mon Oct 22, 2018 7:53 pm

I look forward to using it! :D

I don't care what model format you use, but I have looked at the GLTF format and it's pretty good. We presently rely on FBX.

This is how our coordinate system works. RGB is XYZ:
552px-Space.png
552px-Space.png (44.71 KiB) Viewed 1912 times
User avatar
Leadwerks
 
Posts: 515
Joined: Fri Oct 27, 2006 2:54 pm

Re: vehicles

Postby Julio Jerez » Tue Oct 30, 2018 11:48 am

ok, I think I now has the framework of a basic vehicle, that drives like a car, not like a collection of bodies linked by joints.

It drives like the Brady Bunch SUV but is quite impressive for AI vehicle.
I am even considering letting this be the very basic option because this is the ideal car for AI control.

anyway, I was looking at the file format to adopt for all demos, and that GLFP does not inspire me any confidence, when I open up the site the first thing I read is that this is another brain child of the Khronous group that now try to compite with their own collada fiasco. I am not even going to try to read anything else about it. For me if it comes from Khronos Group, that's reason enough to reject it.
and I do not think I am alone with that opinion.

anyway I think I will go with FBX. that seems to be wide adopted by every one.
Julio Jerez
Moderator
Moderator
 
Posts: 10954
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: vehicles

Postby Dave Gravel » Tue Oct 30, 2018 12:35 pm

Hi,
fbx seen good and it is present in free modeler like blender, I'm just not sure about license.
https://forums.autodesk.com/t5/fbx-foru ... -p/4032339
I currently use fbx and .blend in my engine and in my ut project.

About the new vehicle tire model.
Do you have get times to test the tire over a mesh or terrain ?
Just to see if the tire penetration is again present on mesh edge corner or terrain edge.
With my old multi body method it is one of my biggest problem from very far in time, I'm not able to idle vehicle tire correctly over a meshes level. The tire stay stuck in the edges or it make the vehicle driving unstable.

Edit:
I don't have add the dVehicle in my project again but I have test the demo and it seen to work very good.

Thanks.
Last edited by Dave Gravel on Tue Oct 30, 2018 1:53 pm, edited 1 time in total.
You search a nice physics solution, if you can read this message you're at the good place :wink:
OrionX3D Projects & Demos:
https://www.facebook.com/dave.gravel1
http://orionx3d.googlepages.com/
https://www.youtube.com/user/EvadLevarg/videos
User avatar
Dave Gravel
 
Posts: 690
Joined: Sat Apr 01, 2006 9:31 pm
Location: Quebec in Canada.

Next

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 3 guests