Everyday 3D

I started to work with WebGL a few months ago. WebGL (in case you never heard about it) is a new emerging standard for rendering GPU accelerated graphics in the browser, without any plugins. Not all browsers support it yet, but the latest Chrome and Firefox do and others are about to follow (Safari, Opera, sadly not IE for the moment).

Whatever happens, WebGL seems to be here for good and it is definitely worth learning or at least looking at. It is a pretty low level API unlike Flash Away3d, not to mention Unity. In this respect, it’s much closer to Molehill. This can be discouraging at first, but after I got into it a bit, I found out it’s actually pretty fun to play with.

WebGL is a Javascript API. I always had mixed feelings about Javascript, remembering it from the days of Netscape and the so-called DHTML. But it was 10 years ago, and when I tried it again now I had to change my opinion. It may not be as strict and carefully designed as C# but it is simple, very flexible and easy to share. In the web environment, that last point (often brought by mrdoob) is perhaps the most important.

Based on OpenGL ES, WebGL is a collection of functions to communicate with the graphics card. To those of you who are used to OOP patterns and frameworks, WebGL will come as a shock. It’s mostly plain functions that set some properties, toggle some states or push some data to the GPU. It’s like a giant switchboard with one big global space for all operations. Sounds like fun, eh?

Resources and WebGL demos appear almost everyday, so be sure look around the web for interesting stuff. There aren’t that many comprehensive tutorials yet, but you can try the lessons at Learning WebGL – it’s the best introduction to the subject I’ve seen so far.

What better way to learn a 3D API than to build an engine? I was contemplating writing my own engine in Flash/AS3 a few times before, but never though I had quite enough knowledge to do this. This time I felt much more confident. Also, WebGL gives a pretty good start that Flash didn’t back in the days.

That’s how J3D was born. J3D is a very simple engine that can load 3D models and textures, has a scene with a hierarchy of objects and can render everything using basic lights. Somewhere on the way I added the feature to export models from Unity3d which I thought would make the job of preparing assets much easier.

Although J3D is pretty small and has limited functionality, it works and building it allowed me to learn and understand WebGL pretty well. This was my primary objective.

Last week I uploaded all the code to github and shared the link on Twitter. People seemed to like it and showed quite some interest. This made me very happy and gave me the idea to continue with the project and see where it leads me.

To sum up: demo, another demo, source code on github and more coming soon!

For the past 5 moths I have been working with North Kingdom on an interactive installation called Woodbot Pilots. I’m happy to announce that it had been launched last week!

It’s located at the Skellefteå Airport in Northern Sweden. If you happen to be in the area, make sure to check it out. However, as I imagine, it isn’t a location easily accessible to most of my readers, so I will be posting more pictures & videos as they appear.

UPDATE 28.01.2011 Here’s a video made by guys over at Interactive Institute in Umeå. The also published an article that you can read here.

Together with North Kingdom we are also working on a small website dedicated to the project. It will go live soon. In the meantime there’s a nice article from the opening ceremony in the local newspaper, Norran, where you can see Mr. Robert Lindberg, the director of Skellefteå Airport doing the first run.

Woodbot Pilots is a gestures controlled racing game. We display it on a huge 82″ HD touch screen (191 x 123 cm!) and a special 3D depth camera is used to read the gestures. The camera was developed by a company called Fotonic and is somehow similar to MS Kinect but has a bigger range (up to 7m) and is optimized for industrial environments.

The talented artists from Ars Thanea and North Kingdom created beautiful visuals and the sound engineers from Dinamhoe added a great soundtrack. The game itself was developed in the Unity3D engine. We connected the 3D camera using a C/C++ plugin developed by programmers over at Interactive Institute in Umeå who did a fantastic job – it runs very smoothly.

The game logic is implemented in C# – quite some code in there, even though the game concept is relatively simple. Thanks to a powerful graphic card (XFX Radeon HD 5870 1GB GDDR5) the thing runs at 60 FPS in full HD resolution which is quite amazing!

I will talk about the technical details in a future article. For the moment enjoy some pictures of the race track, and Happy Christmas everyone!

Also, make sure to check out this article on North Kingdom’s website – there are a lot of pictures of the installation itself.

This is just a quick post to let you know that I will be doing more Unity3D training sessions in London – on Nov 15th-16th and Nov 17th-18th 2010. There is still a couple of places left for both, so if you want to learn some cool 3D stuff, you can book it here, but hurry up – the last session was sold out.

On the post about the October session, I got a comment that my photo was not really related to the training, which was right – it’s just that I like this building. This time I used a screenshot from a game we are making during the session. Below, I post some more.

Did you know that C# has a built-in event system? And a very good one! It can be quite useful with Unity3D. Here's an example.

In order to respond to events dispatched by a GameObject you typically would create a script that extends MonoBehaviour and implement the methods you need. So if you want to react to the user hovering the object with the mouse you would create the OnMouseOver method. It would typically look something like this:

That works fine. But what if you want another object to be notified about that event? One way would be to keep a reference to that other object in your script and call it from within your method:

This also works fine, but you always need to keep a reference to the object you notify. Also, you can only notify this object, unless you keep more references to other object. This can quickly get messy.

Messages

Another solution would be to use SendMessage or SendMessageUpwards methods. While they seem to be the right tool for the job, these methods have several major flaws, and in my opinion you should completely avoid using them.

Their syntax is awkward to start with, and you need to pass method names as string literals - which is very error prone! Also, those methods work only within the object's transform hierarchy. You can invoke methods on scripts that are either attached to the same GameObject or to one of it ancestors.

Events

Fortunately there is a better way to solve this problem, and this is with the C# built in event system. I can't explain how the event system works in detail, but if you are interested on learning more on this topic, go and check the tutorial on MSDN.

Now, let's see how to use events in Unity3D. Consider this script:

Don't worry if you don't know exactly what it does. What's important is that once you attach it to a GameObject you can go to another script (any script in your project!) and if you have a reference to that object you can write something like this:

This approach is more flexible than using messages, because it works with any script not only with those that are in the same transform hierarchy. If you keep a Singleton object that manages the state of the application, you could listen to events coming from any GameObject in it. Of course not only a GameObject can send events - any object can.

One of the consequences of such setup is that the same listening function can be used to respond to events coming from different objects. By passing a reference as argument you always know which object dispatched the event - this is what I do in the example.

References, controllers and MVC

In the first scenario above you needed to keep a reference to the listener in the object that sends the event, and I said it's not a good idea. In the version which uses the built-in events, it needs to be the other way around - you need a reference to the object that sends the event in the object that listens to it. How is it better, you might ask?

First of all, here, the sender doesn't know who is listening to the events is sends - and even how many listeners there are. All it does is to send the event and forget. In the first scenario above, imagine how cumbersome it would be to tell the sender to stop notifying the listener!

With the event system, it's the listener that has the responsibility to decide what events it listens to, when to start, and when to stop listening to them. Such object usually manages the state of the application or executes some game logic. To borrow the term from the MVC design pattern - it's the controller. That is why it's perfectly logical to give him such responsibility. In that way, using events creates more solid code.

Finally, I love the overloaded += operator used to add a listener, it's so clean! As you might have guessed by now, when you are done listening to the event you can just say:

Of course you can create a generic EventDispatcher class that implements all events that a GameObject can send - here's a version that implements a few of them already. By looking at the code, I'm sure you can figure out how to add others. However, beware of implementing OnGUI that way! (if you want to know why, read this post).

I'm proud to announce, that I will be running a 2 day training in London later this month. I will be teaching Unity3D, showing how to use the editor and how to work with various assets. I will be also giving an introduction to scripting in C# and hopefully we will be able to cover some features of the latest release of the editor.

Unity3D version 3 has been released only a few days ago. The new version is packed a tremendous amount of new and cool features. Great games & other projects are created with Unity3D every day, so there has never been a better moment to start learning it!

You can read all the details about the training on the LFPUG page, who is also the organizer of the session. Unfortunately, the tickets have been sold out. However, if you would like to learn some Unity3D, please contact me (bartek [at] everyday3d.com) or Tink (training [at] lfpug.com). We are pretty excited about the interest people are showing for this topic, so currently we are planning to run another session in London in November and there are still a few places left on the list.

I got a couple of requests to run such a training in other places, so hopefully I will be bringing some Unity3D goodness to other cities in Europe as well. I'm working out the details, and I'll keep you posted. If you would be interested in hosting a Unity3D training session in your city, please let me know!

Plasma

Rings

Canyon

Flower

The endless well

What are these?

While at FITC San Francisco I attended the session of Iñigo Quilez who is a demoscene veteran, currently working at Pixar. He showed us lots of interesting stuff he created with GLSL. He also showed examples of some more basic stuff like those above. These are very old school effects known to the demoscene artists since the dawn of civilization (that is the '90s). On Iñigo's site you can find a simple tutorial on how to create those effects, and it's not very difficult to port it to Unity3D using Cg. The cool thing is that all this different effects run on the same exact code, changing just a few settings.

Update Sept 17th 2010 Inigo also created a tool called ShaderToy, which allows you to play with the formulas in your browser (it must support WebGL).

As for the plasma effect, I initially saw it on mrdoob's blog and found this short tutorial which explains how to do it. Simple, and it looks nice!

TIP: Although they run pretty smoothly in the browser, the demos perform even smoother in fullscreen mode.

UPDATE It seems that the shaders do not work on OSX 10.6 (Snow Leopard) in Safari 5 and Chrome, but do work on Firefox. Some shaders might not work on certain GPUs, but in this case it's the same system, with the same graphic card and the only difference is the browser. This means that there might be a bug in the web player. If I have more news, I'll post an update, but you also can follow the discussion on the forum here.

In the meantime, if on OSX 10.6 please use Firefox (sorry).