Unity3d v4 released! Also a tip from the release notes

Unity3d version 4 was officially released yesterday and it has a lot of nice enhancements.  Release notes are here and are well worth reading.  In fact, one thing that didn’t feel better was the new Project Browser which is nice on a desktop with a large screen, but not so great on the 13″ MacBook Air where screen space is at a premium.  Luckily they’ve left a way to get the old single column UI back for that situation, as I found in the release notes:

You can switch Project Browser to old-style one column layout in the context menu of the window (upper right corner).

The release notes above also contain an “Upgrade Guide” that’s a must-read for anyone upgrading a 3.5.x project to 4.0 as there are a few differences that need to be accommodated.

One thing to note: If you got Unity3d v3.5 with the free Unity3d v3.5.x iOS module license when Unity3d so graciously offered that great deal, upgrading to 4.0 removes your ability to build for iOS without buying the Unity3d 4.0 iOS module upgrade.  Since you cannot open a project upgraded to 4.0 in 3.5.x, once you’ve installed 4.0 and upgraded your project you can’t build for an iOS device any more until you pay to upgrade to the Unity3d v4.0 iOS module.   As I noted in the last post, supposedly you can install 3.5.6 and 4.0 side-by-side by renaming the folder of the first install before installing the second, but I haven’t tried this yet because we’re just going to upgrade the iOS module to 4.0 instead.

Unity3d 4.0 beta first reactions

Downloaded and installed the Unity3d v4.0 beta this last week and thought I’d write up a few notes based on what I’ve tried so far.

I haven’t used many of the new features yet (I haven’t purchased an official upgrade and so lack the iOS support I need to actually switch in earnest), but it seems to be quite solid (no new crashes so far), though it doesn’t fix the issue I’ve run into on my MacBook Air (HD3000 graphics) where Unity 3.5.x will hang or crash. Same thing happens with v4.0 beta, unfortunately.  😦

My first suggestion is: if you want to keep 3.5.6 you need to rename your 3.5.x install before you install the 4.0 beta because otherwise the beta will erase and install over your 3.5.x install of Unity.  Remembering just after you hit the install button and hurriedly switching to the Finder and renaming it isn’t good enough – the installer must save the FSRef or something because it’ll overwrite it in the non-default name in this scenario (whoops!).

@aras_p helpfully tweeted to confirm that renaming the Unity folder first should work, but I’ve not had a chance to test this yet.

The UI changes mostly seem like nice improvements, though the change to the Project View make it take up more screen space and on a 13″ MBA that’s unfortunate.  I’m not totally sure I see the motivation for the change and it feels weird to me as an OS X user – maybe it’s modeled on some Windows UI convention?  The decrease in screen space efficiency is definitely less than ideal for small laptop use in any case.

I was pretty excited to see the Terrain Engine getting some improvements.  In particular the mechanism to use your own shaders more easily was something I really needed/wanted.  Unfortunately it’s undocumented in beta 5 and while I figured out some of how it works and how to use it, enough of it remains a mystery that I’ve not yet figured out a solution that would allow me to use the Unity built in Terrain Engine instead of creating my own.  The biggest hurdle is that I’m not seeing how to get the base image to stop being drawn or to let me render a base image that matches what my firstpass shaders is drawing.

Our game didn’t take much in the way of modifications to work with 4.0 which was a relief.  The only change I really had to make was the change in GameObject.active and the way that game object activation works (all ancestors must be active for a child marked active to be actually activated).  We are using activation & deactivation of various versions of character meshes for LOD purposes and for switching to batchable static meshes when there isn’t animation for performance.  So this change to the way active state works was something we had to work around.  From the Unity3d 4 beta release notes:

We have changed how the active state of GameObjects is handled. GameObjects active state will now affect child GameObjects, so setting a GameObject to inactive will now turn the entire sub-hierarchy inactive. This may change the behavior of your projects. GameObject.active and GameObject.SetActiveRecursively() have been deprecated. Instead, you should now use the GameObject.activeSelf and GameObject.activeInHierarchy getters and the GameObject.SetActive() method.

Less than an hour to fix and no other problems with the upgrade – nice job Unity devs!

Now if I could just get that HD3000 bug fixed and more documentation on the Terrain Engine so I can turn off the basemap drawing I’d be one happy camper!

Compute Shaders look interesting, but the documentation implies that they’ll only work on Windows computers (despite mentioning OpenCL which we have on the OS X).  So I’m confused if they work on OS X or not.  With 4 core GPUs on the iPad 4 it would be interesting to have these work on mobile devices where appropriate also (or perhaps it’s never appropriate?).

Multiple new items in the menus relating to Animation so that’s something I need to look into, though I don’t expect it to be useful for our current game.

So, what’s got you excited about Unity3d version 4?

Unity JavaScript/UnityScript method lookup Bug or design flaw

Just wasted 2 hours chasing some code that wasn’t doing what I told it to (bad code!) only to find that I’d made a mistake (of course) and the compiler hadn’t told me about it (bad compiler!).

I don’t know if the root cause is that JavaScript/UnityScript method lookup rules are completely broken and don’t make any sense compared to any real object oriented language or if this is a bug, but I thought I’d document what is an easy mistake to make and encourage people deciding between JavaScript/UnityScript and C# for their Unity development to choose C# to avoid this kind of garbage.

Here’s the situation:  you are in a script and want to get a child node of the current object.  So you mistakenly type  gameObject.Find("MyMeshName");  and the compiler is fine with this and no errors or warnings are emitted but things aren’t working the way you thought they should…

That’s because there is no Find(…) Instance Method IN GameObject or its superclass Object.  Nice of the compiler to tell you that, eh?  Oh, right, IT DIDN’T!!!  Instead it decided to do the helpful (not!) thing and call the GameObject Find(…) class method.  DOH!  This class method, unfortunately, does a Global Search and returns you the first “MyMeshName” found anywhere in your entire game.  My how completely opposite of what you wanted.  <sigh>

What you meant to type was transform.Find("MyMeshName") and then get the gameObject from the returned transform and you would have gotten what you wanted – the game object associated with the mesh “MyMeshName”.

Or GameObject should have a way to search inside it’s children without having to get the transform and search and then ask the result for it’s game object.  Seems like searching/traversing the game object hierarchy is about as basic a thing as one would want to do in a game engine, but apparently I’m confused or something…

—-

Just did a test and the C# compiler correctly tells me that there is no Instance method Find(<string>):

 

Assets/TestMethodLookup.cs(9,44): error CS0176: Static member `UnityEngine.GameObject.Find(string)’ cannot be accessed with an instance reference, qualify it with a type name instead

 

So this is seems to be either a JavaScript “feature” that is one more nail in the JavaScript coffin or a bug in the JavaScript/UnityScript in Unity 3d.

(Reported to Unity as Case ID: 492421)

Unity3d GUI.Label and GUISkin bug (in Unity 3.5.3)

Use a Custom Styles style in a Unity3d GUISkin for GUI.Labels to work around a bug in Unity3d with the default “Label” style.

Just ran into this apparent bug (which I reported to them) in Unity 3d v3.5.3f3 which I thought I’d document. Work-around included:

If you create a GUISkin and customize styles to use 24 point font GUI.Box and GUI.Button work as expected but GUI.Label does not pick up the font size set in the GUISkin.

The work-around is to use a Custom Styles gui skin style, in this case “myLabel” and then specify that to the third parameter to GUI.Label:

if ( GUI.Label( r, "hello", "myLabel" ) ) { ... }

will work and pick up your font size properly.

onward!

(A sample project demonstrating the bug & work-around is available here).

UPDATE: So, I ended up tracking this down and found that it’s the “Word Wrap” checkbox that causes the font size to be ignored.  You can use the default Label style as long as you uncheck the “Word Wrap” checkbox.  Clarified the bug with Unity so hopefully they’ll fix it sooner than later since Word Wrap is rather useful…

UPDATE 2: Turns out iOS doesn’t support dynamic fonts so to actually get the larger sized fonts there you have to import a font and set your GUISkin to use that.   Readable GUI elements on iPad 3 – yay!

Unity3d debugging trick

So Geek was just trying to track down a bug with calculating collisions between units in our game.  In order to track down the points he was calculating as part of the collision detection during move he used Gizmos in Unity3d speak.  This is a very handy feature.

So at the start of the script file he created a couple of variables:

public var gizmoPoints : Array;

function OnDrawGizmos()
{
  Gizmos.color = Color.red;
  for (var point : Vector3 in gizmoPoints)
  {
    Gizmos.DrawSphere(point, 0.21);
  }
}

Then in the in the method where he does the move path checking via Rigidbody.SweepTestAll there’s code like this:

...
gizmoPoints.Clear();
for (hit in hits)
{
  gizmoPoints.Add( hit.point );
  ...
}

So the idea is that for each point he found in from the sweep test gets added to the array and then if he has Gizmos turned on in the Unity3d Scene view he can see what points the sweep picked up on.  Geek also had it draw the point his algorithm had picked as the best point in a different color so he could see where in the swarm of possible points his algorithm was picking the best point.  Once he could visualize what was happening this way he found and fixed the bug in less than 10 seconds.   Very useful trick to help visualize what’s going on.  I’d used Gizmos once to actually draw the ray of a raycast as a debugging tool previously so this is now the second time this technique has proven useful.  Recommended.