This update resolves an issue with the way I was snapping parts to each other that occasionally caused them to snap together with the wrong orientation. To do this I had to change the save game format though, so unfortunately any existing save-games won’t work!
Tag: game dev
Here I’m showing how to use the new differential gear in the game.
(Source: https://www.youtube.com/)
Another dev diary demoing the new hi / lo variations of the bevel and crown gears.
(Source: https://www.youtube.com/)
Playable build – updated
Now in the game, some bug fixes and a bunch of new gears!
Hi / lo gears
There are now two versions of every bevel and crown gear, a “hi” and a “lo” version. The only difference between these two versions is where the gear is positioned along its central collar (i.e. either offset high or low along it). This effectively allows for half-unit increments for where a gear can be attached to an axle, as can be seen in these examples.
This gives a lot more flexibility for how various combinations of gears can be used with each other. The high / low naming is a bit confusing I know but I couldn’t think of a better naming scheme, I might change it if I can come up with something better.
Differential gear
In order to allow the outside wheel to turn faster than the inside wheel during a turn, rather than have a solid driving axle, most vehicles use a differential gear to split torque between the driven wheels. I’ve now implemented this in the game, it works in exactly the same way as the differential in a real world vehicle. You have to build it up by attaching axles and the planetary gears to it, as can be seen below.
Just like all the other gears, it works in a fully physical manner, so its behaviour just naturally matches that of a real world open (i.e. non limited slip) diff. If one of the driving wheels isn’t contacting the ground it will spin up without the vehicle moving; both wheels have to be touching the ground for the vehicle to get proper drive.
Next up
As I mentioned a couple of weeks ago, I was thinking I’d have to overhaul the part pairing system to allow for certain kinds of part pairing relationships (e.g. axles and gears pairing with the differential at different attachment points). Well fortunately that turned out not to be really necessary, only some fairly minor changes were required.
However, the differential gear did show up a tricky bug with the way I’m snapping the orientation of parts to each other, so that’s what I’ll be looking at fixing next. I’m also gonna put together some videos soon to demo how to use these new gears.
Here’s a dev diary vid showing the results of my work over the last few months!
(Source: https://www.youtube.com/)
Playable build – updated
Fixed update optimisations
Now that I’ve had to reduce the physics update time-step, any code in my fixed update functions is much more performance critical. So this week I tried optimising as much of it as I could. Unfortunately there weren’t really any places I could move update code out of the fixed update altogether, but I did manage to speed up a few things.
I’ll probably have to revisit fixed update performance at some point, but for now I’m gonna move onto the next thing. Next up I think I’ll look at reworking the system that determines how parts can attach together, to make it more flexible and allow for more interesting part pairing relationships. This’ll be required for some of the new parts I want to add in the future.
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!
Collision bug update 2 – fixed!
A while back I encountered a bug in Unity where adding parts (that had a mesh collider) in a particular order to a construction would cause physics collisions between some parts to fail. This would break the construction mechanic from then on as I rely on getting collision callbacks to know when parts are positioned appropriately for attachment.
Well, as far as I can tell this has been fixed as of the latest Unity release! I didn’t get any update on the bug report I submitted, so perhaps it was fixed in relation to some other bug, either way it seems to be sorted now which is awesome. Here’s hoping I don’t find any other similar issues…
But…of course there’s always something else to worry about! I’ve recently noticed an odd behaviour where long, thin rigidbodies (such as axles) that have angular velocity around their long axis, tend to completely lose that angular velocity when rotated around other axes. It’s like a massive braking force is applied to their rotation. So I need to do some experimentation to figure out if there’s anything I can do to mitigate this (perhaps by fudging the inertia tensor or mass).
Playable build – updated
Dynamic gear engagement
The engagement between gears is now activated and deactivated dynamically. This means (as the various parts of a construction move around) gears will engage if they move close enough to each other, and disengage if they move apart. The test that checks if a pair of gears are engaged is fairly expensive, and obviously I now have to do these tests every update. So to avoid doing this between every pair of gears in a construction (i.e. O(N^2), not good), I use trigger volumes around each gear to find pairs of gears that are close to each other, and then do the engagement check only on these.
New steering wheel part
I’ve added a steering wheel part to the game that attaches to axles. It has a behaviour similar to the motor, where if “switched on” it will rotate in response to user input (i.e. the usual hold shift + directional controls).
Its obvious application is as a vehicle steering wheel, but more generally it can be used as a “control wheel” anywhere you want to rotate bits of your construction in response to user input.
Playable build – updated
New rack gear added
I’ve just added a rack gear to the game, useful for rack and pinion steering among many other things. Rack gears engage with spur gears that are positioned directly above them.
The implementation is still preliminary and still needs a bit of refactoring / cleanup, but it seems to work well so far, which is a relief. It looks like my gear physics solution is holding up!
There is one significant issue remaining with gears generally however, which applies to all gear types but is particularly highlighted by rack gears. Whenever a construction is modified (by adding or removing a part), a search is performed to find pairs of gears that are next to one another and should be considered engaged, and then a physics constraint is set up between each pair. However this is done only once, after the construction is unfrozen and things start moving about, the gear engagement pairings are not updated. Obviously this becomes a problem if the gears move apart from one another, it also won’t engage gears that start off apart, but then move together.
So I think my next big task will be to overhaul the gear engagement system so that it updates dynamically. It will need to be reliable, and not incur a big performance cost doing lots of spatial searches etc. could be tricky!