Tag: physics

Wheel physics revisited

Posted on

Last week I decided to take another look at the wheel physics implementation, in particular the tire friction model.  First let’s quickly recap how the wheel physics works in GearBlocks.

Wheel physics recap

Every update I find the contact point on the ground directly below the wheel and position a configurable joint there.  This joint is then connected to the wheel at the closest point on its outer edge to the contact point on the ground.  The joint has a linear limit set up to prevent the wheel going below the ground, which provides the wheel to ground collision response.

For friction between the tire and ground, I set up the configurable joint’s velocity drive to constrain the wheel’s velocity at the contact point to zero, with the maximum force on the drive being set to the friction force.  To calculate the friction force, I use a method inspired by the Coulomb damping model, where the friction force equals the product of a friction coefficient and the normal force at the contact point (i.e the force preventing the wheel from sinking into the ground).

Previous tire friction hack

To find the normal force I need to know what force the configurable joint’s linear limit is applying to keep the wheel above the ground.  However, it used to be that in Unity there was no way to access this (even though it was available in PhysX), so I had to estimate the normal force by taking the total mass of the construction, dividing it by the number of wheels, and multiplying it by the acceleration due to gravity.  Basically a total hack, because it assumed the vehicle’s weight was always distributed exactly evenly over each wheel.

Improved tire friction

Well the good news is it turns out that fairly recently the joint force was made available in Unity (via Joint.currentForce), so I’ve now switched the implementation over to use this to find a proper normal force.  This means that in a vehicle, weight distribution now affects tire grip, and because the normal force is now being calculated dynamically, weight transfer also affects grip in the way you’d expect, which is pretty cool.  This all sounds great, and is a definite step in the right direction, but there’s a problem.

Formula magic

By using Coulomb damping I’m effectively assuming that tires are rigid (i.e. non-elastic) which of course they’re not.  In reality a tire’s grip changes depending on how much it is sliding across the ground (tires actually develop peak grip when sliding slightly).  Not only that, the longitudinal (forward and back) and lateral (side to side) grip of a tire behaves slightly differently.  So most driving simulations instead use some form of “friction curves”, equations that you plug slip amounts into and get friction forces out.  The industry standard is the Pacejka tire models, sometimes known as “magic formulas”, these are empirical models that have been made to fit real world measured data, the equations themselves don’t have any basis in real physics as far as I can tell.

Sounds simple enough, so why not use the magic formulas?  Well, after looking into this for a bit, I can see several problems:-

  1. The equations for the Pacejka curves themselves are complicated and have a ton of tuning parameters, something I’d prefer not to have to deal with.  Probably overkill for what I need anyway.
  2. The slip values used to lookup into the curves are actually slip ratios.  The upshot being that at low velocities numerical instability becomes an issue (and at zero velocity you’ve got a divide by zero – the slip ratio is undefined!)
  3. Because you need to evaluate longitudinal and lateral slip separately, there’s the question of how to combine the resulting separate friction forces.  You can’t just add them together because a tire can only develop so much grip at any one time, the more longitudinal grip you “use up”, the less lateral grip is available, and vice versa.  This effect is sometimes known as the tire’s “traction circle”.

I’m sure there are ways around all of these problems.  The Pacejka equations could be substituted with something simpler for example, and I’ve seen various ideas out there that attempt to properly combine longitudinal and lateral slip.  The slip ratio numerical instability issue I’m less sure about at the moment, apparently a lot of driving sims switch to another simpler friction model at low velocities to get around it, seems a bit hacky though.

Another related issue is that I’m not even differentiating friction levels between different surfaces (e.g. tarmac vs. dirt) yet, so perhaps a realistic tire friction model isn’t worth it at this point?  Anyway, something to keep thinking about and revisit again in the future.

GearBlocks Demo 0.4.6034

Posted on

GearBlocks Demo 0.4.6034

Unity 5 upgrade done (mostly)

The last remaining bugs caused by the Unity 5 upgrade (at least, those that I’m aware of) have now been fixed.  In the end I decided to postpone migrating away from the deprecated APIs for now as the game still builds ok without doing this (albeit with some warnings), and it’s been so long since the last build – I wanted to get one out as soon as possible!

New world tool

image

There is now a “world tool” in the game (that can be activated by pressing 0), and with this tool active, holding / pressing Q brings up the world tool UI.  In this UI you’ll find the world constructions tab (moved over from the builder tool UI).  You’ll also find a new “settings” tab that allows global settings to be changed during gameplay.  You can change things such as the current time of day, but perhaps more interesting are the new simulation settings.

These allow you to adjust the trade off between physics simulation accuracy and performance.  For example, if you have a slow computer, you can reduce accuracy to get a better frame rate.  Or, if you have a model that requires higher physics accuracy, you can increase it at the expense of performance.

Here’s a brief explanation of these settings:-

Update rate – This slider sets the number of times per second that the physics simulation is updated.  The higher the update rate, the smaller the time step from one update to the next which gives greater accuracy, at a higher performance cost.  The sim time step is particularly important for constructions that have parts with high velocities, especially large angular velocities (i.e. high RPMs).  In these cases, it may be necessary to increase the update rate to prevent instability or “glitching”.

Constraint accuracy – This slider controls how tightly rotary bearings, linear bearings, and so on are constrained (how little they “sag”).  It also affects how much torque gears can transfer without slipping.  If a construction has parts that exert large forces between moving attachments or gears, this may need to be increased (again, the downside being reduced performance).

A science experiment

As (I think) an interesting aside, it turns out that actually two factors affect how accurately constraints are resolved.  Increasing the number of physics solver-steps-per-update increases constraint accuracy, but so does reducing the simulation update time step.  However, I want the player to be able to adjust the sim update rate without also affecting constraint accuracy, so I did an experiment in the game to try and figure out how to keep a consistent level of constraint accuracy while varying the time step.

image

I built a construction that put some gears under torque loading (using a lever and a big weight on the end to provide the torque loading).  At various sim update time step settings, I adjusted the number of solver-steps-per-update to just the point where the gears no longer slipped.

image

Plotting these results out on a graph showed what looked to be some kind of power relationship.  With a little help from Wolfram Alpha, I found that yes indeed the number of solver steps required was proportional to the time step raised to a power – a power of 2 in fact, handily enough!

So, now I set the number of solver-steps-per-update equal to the square of the time step multiplied by the constraint accuracy value that the player can adjust, and this gives a nice consistent behaviour.

Collision behaviour improvements

You can no longer accidentally deselect or unfreeze constructions under the ground or inside other constructions (this used to generate large impulses as the physics engine tried to resolve the collisions, flinging stuff all over the place).  For the same reason, I have also prevented collisions between frozen constructions and the player or other non-frozen constructions.  This has the added benefit that you can now walk inside frozen constructions to get a different perspective when building them!

Well, this is a big update for GearBlocks with lots of changes, particularly the Unity 5 upgrade.  There could still be bugs or problems introduced that I haven’t spotted yet, so do please let me know if you find any, thanks!

Unity 5 physics issues finally sorted

Posted on

At long last, I have resolved all the remaining physics problems I was having with Unity 5!  As I mentioned in my previous blog post, I had solutions that I was working on for most of these issues, but the one thing I wasn’t sure about was how to fix the joint velocity drives.

Configurable joint drives

One of the things that changed from PhysX 2.X and 3.X, is the way that joint drives are configured.  They no longer have a mode flag to specify whether they are position or velocity drives.  Instead, if you want a “position drive” you set the drive’s spring value to be non-zero, if you want a “velocity drive” you set its damping to be non-zero (and if you set both to non-zero the drive behaves as a damped spring).

The question is, what non-zero value to actually use?  Nothing in the Unity or PhysX documentation seems to help much here.  I use both position and velocity drives in the game, and I want them to be constrained only by the maximum force that the drive is set to use (in other words, fully “stiff” as if the spring or damping values were effectively infinite).

So I tried setting them to float.MaxValue, but this caused some odd behaviour.  Drives configured to be “velocity drives” would not work if the rigidbody’s mass was below some threshold, and those configured as “position drives” would sometimes cause Unity to crash completely without any warning.  In the end, after some experimentation, I simply used a smaller (but still very large) value for the spring / damping settings.  This seems to work alright, although I’m somewhat concerned it could still fail in some unforeseen situations!

Simulation update rate

As I mentioned in the last post, swapping joint rigidbody ordering (i.e. owner vs. connected) helped a lot to improve simulation stability at high angular velocities.  Unfortunately it was still not quite enough to get back to Unity 4 / PhysX 2.8 levels of stability.  The simulation update rate also needed to be increased a bit (by reducing Time.fixedDeltaTime), at the expense of performance.  So, as a compromise, I will be exposing a setting in the game to allow the sim update rate to be adjusted.  Advanced users can change it based on the construction that they’re building, and how fast their computer is.

Last few bugs

With these issues taken care of, there’s now nothing to prevent the upgrade to Unity 5.  I’m still working on migrating away from some deprecated APIs and fixing a few remaining (non physics related) bugs, once this is done I’ll be able to put out another demo release.

Unity 5 physics update (again)

Posted on

Over the past few weeks I have been working on resolving the physics issues that are preventing me from upgrading to Unity 5.  For those that don’t know, Unity 4 uses PhysX 2.8, whereas Unity 5 uses PhysX 3.3, the new version being a major re-architecture of the PhysX implementation as I understand it.  The resulting differences in physics behaviour have caused me a fair few problems.

A while back I outlined these problems, but I’ll run through the remaining ones again here, along with the current state of play for each of them.

Collision contact tolerance
The collision contact tolerance is important to set up so that adjacent parts in a construction have enough leeway to slide past each other without jamming up, while also not allowing parts to sink too far into each other.  In order to replicate the same contact behaviour in Unity 5 as in Unity 4, it turns out you have to set the collider’s contactOffset to the same value you had Physics.minPenetrationForPenalty set to in Unity 4, and then also shrink the colliders by this same amount in all directions.  This shrinking was a bit annoying to have to do, as I use the collider dimensions for other stuff, but at least it seems to have done the trick.

Instability at high angular velocities
Physics engines, given that they integrate at discrete time intervals (rather than being continuous like IRL physics), often struggle with objects with high velocities, the only way around this really is to update the simulation more often with a smaller time step.  So in order to allow for rapidly spinning parts like gears, axles, etc. in GearBlocks I have to use a small time step (Time.fixedDeltaTime), otherwise things would become unstable and start wobbling all over the place.  However in Unity 5, I had to set it to be even smaller in order to get the same level of stability, unfortunately offsetting much of the physics performance gains over Unity 4!

Each joint connects two rigidbodies, one being the owner of the joint, the other the connected rigidbody.  One thing I discovered that helps with stability is to set up the owner / connected relationship in a particular order.  The PhysX documentation recommends having the rigidbody with the higher mass of the pair be the owner.  I found that it was even more effective to have low velocity parts (e.g. blocks, motors, etc.) be the owner, and those with high angular velocities (e.g. axles) be the connected.  Setting joints up in this way meant I could get stable behaviour in Unity 5 without having to reduce Time.fixedDeltaTime by quite so much.  Unity 5 / PhysX 3.3 seems super sensitive to this ordering, whereas Unity 4 / PhysX 2.8 doesn’t seem to care.  It’s tricky to set up though because I don’t know ahead of time which parts of a construction are going to be the fast spinning ones (and I can’t change the ordering once the construction is unfrozen and moving without causing other problems which I won’t get into here).  So right now I’m working on something that’ll use an educated guess and hopefully get it right in most cases.

Unstable collision behaviour
In Unity 5, for some constructions when contacting flat ground, their collision response with the ground isn’t very stable and they can keep bouncing around for ages after the initial collision.  What’s more, this gets worse the smaller the simulation time step.  Setting up the joint rigidbody ordering as I discussed above seems to reduce this instability though.  Also setting the rigidbody’s maxDepenetrationVelocity to a smallish value helps too.

Joint drives (used for motors)
I was finding that the same force numbers for joint drives were giving different results between Unity 4 and 5.  I discovered that in Unity 4 the JointDrive’s maximumForce value should be multiplied by Time.fixedDeltaTime (which is what I was doing), whereas in Unity 5 it should not.  In other words, Unity 4 expects an impulse value, but Unity 5 wants a force value!

Configurable joint velocity drives
Once I grasped the differences in the way the settings behave, I was able to get these working, sort of.  I found that they still don’t work if the rigidbody’s mass is below some threshold, and there also seems to be a dependency on Time.fixedDeltaTime.  Not really sure what’s going on here, I need to do some more investigation on this one.

Getting there, but more to do

Well, if anyone out there is still in the process of upgrading to Unity 5, I hope my findings might be useful to you!  I’m hopeful I can resolve all this stuff soon, after which I still have to migrate away from some deprecated APIs, and work around a bunch of other bugs and issues I’m having in Unity 5.  Anyway, I can’t wait to put this upgrade to bed so I can get back to actually making the game!

Playable build – updated

Posted on

Playable build – updated

Another physics problem

A few weeks ago I noticed an odd physics bug in the game, where if part of a construction was rapidly rotating around one particular axis, that rotation would be massively slowed if the construction as a whole was also rotating about another, perpendicular axis.  For example, a rapidly spinning axle (acting as a drive-shaft) running longitudinally in a car would be almost completely stopped if the car yawed or pitched (say when steering or coming off a jump).

There is a gyroscopic effect that applies to a rapidly spinning object, where if you try and rotate it about a second axis perpendicular to its spin axis, it will want to rotate about about a third axis perpendicular to both.  Similarly, if you prevent it rotating about one perpendicular axis, it will resist rotation about the other.  This happens in game physics, just as it does in the real world (it’s what keeps bicycles up!)  In Unity’s physics (PhysX 2.83) when this resistance to rotation is counteracted by the hinge constraints holding the object’s rigidbody in place, it’s as if a large torque gets applied that dramatically reduces the rigidbody’s angular velocity about its spin axis.  I’m no expert on the physics of gyros, it’s possible that this is a real world effect that is just exaggerated in PhysX – but regardless it didn’t feel correct to me and could completely screw up a construction’s behaviour in the game.

I did some tests using other physics engines – a later version of PhysX (3.3) and Bullet.  I reproduced the same issue in both, so I’m assuming it’s a common behaviour among most, if not all, physics engines, and that porting over to a different one isn’t going to help me.

Hack and slash

I tried hacking around the problem by overriding the mass and inertia tensor of a rapidly spinning rigidbody, but to no avail.  I tried adding an “artificial” torque to counteract the slowing down effect on the spinning rigidbody, but that just caused stability issues with the hinge constraints.  It was as if all the forces were fighting each other, and something had to give!

I considered implementing a custom pseudo-physical solution specifically for drive-trains (i.e. motors, axles and gears), but this would have been a huge amount of work, it would have been very difficult to integrate nicely with the PhysX physics, and would have almost certainly limited the behaviour and physical realism of the constructions.

At this point I was really stuck.  I contemplated ignoring the issue and simply living with it, but that just wasn’t acceptable to me.  Another option would have been to completely remove all rapidly spinning stuff (like gears and axles) from the game, but after all the work I’ve done so far, I really didn’t want to do this.  Besides, it would have hugely reduced the scope of what could be built in the game, and taken away from what I think will make it unique compared to other building / sandbox type games.

An error / performance trade-off

Fortunately I found a way out.  I discovered that reducing the physics fixed update time-step minimised the problem to an acceptable level (albeit not eliminating it altogether).  I believe the issue is due to mathematical error that occurs with a combination of very rapidly spinning rigidbodies and a fairly large time interval between physics updates.  I can’t really lower the cap on how fast stuff can spin (not without placing undue limits on the constructions that can be built), so my only option was to update the physics more frequently with a smaller time-step.  Of course this comes with a significant performance cost, but it looks like it’s a trade-off I’ll have to make.

So when you play the game now you may notice a performance slowdown (depending on the complexity of your constructions, and your computer spec).  Next up, I plan to remove as much code as possible from my fixed update callbacks (these get executed at the same rate as the physics update), to try and mitigate this as much as I can!

Playable build – new gear physics

Posted on

Playable build – new gear physics

Well, after many weeks of trial and error, experimentation and frustration, I think I finally have a solution for the gear physics!  To recap, the problem with my old implementation was that it was only considering relative angular motion between the gears, and not linear motion as well.  This made the gears behave incorrectly if they had any relative linear velocity.

Need for a new solution

My old gear physics implementation was inspired by the one in Box2D, so I looked there again for ideas.  It turns out they work around this problem by also taking into account the angular velocity of the rigidbodies that the gears are attached to.  I played around with this idea for a while but I found it didn’t really extend well to my more general 3D case.

There were also other things to consider, like supporting other types of gear such as rack and pinion.  Also, the fact that my gear physics was only updated once per FixedUpdate (and not as part of the main PhysX solver update) caused lag, or “wind-up” between the gears under high torque loads.  A compromise I was living with, but was never really happy about.

Using configurable joints

So I decided to throw out my old approach and instead make use of the built in PhysX constraints (or “joints”), as exposed by Unity’s ConfigurableJoint.  The idea was to position the joint anchors at the current contact point between the two gears (right at the edge of the gears where they touch), and then lock the motion only along the tangent at that contact point.  Then every FixedUpdate, the joint anchors are re-positioned to the current contact point (as the gears will have moved slightly).  By carefully positioning the anchors like this, the gear ratio (relative torque transfer), and the relative angular and linear motion are all taken into account automatically.  This approach also makes it relatively easy to add support for rack and pinion gears.  And…by using built-in joints, the gear constraints are solved along with everything else, so there is minimal wind-up.

Sounds good in principle, right?  However the re-positioning of the joint anchors is where things get tricky.  If every fixed update, they are simply re-positioned exactly to the new contact point, the gears will gradually slip when under load.  This is because a joint doesn’t perfectly rigidly lock its anchors together, and there will usually be a small difference in position between them, even after the physics solve.  This error gets fed back into the new joint anchor positions and the error accumulates over time.

Correcting the joint anchors

So I tried correcting for this error by figuring out what the anchor position delta was vs. what it should have been.  This is not easy because there is not really an absolute angle for a rigidbody, only an absolute position.  The orientation angles of a rigidbody wrap every 360 degrees of rotation, so you’ve no idea how many of these rotations have happened since the last update.  You end up having to integrate velocity over time and accumulate the positional delta as found at the contact point between the two gears.  There are two problems with this.  First, I found that when comparing the contact point velocities between the two gears as reported by Rigidbody.GetPointVelocity, they seemed slightly off if the gears were moving linearly relative to one another.  Close, but not spot on.  This small error was compounded by the second problem, which is that by accumulating the contact position delta over time, any errors also accumulate – quickly.  It creates a feedback loop, the error feeds into the joint anchors, which causes the joint to pull the rigidbodies around too much, causing more positional error, which feeds into the new anchor positions in the next update, and so on.  This leads to unstable physics behaviour – high impulses, oscillations, and your machines exploding like crazy.

At this point I got pretty desperate, thinking I might have to abandon gears altogether, maybe even the whole game.  I even tried mocking up a solution using physics colliders (one BoxCollider for each gear tooth!), and using the collisions between the teeth to provide the gear behaviour.  Er yeah – that didn’t work unsurprisingly.

Predefined anchor positions

Then I came up with the idea for the solution I have now.  Re-positioning the joint anchors exactly to the gear’s contact point leads to accumulated error and gear slip.  So instead, each gear is given predefined positions at equal intervals around its circumference, and every update the one closest to the current contact point is found, and that’s the position used for the joint anchor.  As long as the distance between these predefined positions is greater than the distance between the joint anchors after the physics solve, you get no gear slip.

However, there is a problem with this if the gears are different sizes, as shown above.  The next / previous predefined anchor positions as measured along the contact tangent don’t quite line up due to the differing radii.  I tried correcting for this with a fun bit of trig, the maths worked out beautifully, but in practice it led me right back to another feedback loop, the joint and its corrected anchor positions ended up fighting each other, causing oscillations, exploding machines and much cursing.  In the end I just went with a simpler approach of just upping the number of predefined anchor positions, so that any differences along the contact tangent were minimised.  However, this of course means the distance between each predefined position is smaller, so increasing the chance of gears slipping under load.  In practice it’s actually not too bad though, it takes quite a high torque load to cause slip (to the point where axle hinge joints are also being noticeably pulled apart).

Next steps

This whole endeavour has been very frustrating, as the ideas I tried often worked fine most of the time, only to fail in particular use cases (certain combinations of bevel gears seemed to be particularly sensitive).  I spent a lot of time switching back and forth between my various approaches, trying different modifications, until homing in on what I have now.  It was so time consuming as I had to do lots of testing every time I made a change to check that I hadn’t broken one of my many test cases.

Well, hopefully the implementation I ended up with will see me through.  I’ve tested a lot of situations (complex gear trains, high torque loads, high rpm, etc.) but the open ended nature of this game means I might have missed a case where things go bad, let’s hope not.  Next up I’m going to work on implementing rack and pinion gears, and probably worm gears too, I wanna really be sure these will actually work with no problems, before going ahead with any other part of the game.