The projection image on the wall is the final result of camera input and the presenter slides which will get liveedited to a separate machine. They’re mixing everything in realtime using modul8 vj software.

We’ll also be color-keying in the conference visuals with our slides. Cool stuff – I just hope it doesn’t crash…

I’m giving a talk about the inner workings of immediate-mode GUIs at GDC Europe tomorrow (in Cologne). Looking forward to doing it – it’s been my main Unity development area for the past 2 years, so I guess I somehow ended up being an expert on that subject It’s Monday at 2:10 – 3:00 PM

If any of you are there, I hope you come – and if you want to meet up in Cologne, drop me a mail or a PM on our forum, and I’ll try to squeeze you in.

I was just going through some old folders sitting in a dusty corner on my hard drive, when I found a backup copy of images I posted to a Danish gamedev forum in the first years of Unity. Thought I should share these:

Unity 0.2 (or thereabouts)

This is Unity running in what I believe to be OS X 10.0 – it’s a game Joachim and I made together over a weekend when I visited him while he was still living with his parents. The funny thing is both seeing how much has changed, but also how little: we got ShaderLab in bottom left, Hierarchy view, Project (called Library back then) and the inspector top-right. What did we actually do during all those years? (and yes, that is python gamecode scripts you can see in the Library – this was before we switched to Mono)

I modelled the Apache – l33t gfx skillz, no?

Fast forward 1-2 years:

Here we have a weekend game we did in a somewhat later Unity. Don’t know why I put it here – I just always liked it, I guess.

Over & out \n

Upcoming 2.6 timeline WIP

I’m really excited about this. I’m thinking that it should be able to require a lot less scripting work for a bunch of stuff. It will also support material animation (so you can actually just make some curves for a UV scroll – instead of having to code the thing from scratch).

Transparency creates visual noise – our eyes are very good at edge detection, and having transparent stuff increases the number of edges that we have to process. Also, a lot of GUI has some sort of layering effect – either through shading, coloring or by using floating windows. Using transparency breaks this layering (in nature, very few things are partially transparent).

Who got the idea that having a large 50% transparent panel was a good idea? – you can neither see the panel nor the text beneath.Now, I said at the top that semitransparent GUI is ususaly not a good idea – let’s take a look at where it does work:

• Almost completely opaque – Aperture is probably the best example of this. Their panels are 95% opaque – so you hardly notice the transparency, they just pick up a tiny bit of color from the underlying pictures.
• Almost invisible – The iPhone has this neat trick where they add a soft darkening effect to the entire screen when a modal dialog pops up. You don’t notice the darkening bit, but it makes the modal dialogue stand out.

Sometimes as GUI designers, we can’t quite decide whether or not we want the user to see something – and so we are tempted to make them semitransparent. This is bad – we should make up our minds. Either something is there and can be manipulated or it is not. I got that wrong in Unity: When you have a move tool handle going into or away from the screen we want to disable it (dragging sends the object to infinity fast and it blocks the free move handle) – I was scared of confusing user with move handles popping in and out of existence, so I decided to “dull” them down to 50% transparency.This is NOT enough, so now I’m confusing users with handles that can sometimes be dragged and sometimes not.Great work, Nicholas. I’ll fix that later (and blag about it later still) – it’s back to coding for me.Happy Easter!

Unity has a very minimalist GUI; this stems from the basic premice that GUI you don’t interact with is an actual loss to your productivity – every GUI element that you do not use is one you look at many hundred times a day when working with Unity, and hence something you need to discard from using many hundred times a day. After a while you get pretty good at ignoring a piece of user interface, but when it adds up, you end up with a cluttered mess. Take a look at many 3D apps to see just how bad this can get.

On to what I actually wanted to talk about – the world space indicator arrows, and why they are not there.

At its heart, Unity is not a modelling app – it is an app where you bring together pieces of art from other apps. This means that usually telling which way is up is not a problem:

Geez, I wonder which way is up?

While this can be quite hard to see in a 3D-modelling app (where you might be constructing your mesh by connecting raw verts), by the time you put things into Unity, this is not so big a deal. 

What about when you’re just starting out? In this case, I can see we have an issue – I cannot tell how I’m looking at a box. However, adding an RGB axis thingy to show the directions to every scene view seemed to be way overkill; it would add on-screen clutter for the people who have huge, complex scenes to manage – in order to solve a slight confusion when you’re starting out a new scene. I thought we could use more subtlety;

In real life, we don’t have the problem of telling up from down. Apart from the fact that we can usually assume that our feet should be pointing downwards, there are other cues – mainly a horizon line and lighting.

Light tends to come from above. How about adding a soft top-down light to Unity’s default light setup? This could be a hint of a global up we might just pick up without thinking about it?

I’m also considering always having a very simple skybox in the sceneview – basically something that would tint the upper half of the background a bit lighter than the lower one.  

—-

There is, however, another solution; Sometimes, other people just make some excellent work: In one of the later Maya versions, they added the ability to click the indicator arrows to orient your viewport to a direction:

They even animated the viewport turning to make sure you didn’t get confused while changing views. I noticed that even experienced Maya users picked up this concept immediately – and apparently didn’t mind the animations. Now, those axis arrows are no longer mere decoration, they are actually used to perform a function we do very often – and giving them this functionality means we can remove the (seldomly used and much more cumbersome to use) direction drop-down. 

This is one of the things I plan to be playing with when I do my huge Scene View cleanup.