I find the RigidDynamicActor and Chassis RenderActor use the same coordinate .
Also I find the RigidDynamicActor has a member mBody which use the the mass center as origin.
I think the RigidDynamicActor should rotate around the Mass Center not the RenderActor Center.
So why update RigidDynamicActor in this way?
The Mass Center is just set below/forward the Actor center
I think it’s not very accurate when I implement a vehicle in practice.
So How to compute the accurate Mass Center of Vehicle?
A wheel’s CMOffset is vec3(0.9,-0.75,1.5)
The unit of CMOffset is meter ?
The vehicle is parameterised relative to the centre of mass of the rigid body rather than to the actor. This is documented extensively in the guide. There are some advantages to this but there are also some disadvantages. Whether you think this is a positive or a negative really depends what you are doing and whether you have manufacturer data to hand.
There are multiple ways to compute the mass center of the vehicle but most users backwards rather than forwards. I mean that it makes more sense for games to start with the centre of mass and then work out the parameters that reflect that rather than work forwards. The reason for this is that the vehicle model is only a model and doesn’t have any knowledge of density distribution or the mass of steering wheels or the foam used in the back seat. Computing the centre of mass from the vehicle parameters will always be a very rough estimate. It is far better to start with the kind of handling that you want to have. Do you want the vehicle to be heavier on its front wheels or its rear wheels? If so, then by how much? That will allow you to specify the centre of mass offset relative to the actor center. You can then compute the wheel centres relative to the centre of mass and use the function PxVehicleComputeSprungMasses to compute the masses of each suspension line.
So If I want to simulate a BMW in VR Environment ,I need to get the manufacturer data to compute the mass center ?
The manufacturer data should have density distribution /mass of steering wheels and so on?
Also I should consider the mass and position of passengers.
I think it’s still hard to compute the accurate mass center…
Computing the mass centre is indeed a very difficult exercise. The manufacturer data might quote the roll centre [url]https://en.wikipedia.org/wiki/Roll_center[/url] but that isn’t quite the same as the mass centre. I doubt anyone truly knows the mass centre of a vehicle. It is also a shifting value because adding passengers and luggage will change the mass centre.
We might expect that the car is designed to divide the mass fairly evenly between the four suspension lines. Therefore, it is likely that the mass centre lies near the centre point of the four wheels. The roll centre can then help to estimate the vertical coordinate of the mass centre. These, however, are all estimates and deductions. That’s about the best that you can do. The centre of mass is only the tip of the iceberg. What is the moment of inertia of a vehicle? I doubt anyone really knows. What about tire longitudinal stiffness? All we can do is estimate and test.
The PhysX vehicles SDK is not designed to accurately model specific cars. The intention is to provide behaviour that seems reasonable and plausible. The intention is also to provide a paramaterised model that allows different behaviours to be easily created just by changing a few numbers. I would expect a developer to start with an estimation of the centre of mass and moment of inertia and then tweak those numbers until they get the behaviour that they want.
I did once validate PhysX vehicles against real vehicle data. Some numbers did end up being educated estimates: centre of mass, moment of inertia, clutch stiffness etc. Sensible tweaks of the values allowed reasonably good tracking of a real car. Manufacturer data is necessarily incomplete and not always a good fit to a physical model.
Computing the mass centre is indeed a very difficult exercise. The manufacturer data might quote the roll centre [url]https://en.wikipedia.org/wiki/Roll_center[/url] but that isn’t quite the same as the mass centre. I doubt anyone truly knows the mass centre of a vehicle. It is also a shifting value because adding passengers and luggage will change the mass centre.
We might expect that the car is designed to divide the mass fairly evenly between the four suspension lines. Therefore, it is likely that the mass centre lies near the centre point of the four wheels. The roll centre can then help to estimate the vertical coordinate of the mass centre. These, however, are all estimates and deductions. That’s about the best that you can do. The centre of mass is only the tip of the iceberg. What is the moment of inertia of a vehicle? I doubt anyone really knows. What about tire longitudinal stiffness? All we can do is estimate and test.
The PhysX vehicles SDK is not designed to accurately model specific cars. The intention is to provide behaviour that seems reasonable and plausible. The intention is also to provide a paramaterised model that allows different behaviours to be easily created just by changing a few numbers. I would expect a developer to start with an estimation of the centre of mass and moment of inertia and then tweak those numbers until they get the behaviour that they want.
I did once validate PhysX vehicles against real vehicle data. Some numbers did end up being educated estimates: centre of mass, moment of inertia, clutch stiffness etc. Sensible tweaks of the values allowed reasonably good tracking of a real car. Manufacturer data is necessarily incomplete and not always a good fit to a physical model.
I would guess that pretty much all vehicle models use either a single rigid body or multiple rigid bodies. They will all need to know the centre of mass. Even military simulations use vehicles based on rigid bodies. Additionally, PhysX isn’t too far from CarSimEd, which was also based on rigid body mechanics. Anything that computes tire or suspension forces will need to apply those forces to something that is almost certainly a rigid body.
The core of the model is that there is a rigid body and there are forces arising from tire and suspension forces. The rigid body’s transform helps compute the forces and the forces tell the rigid body how to move. I’m guessing that pretty much all vehicle models work on that principle and only differ to the degree of complexity of the model. Some models have more sophisticated tire models, some model the gears and clutch more accurately, some model the suspension system with multiple bodies coupled with constraints. PhysX does all of these in a fairly simple way but it shares the core model of a rigid body moving under force.
The problem with all simulation is that the model used is always an approximation. I wouldn’t even say that the centre of mass estimation is the biggest approximation in a vehicle simulation. Tire forces, for example, are always going to be approximate because it is hard to mesure the regression data for a specific tire on a specific car on a specific road in specific temperature conditions. Even if we had a great model it would be very difficult to drive that model with accurate data. The suspension model is also prone to error. PhysX uses a simple spring but it would be easy to extend that to a jointed system that more closely mimics reality. If we did that we would be faced with all sorts of technical problems like how to accurately model a non-linear spring or one that has bi-directional damping. Even measuring the stiffness graph of a non-linear spring is a significant challenge. How would we even measure that data so that it could be plugged into a vehicle simulator? Finally, there is the timestep of the simulation. As the timestep reduces the simulation ought to to converge but that requires very, very small timesteps that are computationally expensive. Making a good timestep choice that balances computational expense with accuracy is fraught with difficulty. This is all hard.
It is always difficult to map the real world to physics modelling parameters. That is true of all vehicle models as well as PhysX. I would say that PhysX is a fairly simple model; more sophisticated packages will ask for more and more parameters that might not be readily available to the user. The best we can do is to improve our estimates by calibrating the simulated motion against real data.