Hey everyone, apologies for the lack of GearBlocks updates recently.  I’ve been working on porting all of the menus and other UI over to the new UI system that was introduced in Unity 4.6.  I wanted to get the port out the way sooner rather than later, before I add any new features that require UI changes or additions.  Unfortunately it’s taken me much longer than expected, I’m getting there, but I probably still have one more week left to go on it.

Previously I was using the old immediate mode UI system, which has its well known limitations that I won’t go into here, I’m guessing it will eventually be phased out in future releases of Unity.  The new system is for sure a lot more powerful and flexible, and of course you get to properly lay out your UIs in a WYSIWYG fashion.

Issues with the new UI system

Unfortunately once I got into it, I found there were some downsides to moving to the new system.  For instance, some of the features of the immediate mode UI I was using (e.g. selection grids) do not come “built in” and I had to write additional code to replicate them.  Also, some bits of the UI that I populate at run-time (e.g. the parts list in the inventory screen) required significant rework to the code that does the populating (simply because of the totally different philosophies of the old vs. new UI system).  The most troubling issue though was the performance of the new UI system, I discovered if you’re not careful you can easily add many ms. to your frame time, with spikes in the hundreds of ms!

UI performance problems

GearBlocks has many separate UI screens that the user can transition between.  The “standard” way to implement this in the new UI system (at least from the tutorials I’ve seen) is to use an animation controller to blend each screen between an open and closed state, these states setting the screen’s CanvasGroup visibility and interactibility.  However I found that the animation blend added a couple of ms. (from Animator.Update and Canvas.BuildBatch) during a transition.  Even worse, despite all screens (apart from the currently active one) being invisible and non-interactible), they still all seemed to get processed and I found that this resulted in several ms. of overhead from the EventSystem update.

To get around the transition blend cost, I did away with animations for the in-game UI and just did the transitions directly from code (I kept using animations in the main menu though as the performance cost isn’t so critical there).  For the second problem, I wanted to eliminate any cost for a non-active screen – it’s not really practical to go through and disable each and every UI behaviour, so I tried deactivating the screen’s root GameObject.  Unfortunately, while this does eliminate the continuous frame-by-frame cost, it can result in huge performance spikes when activating / deactivating the GameObject (I found hundreds of ms. if you have a complex screen with ScrollRects), so it’s not a viable option.

Luckily I found another solution, which is to have a separate Canvas and GraphicRaycaster for each and every screen, then enable / disable these to transition between screens.  This way you get the best of both worlds, no cost for inactive screens, and no cost to activate / deactivate them.  I get the impression this is a common trick people use to get around this problem.  It seems like there are a few performance tricks people are discovering (such as disabling Canvas “pixel perfect” when using ScrollRects).

Well, hopefully I’ll be done with the UI port soon, and then I can get back to adding new stuff to the game!

For some time I’ve been trying to resolve the physics issues after upgrading GearBlocks to Unity 5.  I’ve had success with some issues, not so much with others.  I’ll sum up where I’ve gotten things to so far.

Rigidbody rotation unfreezing
When unfreezing a rigidbody, its rotations weren’t being unfrozen, this bug happens if you had already modified the rigidbody’s inertia tensor.  After submitting a bug report, I heard back from Unity – turns out the workaround is to restore the inertia tensor after unfreezing, which works fine.

Collision contact tolerance
The collision contact tolerance seems to have significantly changed with Unity 5.  What I thought was my gear constraints not working properly was actually due to the moving parts (blocks, axles and gears) within a construction colliding with each other, and everything was getting all jammed up.  One workaround I tried was to shrink the colliders, trouble is I had to shrink them by quite a large amount and even then I’d still get occasional unwanted collisions.  Another option would be to disable collisions altogether between neighbouring parts, but that’s problematic as you might actually want them to collide in certain situations.

Unstable collision behaviour
For some constructions when contacting the ground, their collision response with the ground is kinda jittery and they keep bouncing around for ages after the initial collision.  After some experimenting, it seems this behaviour is worse with the small fixed update (i.e. physics update) time step I’m using (5ms vs. the default 20ms).  Not much I can do about that though, as I need the smaller time step for accuracy with fast spinning stuff.

Instability at high angular velocities
On the subject of fast spinning stuff, despite the aforementioned small time step (and also a high solver iteration count), gears / axles spinning a high rpm now become unstable and start wobbling around.  With the same settings in Unity 4 this was rock solid.  I tried playing around with these settings but I couldn’t get it to be stable, more experimentation is required, but this could be a real show stopper.

Hinge joint motors
When switching on a joint motor, there is a bug in Unity 5 that means the connected rigidbodies don’t get woken up, and so they don’t start moving if stationary.  The workaround is to explicitly wake up the rigidbodies when turning the motor on.  I also found I had to multiply my torque values by a factor of around 50 to get similar behaviour to that in Unity 4.6.

Hinge joint limits
I use angular limits to force a hinge joint to a particular angle by setting the limit min and max values both to that angle, but this stopped working properly in Unity 5.  I found the fix was simply to ensure there is a small delta between the min and max.

Configurable joint velocity drives
I still can’t get these to work at all, I submitted a bug report to Unity but haven’t heard back so far.  Hopefully they’ll be able to fix this one.

In summary, I’ve got fixes / workarounds in hand for most issues now, but there are still a couple of show stoppers (namely velocity drives and stability at high angular velocities).  So for now I’m still sticking with Unity 4.6, I really need to get back to making actual progress on the game!

Over the last week I also had a look at some of the Unity 5 physics bugs I mentioned in an earlier post.

It turns out the rigidbody freezing bug only happens when I modify a rigidbody’s mass properties (i.e. mass, inertia tensor etc.)  I was quite easily able to repro this in a very simple project, so I’ll send this off to Unity when I get a chance.

After browsing the Unity forums I found out that hinge joint motors not working is caused by the motor not waking up the rigidbody.  As a temporary solution, if you force the rigidbody to wake up every update, the motor works.  I also found I had to multiply my torque values by a factor of around 50 to get similar behaviour to that in Unity 4.6.

Velocity drives definitely aren’t working for me.  Again, I was able to repro this in a very simple project.  One for another bug report.

I haven’t had a chance yet to look at the hinge joint limit and OnCollisionExit issues, but I’ll keep chipping away at these next week.  I also noticed that my gears don’t seem to be working properly, sometimes the gears (particularly rack gears) get stuck.  I checked and the configurable joints I’m using for the gear constraints do still seem to be updated correctly, so I’m not sure what’s changed here.  I always was concerned I’d find some slightly different behaviour in Unity 5 with PhysX 3.3 that would unavoidably break the delicately tuned physics setup in my game, and this may be evidence of that.  Let’s hope not, more investigation required!

This week I tried porting over to Unity 5.  It went pretty smoothly to start with, a few shader and code tweaks were required to get everything running properly, but nothing too bad.  However once I got things going I found some pretty fundamental physics bugs that totally break my game:-

• Once frozen, rigidbody rotations can’t be unfrozen (positions are fine).
• Joint motors, limits and velocity drives seem to be non-functional (at least when setting them from code).
• The OnCollisionExit callback never seems to be called.

It’s a pity really, as I can already tell the physics performance is significantly improved (which I sorely need!), but for now I’ll have to stick with Unity 4.6.  Hopefully Unity will resolve these issues fairly soon.

In the meantime I’ll have to re-jig my task plan a bit, but it shouldn’t hold things up too badly.