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.

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).

When we first talked about the project, the idea was to use either Flash or Processing, but I though that it's a good occasion to try Unity3D (of course... :) To achieve the desired visual effect I needed a shader system that's fast, flexible that and works with 3D. Unity's ShaderLab seemed like a good option.

The material on the shape is transparent and is composed of a blurred version of an image applied as regular texture and the image itself applied as reflection. The images change over time, and are animated by scrolling UVs.

All the data for the installation is loaded dynamically, the application itself is just composed of some scripts that make it run, so the file is only 55KB! It's controlled by an external configuration file that allows to define the source images and sounds. There are also quite a few other settings to tweak they way it works, ex. how transparent or how reflective the material should be.

One particular challenge was to make the shape react to the sound. To make this happen I needed to read the spectrum and Unity3D doesn't offer access to sound data on the code level. One possible solution was to write a plugin that does that, the downside however is that it wouldn't run in the web player.

I solved the problem by pre-processing the sound in a small Flash app. It dumps the spectrum data to a text file which is then loaded to Unity3D. When the application plays the sound file, it uses this data to check the values of the spectrum at any position in time. Simple, but does the job.

The installation is part of a project called Tango and Hawaii created by Anrick and Luciano. Be sure to check the live demo. It was originally presented at the Magdalena Festival in Maribor, Slovenia.

It was a new experience for me to work on an art piece was. It was very inspiring to see what Anrick and Luciano did with a tool I helped them to create. Thank you guys!

I'm happy to announce that I will be speaking at FITC San Francisco in August. I have been speaking at FITC events twice this year, and both times it was a fantastic experience. I'm looking forward for this one, and what really thrills me about it, is the amazing speaker lineup!

There are of course all the usual suspects like Joa, Ralph, Andre, Mario and Seb plus many more great speakers form the community - you don't want to miss any of them. Here's a few that particularly caught my attention:

Eugene Zatepyakin The Actionscript/Alchemy mage from Russia. You may know Eugene from his work on ASSURF which is this amazing image recognition library. I had the pleasure to meet Eugene in Antwerp last year and I can assure you that you won't regret attending his presentation.

Theo Watson At FITC Amsterdam 2009 Theo was speaking as a last minute replacement for another presenter who could not make it. It was a lucky coincidence for me, because I really loved what he was showing! Theo is a digital artist working with openFrameworks. In San Francisco he will be taking part in a panel together with Jer Thorp and Ben Fry, the creator of Processing. I'm sure it will be a very interesting discussion. Theo will also be giving a presentation on interactive storytelling toghether with Emily Gobeille.

Yoko Nakamura Yoko was doing kick-ass Flash stuff on Yugop while I was still learning how to use gotoAndPlay()! I can't wait to see the legend live.

And there's me. I feel almost insignificant in face of such great talents, but I will do my best to deliver a great presentation. I was speaking in Amsterdam and Toronto and I was happy to see a full house both times for which I only partly credit my amazing speaking talent... :) It's rather that Unity3D is such a hot topic right now. In San Francisco I will be giving a new, updated presentation entitled "What can you do with Unity3d?". I hope to see you there!

But wait, there's more... so take a look at the complete speakers list. If you live in California (or close to) this is an event not to miss. The super early bird tickets are only available until today (Friday, May 28th) so go grab them before it's too late!

This post is an addition to the last series I wrote about dynamic content loading in Unity3D.

When building a dynamic application, every now and then you might need to load some 3d models at runtime. Either because there's a database with models you want to use or just because you want someone to update the models without rebuilding the project. I actually had this situation a few weeks ago. Surprisingly, this option does not come with Unity out of the box.

Asset bundles and resource folders

But first thing first. I said there's no ready-to-use way to load 3d models at runtime, but it's not 100% true. In fact, there are two options: asset bundles and resource folders. These methods are discussed in depth here.

They can both be useful in some cases, but they both have one fundamental drawback: in order to create them, someone needs to open the project in Unity, import the 3d models, create the bundles or resource folders and then export the whole thing again. To create an AssetBundle you need to run a script in the editor, while the Resource Folders... honestly, I failed to even make them work!

In brief, it's all too complicated for what I was looking for.

A straightforward solution

What I needed and wanted was easy and simple: to load a 3d object (geometry + some materials and textures) at runtime, using just a URL as parameter. The only solution seemed to write my own importer.

Basically, I had the choice between Collada and Wavefornt OBJ. I would choose OBJ any time of the day because it's a simple, concise plain-text format, while Collada is bloated and is XML-based.

It's not that I hate XML (although I'm not a big fan either) but in order to parse XML you need to include a pretty weighty DLL in your *.unity3d file, around 850Kb, which in this case (and in many others) defeats the purpose. Still, it's good to know that it possible, and there are situations when it's ok to use it. If you want to learn more about Unity3D and XML there's a awesome article on this topic by Paul Tondeur.

It turned out that while it's not rocket science to write an OBJ importer, it's not exactly banal either. I spent a few days coding it so I thought I'll share this with everyone - maybe someone will make good use of it.

Here's a package with the source code (v1.1) (or a version that works in Unity 3 (v 1.2)), along with a simple scene demonstrating how it works. In fact it couldn't be simpler. All you have to do is to create an instance of the OBJ class and start a coroutine to load the contents, like this:

Supported features

• Vertex, normals and UV data
• Multiple objects per file
• Vertex groups and multiple materials per object
• MTL files, diffuse and specular materials
• Basic textures

And it's all at a cost of ~12Kb extra added to your final file!

Testing and the universality of OBJ format

In the 3D world the OBJ format is nearly universal - I think that every 3D editor in existence is able to export to this format. This also means that Wavefront files come in many different flavors.

I tested the code against models created with Blender and against common sense assumptions on how an OBJ file can be constructed. If it doesn't work with files exported from your editor send me the OBJ file, and if possible I'll update the code. It's released under the MIT license so feel free to use it in your projects, commercial or not.

That's it! I hope you'll find it useful!

Unity3D can work with meshes created in external 3D editors, but geometry can also be created with code. And not only geometry, but materials and textures as well. To test all these options I created a simple cityscape. I got inspired by this set of awesome pictures and also by a project called Pixel City by Shamus Young.

Creating meshes

All information about the geometry of an object is stored in the Mesh object inside the MeshFilter component. A mesh is composed of an array of vertices grouped into triangles and with UV information added to it. It's a pretty common way to store information on 3d geometry, similar to what you can find in Actionscript - Graphics.drawTriangles expects arguments in the same data format. Many file formats out there store meshes that way too, ex. Wavefront OBJ (which makes writing importers/exporters relatively easy by the way).

Creating a mesh with code means populating the arrays of vertices, triangles and UVs. While it is pretty straightforward, even building a simple cube can be tricky and the code quickly becomes a unmanageable list of numbers. In the source code, the buildings are generated in the BuildingBuilder.cs file, so you can see it for yourselves.

Creating textures

We've already seen that any bitmap you import into a Unity3D project is represented by the class Texture2D. Of course, bitmaps don't have to be imported - they can be created from scratch. The constructor of the Texture2D class take a few arguments, including the width and height of the image.

Once a new texture is created all it's pixels are empty (i.e. black and transparent). Their values can be changed either on a pixel-per-pixel basis using the SetPixel method or by copying portions of other bitmaps using SetPixels.

In the above example I have 6 predefined textures with different types of windows, so I don't create those from scratch. However I use a procedural texture for the illumination maps. I generate a 64x64 bitmap where the value of each pixel determines the brightness of a single window (i.e. how much light it emits). It's pretty basic: after the Texture2D is created I just run through all it's pixels and assign a random value to it's alpha component.

Creating materials

There are 6 different textures representing a different type of window each and one illumination map. How to put these together? That's what materials are used for. As with any other element, materials are represented by the Material object in scripts, and they can be created with code. The constructor takes only one argument: a shader.

Shaders are one of the most crucial elements of Unity3D (and any other 3D rendering engine for that matter). They describe how a 3D geometry will be rendered, what colors and/or textures will be used and how it will interact with light. For the buildings I use a shader called Self-Illuminated Diffuse. It's one of Unity3D built-in shaders.

Shaders usually need some parameters to work with - like colors or textures. A material is essentially a shader and a number of objects that define it's parameters. Self-Illuminated shaders expect one texture for the color and the other that determines the amount of light emitted by this texture. It's great for creating objects that emit light like bulbs, neon signs or... windows in a night scenery (it's important to understand however that the object emits light but this light doesn't illuminate any other objects around it).

I use the window image as the color texture, and the procedural image with random alpha values as the illumination map texture. The trick is that I set the scale of the color texture to 64. This way the window is repeated 64x64 times on the material and each pixel of the procedural illumination map (scaled 1:1) corresponds to one single window. I also set the filtering mode of the illumination map texture to Point, so that it doesn't get blurred when seen form a bigger distance.

A word on optimization

The generated buildings have different width, height and depth. A natural solution to apply textures on all of them was to create a material that repeats the windows the appropriate amount of times for each building. Ex. a 4 story building with 3 windows in a row would have a material where the x-scale of the texture is set to 3 and y-scale to 4. The emission map scale needs to be divided by 64 in this case, giving values of 3/64 and 4/64 respectively.

While this seems quite ok, it poses an optimization problem. Unity3D is much more effective when there's a lower amount of meshes composed of large amount of vertices, rather that the other way around - lots of meshes with few vertices. One building has 20 vertices and I create 2500 separate meshes! It's far from optimal, and you can really feel the framerate going down because of that. Fortunately there is a built-in script called CombineChildren that automatically combines all the buildings into one huge mesh making everything work much faster and smoother. But (of course) there is a trick!

Unity3D will combine objects only if they share the same, exact material. The scale of a texture on a material is unique, so if there are two materials that are identical and the only difference is the scale of the texture, we still need 2 different materials. In the above scenario almost each building uses a different material, unless it has exactly the same number of stories and the same number of windows in a row. I had to come up with a way to use only one material, and to deal with texture coordinates in a different way.

The answer is to use UVs instead of the texture scaling. So I started by creating only one material, which contains 64x64 windows. If a building is ex. 20 stories high and has 6 windows in a row, this means that the wall of the building needs to be mapped to the texture with this coordinates [0, 0, 6/64, 20/64]. Remember that UV values are normalized, i.e have values between 0 and 1, 0 pointing to the left/top pixel of the texture, and 1 to the right/bottom.

This way I can reuse the same material on every building regardless of it's size. It works even on buildings that are higher that 64 stories, because UV values are repeated - ex. an UV value of 1.2 is the same as 0.2. Perfect!

One little problem still persist though. Since each building uses the same material it also has the same pattern of lit and unlit windows. It doesn't look nice. Fortunately there was an easy solution for this: to offset the UVs of each building by a random value multiplied by 1/64. That way each building is mapped to a different area of the of the material and things look more natural.

Effects

To make the cityscape more interesting I added a Glow image effect to the camera. It adds a subtle glow around lit areas of the scene - in this case the windows, giving it a slightly blurry look.

Source

You can grab the package with the source code here.

Here's a little piece I made after the image decomposer. This time I wanted to load videos instead of images. I had the idea to project them on a big screen so that the user can actually feel like he is in a movie theater. I started to play with it, I modeled a cinema interior, setup the lightning and I thought it's pretty neat.

You can walk around the theater with cursor keys and space to jump over the seats. If you go into the corridor in the back the movie will pause (wouldn't it be nice if that happened in real life too?). Use the left mouse button to toggle a flashlight.

Unity3D currently supports videos in Ogg Theora format only. Although it's free, it is not very popular on the net. It's mainly used by Wikipedia and Archive.org for the video content.

The demo works the same way as the image decomposer, which means you can append a URL to any valid Ogg video on the web and you should be able to watch it. To start, here are a few interesting movies I found:

Sita Sings The Blues, an animated film produced and directed by Nina Paley. More info...

Big Bucks Bunny, a short computer animated film by the Blender Institute. More info...

The Blob trailer, 1958 movie with Steve McQueen. Back then it was scary, today it's funny.

The Adventures of Flash Gordon, 1955. Probably a very bad movie.

Dynamic loading of videos in Unity is easy and it's well documented. The code is almost exactly that same as with images. I won't publish the sources this time because there is very little code in it, on the other hand there are over 50MB of textures in a pretty big mess.

If you find (or create) an Ogg encoded video worth watching post a link in the comments.
Have fun!

Just as I was thinking about an interesting demo to play with drawing functions in Unity3D, Mrdoob published his Harmony drawing tool made with HTML5/Canvas. It looks really cool, so I though how about doing this in 3D? I only had to figure out how to draw lines.

I did some research and below I present 3 different solutions. You can grab the source of the examples discussed below here.

Drawing lines with Line Renderer [demo]

When it comes to lines, the first thing you'll bump into in the Unity3D API is the Line Renderer component. As the name suggests, it is used to draw lines so it seems the right tool for the job. Lines in this case are defined by 2 or more points (segments), a material and a width.

It has an important limitation: the line must be continuous. So if you need two lines, you need two renderers. The other problem is that the Line Renderer acts very strangely when new points are added dynamically. The width of the line does not seem to render correctly. It's either buggy or just wasn't designed for such use. Because of these limitations I had to create a separate Line Renderer for each tiny bit of line I'm drawing.

It was easy to implement, but not very fast since I end up spawning lots of GameObjects each with a LineRenderer attached. It seems to be the only option if you don't have Unity3D Pro though.

Drawing lines as a mesh using Graphics [demo]

The Graphics class allows to draw a mesh directly without the overhead of creating game objects and components to hold it. It runs much faster than Line Renderer, but you need to create the lines yourself. This is a bit more difficult but also gives you total control of the lines - their color, material, width and orientation.

Since meshes are composed of surfaces rather than lines or points, in 3D space a line is best rendered as a very thin quad. A quad is described with 4 vertices, and usually you'll only have the start and end points and a width. Based on this data you can compute a line like this:

First, you get the normal of the plane on which both start and end vectors lie. This will be the plane on which the line-quad will located. The cross product of the normal and of the difference between end and start vectors gives you the side vector (the "thin" side of the quad). You need to normalize it to make it a unit vector. Finally calculate all 4 points of the rectangle by adding the side vector multiplied by half width to both start and end points in both directions. In the source code all this happens in MakeQuad and AddLine methods, so take a look in there.

It wasn't easy to implement, but once I was there it runs pretty fast.

Direct drawing with GL [demo]

No fast is fast enough! Instead of leaving this topic and live happily with the Graphics solution, I kept searching for something even better. And I found the GL class. GL is used to "issue rendering commands similar to OpenGL's immediate mode". This sounds like fast, doesn't it? It is!

Being much easier to implement that the Graphics solution it is a clear winner for me, the only drawback being that you don't have much control over the appearance of the lines. You can't set a width and perspective does not apply (i.e. lines that are far behind look exactly the same as those that are close to the camera).

Conclusion

For massive & dynamic line drawing LineRenderer is not the best solution, but it is the only one available in Unity free version. It can surely be useful to draw limited amounts of static lines and this is probably what it was made for. If you do have Unity3D Pro, the solution with Graphics is reasonable and very flexible but if it is performance you're after choose GL.

As I promised here's the first article exploring Unity as a 3D web application tool.

Every web application nowadays is data driven, therefore the ability to dynamically load assets is crucial. Unity3D can load plain text, images, video and sound. Since loading plain text is not so interesting, I thought I'd see how it works with an image.

Here's a little experiment I called "Image Decomposer". It loads an image passed as parameter in the URL and creates a wall of little cubes which colors are based on the pixels of the image. When you rollover the cubes they fall down slowly decomposing it, hence the name.

The code is pretty simple, you can get the source here. Below are a few things I found out while making it.

URL parameters

A very useful way to pass parameters to your swf files is to attach them as a query string in the embedding HTML, like this: flash.swf?paramA=valueA&paramB=valueB. It's a Flash classic!

The good news is that is also works in Unity. Take a look a the HTML source of the demo to see how the image URL is passed to the unity3d file. Inside Unity3D it's very easy to get access to it through a static property called Application.srcValue. It returns the whole path, including the file name and you need to parse the query string yourself. Here's a sample code in C#:

The 'ps' array now contains pairs of key/values from the query string.

Loading freedom

Unity3D supports JPG and PNG format. Sadly GIFs are not supported, even animated... ;) The really nice thing is that there aren't any security restrictions when loading files from other domains. This is something that drove me crazy so many times with Flash! In Unity3D pass a valid URL and it will load the asset, it's so simple. If you don't believe me - just paste any link pointing to an image in the demo ("image" parameter in the URL) and see it for yourself.

I wouldn't expect things to be like that forever though, so use it while you can people!

Coroutines and C#

To deal with asynchronous events, like loading an external asset, Unity3D uses coroutines. They are a bit different from events in AS3, but not very much. If you are a fan of C# and want to use coroutines you may find the official documentation a bit unclear. So, first, read the official documentation here and here, and continue reading this post afterward.

What caught my attention is that to use the yield statement, the enclosing method must return IEnumerator. But all of the inherited methods in MonoBehavior, like Start(), Update() and the event handling ones return void.

Surprisingly, it turns out that you can just change the signature of any of those methods so that they return IEnumerator! If this isn't breaking OOP rules, I don't know what is. But, since it works, it's ok I guess. It's certainly not obvious. Otherwise it is possible to create a custom function that returns IEnumerator and use the StartCoroutine() method of MonoBehavior to run it.

Another thing is that with C# you need to write yield return... not just yield... The official docs being written in Javascript they tend to omit the new operator as well, and C# does not like that. So, if the docs say:

and you copy/paste this to a C# script, you need to edit this line and make it look like this:

If you keep this in mind you will spare yourself some annoying compile errors.

Scaling images (or why you don't need to do this)

Once the image is loaded, it can be assigned to a Texture2D object, which is the type to store bitmaps in Unity3D. From now on it can be used as a texture for any material. For example, you can create a plane and assign it as the main texture of the plane's material or use GUI.Label to display the picture in 2D. But let's do something more interesting.

Texture2D has a few methods to extract information from the image, the most basic being GetPixel() and SetPixel(). They work exactly the same way as their equivalents in AS3 BitmapData class. The first allows to get the color of a pixel at a given coordinate, the other does the opposite.

When you start to play with these and you use images embedded in the project, make sure to select the "Is Readable" checkbox in the inspector. Images loaded dynamically are readable by default.

In the demo, no matter how big the loaded image is, the amount of cubes generated remains the same (it will adapt for different aspect ratios though). My first idea was to scale the image to something like 50x50 pixels, and then using getPixel() to fetch the color for each cube. But I found out that there isn't any function to resize an image in the API. Sure, I could write my own function, but this can get quite complex as you can see here. Fortunately there is a better way.

Texture2D has a method called GetPixelBilinear(). It uses bilinear filtering to evaluate the color of the image at a specific point defined by normalized coordinates (i.e. in 0-1 range). If the word "bilinear" sounds familiar to you it's because Photoshop also uses this algorithm to scale images. With this method the same code can be used to get pixel colors from images regardless of their size and aspect ratio:

It's much more elegant (and faster) than scaling images!

As a side note: it would be also very easy to implement an actual resizing function using this method, in case you really need that. I'm sure that by now you can figure out how to do this :)

What's next?

The above example is simple but I hope it shows you how to get started with dynamic content. As far as images are concerned, much more is possible. By using custom shaders and render textures you can apply filter effects to images (and video). However, these features are available only in Unity3D Pro and besides, explaining it would make this post way too long. I'll do that in a separate article instead.

I believe however, that Unity3D is much more that a game development platform, and all those kind of projects could be tackled with Unity3D as well. In some cases the result would be pretty awesome and way beyond anything we can currently dream of with Flash and Actionscript - and this kind of opportunity is what I am looking for. (In some other cases it could end up with a disaster, similar to what happens when sites that clearly require HTML are done with Flash. We will see those too, simply because errare humanum est).

Technology adoption is not as fast as we could wish. I'm sure that eventually Unity3D will become the standard for 3D applications on the web, but we're not there yet. So far it has been very successful with games for the iPhone and it starts to emerge as the tool of choice for online games. The advertising business will follow and adopt it as well. We can expect top interactive agencies and production companies to start releasing Unity3D productions soon. I hope this will happen within this or the next year. Chances are that such projects are already in the making.

The reason why this will happen is that Unity3D is versatile. It is marketed as a "game development tool", but it has numerous features that allow much more that that. It allows to integrate diversified content (2D, 3D, video, sound), has a great animation tool and a powerful scripting API to create any kind of complex logic.

As I got back from FITC Amsterdam loaded with new energy and inspiration, I decided to take a deeper look at Unity3D scripting and go at least a bit beyond the basics and beyond the "building a 3rd person shooter" scenario. As a long time Flash developer there are some problem/questions that are typical to Actionscript technology and I decided to check how similar problems can be solved with Unity3D. Here are the first few questions that came to my mind, pretty basic actually:

1. How to dynamically load an image into Unity3D and do something with it?
2. How to load a video?
3. How to draw lines, points and shapes at runtime?
4. How to generate content with code?

The questions order starts with those that have been easiest to answer. I have some more questions lined up, so this post might get updated. Anyway, in the coming days (or weeks rather) I'll be posting the solutions. I made some experiments, I have some code to share and some tips that I found on the way. See you soon!

The conference season is upon us!

Following my last year short presentation at Flash On The Beach and at the Warsaw Flash Camp, this year I will continue my adventure with public speaking. In the next months I will be having my sessions at 3 highly interesting events.

1. FITC Amsterdam, February 22nd-23rd

FITC Amsterdam is only a few weeks away. I've been to FITC last year and I really enjoyed the conference (and the parties too). I am thrilled to be back this year as a speaker. If you want to catch my session it's on Monday (Feb 22nd) at 12:30. If you are interested in Unity and in 3D in general you should definitely attend! For more information, here's a detailed session description. I hope to see you there!

FITC it's of course much more than my presentation. There are 2 days packed with interesting sessions, so be sure to checkout the schedule to see what's interesting for you. There is also a party every evening - a great opportunity to do some networking and to have a few beers and some other stuff (remember, we're in Amsterdam!). So grab your tickets before they're all gone!

2. London LFPUG Meeting, March 25th

If you can't attend FITC and you miss my session in Amsterdam, don't panic! You can catch me again next month in London. On March 25th I will speak at the next in the series of LFPUG meetings.

It will be a evening packed with realtime 3D, as I will be speaking together with Rob Bateman from the Away3D team. Here's some detailed info about the event. The event is free, all you need to do is register, so if you are in London don't miss it!

3. FITC Toronto, April 25th-27th

Finally in April I'll be making the move over the Atlantic all the way to Canada for FITC Toronto, where I will also be talking about Unity. There is no schedule yet, but it's should be coming soon. However, the tickets are already on sale. If you hurry you might even get a early bird price!

This is very exciting for me for several reasons. First, it's a major conference with 3 days of sessions, workshops and even a recruiting event. It's not to be missed not only if you live in Toronto, but for anyone in the region. And I've heard people come for FITC from all over Canada and US.

Second of all it's my first time I will attend a conference in North America. I looking forward to meet a lot of people whom so far I knew only from blogs and twitter. So if you are around don't hesitate to get in touch!

Finally, it will be my first visit to Toronto and I heard a lot of good stuff about the city. We also plan a short family vacation afterwards to visit Montreal and Quebec Miami and the Florida Keys.

Next?

I'm currently entirely focused on those upcoming events, preparing all the materials and the presentation. However, I hope for more opportunities in the future. If you happen to organize a Flash and/or Unity event and you are looking for speakers be sure to let me know!

I don't have any further plans at this moment, except that I will also attend OFFF in Paris in June (as guest, not as speaker).

Photo credits [1] [2] [3]

I am proud to announce my latest project. It's a 3D racing game done in Flash with Away3D. I worked on this project together with Calisto Labs and our client was Snowball Media. My task was to create the 3D game part. It was great fun to work on this project. The team at Calisto Labs did a awesome job and everything went smoothly!

The project required to use my Actionscript and 3D modeling skills together on a scale like I never did before. I spent a lot of time with Blender and Unity in the last months, and without this experience I feel the project would be beyond my abilities. Also, having a direct comparison between Flash and Unity allowed be to see things in a larger perspective.

Flash vs. Unity... again

I built the game with Away3D FP10. I must say that Flash 3D has gone a long way since I first started to play with it, and Away3D is a very solid engine. The 2K polygon limitation is a thing of the past, and the correct perspective projection in FP10 makes everything look so much better. The team also added some other crucial features to create 3D environments - ex. frustum clipping.

Before starting this project I was working on a Unity3D racing demo, so I managed to get quite a few ideas on how to build such a thing. However, when I moved back to Flash, I was a bit desperate because I realized how much stuff I got used to in Unity is just not there in Flash. A built-in physics engine would be the most important one.

Home-made physics and collision detection

For physics in Flash I was tempted do use JigLib at first. But soon I found out that JigLib is way too complex, creating a realistic car behavior would be very difficult and it would probably eat too many CPU cycles. I estimated that Away3D will take around 90-95% of available processing power, so there's no space for any other complex piece of code to run in the same time. I always think that when it comes to 3D in Flash performance is quality, and there is no excuse for poor performance, even if you want something to look "realistic". So I ended building something very very simple.

Once I got the car driving around, I needed to add some collision detection. In Unity you quickly get used to the fact that any 3d object is a collider which makes collision detection a no-brainer - just implement a listener method and get a call whenever your object collides with another one. And if you need to add realistic collision response, you just make the object a rigid body and there you go! (Ok, you may need to adjust some settings, but still it's pretty straightforward).

In Flash it seemed like a much more complex task. I was thinking in the lines of creating a system based on the geometry of the track. I started to study curve equations just to realize I wouldn't make it even if I had a year to complete the project! Then I remembered, that a good way to test collision with complex shapes is a bitmap.

The way it works is that it takes the car's position and checks against a map of the track that has different colors for different areas - ex. red for the road, green for the sideways and so on... Since it samples only a few pixels per frame and all it does is check their RGB values, it's lighting fast. Truly, Flash is the art of minimal!

Scenery

The most fun part was to create the scenery. I've never tried to import such a large 3D scene into Flash so I wasn't even sure if Away3D would handle it. It turns out it did handle it pretty well. Instead of using Collada I went with Wavefront (OBJ) format for the meshes as I feel it gave me more flexibility. OBJ is a simple format which makes it a bit easier to see what's going on while Collada is bloated and overly complex for my taste. I used Blender to model the track and the few objects that you can see around it - lampposts, houses and the tunnel.

Lightning

Lightning is very important in low poly scenes, because it adds a lot of detail and atmosphere to the scenery, without adding any polygons. Even thought the scenery is simple, I ended up having more that 60 lamps. Of course all those lights needs to be baked on the textures, there's no way to run them in real-time. Blender has a very good texture baking tool and all this works fine for static objects. But what about objects that move, like the car?

For lightning the car, I reused the concept from collision testing. But instead of a collision map I made another one - a light map. Basically it's a bitmap with white areas where the scenery is lit and dark ones where it's not. By sampling a single pixel on every frame I can see if the car is passing through a lit area. Then, all I have to do is to apply a color transform on the car texture to make it brighter. Again - a minimal solution, but it works!

Now that you know all about it, go ahead and try it out!

Ringo from FlashBookmarks asked me if there were modifiers similar to AS3Dmod in Unity. I searched for something similar some time ago, but didn't find anything interesting.

However, when I was starting C# scripting, I ported two of the modifiers from AS3Dmod - Bend and Twist. So I thought to share them with everyone. Don't expect much, it's not the full library, just two classes. If I have some free time, I'll look into how to implement stacking, since for the moment you cannot apply two modifiers to the same object (the second one won't have any effect).

To play around with them grab this package and import it into Unity. Keep in mind that the modifiers work at runtime, so you won't see any effects in the editor until you run the game. If you want to animate them, just add another script that will have a reference to the modifier instance and change it's properties at each Update() call.

If you are interested in this kind of "bricolage" with 3D geometry, I recommend to take a look at the Procedural Examples project provided by Unity. You will find there some highly interesting samples like dynamic extrudes or perlin noise. It's a great starting point to explore runtime geometry transformation.

Of course, take a look into the sources of the modifiers too! You'll see how simple it is to access the geometry at runtime and do some modifications. Basically it goes like this:

Things worth notice: In Unity a vertex is just an instance of Vector3 - there isn't any special class for this, as in Flash-based 3D engines.

You can see a bit of the casting-drama I need to do (lines 1-2) to get to the object holding the actual geometry information (Mesh). That's a bit annoying in C#, with JS that code would be more readable. Anyway, it's better to make that only once, in Start() and not at every Update().

To get correct lightning effects on the materials, do not forget to call mesh.RecalculateNormals() after you've modified the positions of the vertices.

If you want to modify your mesh continuously (i.e. to animate it) it's necessary to keep the original array of vertices, because the code above overwrites the original positions. Take a look at the source code in the package to see how I did it.

That's all for now, hope you enjoy it!

There's something you'll quickly realize when you start playing with Unity. It's the fact that you won't go far without some basic knowledge of a 3D editor. I've been using Blender for my Flash 3D experiments, but I can't honestly say I knew anything about it. I was able to model some very basic shapes, and whenever I needed something more complex I'd ask someone who's more experienced or just find a free model on the Internet. With Unity it just doesn't make sense. You won't be able to understand half of the functionality if you don't have a 3D editor to work with. By the way, I'm not the only one who noticed this.

As a logical consequence, I decided to take a step back and learn Blender. I don't want to go into details on the choice of software. If you prefer Maya or Cinema4D, fine. I grew to like Blender, but I know it makes a horrible first impression. The thing about Blender is that it's free, and that's a huge advantage for beginners.

After some time of modeling, texturing and setting up lights and I started to really love that. I felt like I was taken 10 years back, at the time when I was discovering Flash, HTML, building my first "home page". I'm sure you all know the great feeling when you start to understand something new and your skills grow every day. There's nothing like it! (Ok, there are other things better than that, but let's stay within our geeky subject).

At first I wanted to get just enough skills to continue with Unity3D development. But soon I realized that this might be what I'd like to do for a living. Wait, what? Can you imagine? I'm in my thirties. I'm doing pretty well in flash development business. Is there anything more stupid that dropping all this and becoming a 3D designer? And how many years I would need to become any good at this? Or maybe it's just a matter of a couple months to master the tool and I'll be all set? But maybe I don't have what it takes to be a 3D designer. However a fundamental thing I believe in, is that there's no such thing as innate talent and all you need is enough persistence...

I've been struggling with those questions for a while, and I don't have any answers yet. In the meantime I ordered some books, found some tutorials and kept learning to keep all the options open. I still have a long way to go, but I can already see some results.

As my modeling skills grow, I feel much more confident as a 3D developer because I can understand where the assets come from, how they are built, how visual effects are achieved. Those things were like a black box to me before. Now I can even build some 3D stuff myself. It's so much worth the effort even if I'll never work as full time 3D designer.

The two Unity examples above are my first, modest 3D modeling experiences. One is a mini game. It features a scenery that I populated with a few models including my first car model. Apart from modeling the scenery elements I used that as a testing ground for many Unity features like the terrain engine, line and trail renderers, rigid body physics, car simulation, particle systems and of course scripting. The end result is a bit random, but I don't remember having that much fun for a long time!

The second is a small interior scene (really small!). I couldn't grasp how lightmaps work in Unity until one morning I woke up and I just knew (yeah, that's how it happens sometimes!). During the day, I quickly threw up this demo to test if my understanding was correct. I think it was, even though in the end the shadows came out too subtle. Anyway, I'm doing more experiments on that subject now and maybe I'll write a separate post on how to work with lightmaps in Blender & Unity.

That's it for now! I'll see where it takes me, but you should expect more 3D modeling related posts on this blog from now on. Also, I'm not giving up on coding... yet ;)

I like books. A book is always a good thing, no matter how abundant online resources are. It's always at hand, with all the information brought together in one place, not scattered across different sites or even worst, across different forum threads.

When I learned a couple of months ago that Will Goldstone was writing a book on Unity3D, I was pleasantly surprised. A bit later Packt, the publisher of the book, contacted me asking for a review.

In the meantime the book hit the shelves, and there was some buzz on Twitter, so there's a good chance you've already heard about it. If you are still wondering whether you should buy it, keep reading.

Great for beginners

The book is written in the form of one big tutorial. The author leads us through different parts of the Unity3D IDE in the course of creating a simple game. The word "simple" is key here. Before I had the chance to read the book I went through the Unity3D official tutorial which has a similar structure. It presents us with a very cool 3D artwork and a pretty complex game to build. Compared to that, what we will create with the book is pretty basic. However, in this case: simpler means better.

After completing the official tutorial I felt I merely scratched the surface, and many parts of it were too complex to follow. The book doesn't leave you with this feeling. You'll be guided in creating a game but you will do it from scratch and all the steps are explained in depth.

Scripting

I assume most readers of this blog are familiar with programming. In this case you may find the code presented in the book somewhat rudimentary. One way of making it more fun is to translate the code from JavaScript into C# on the way. I did that, and I think it's much more beneficial than just copy-pasting. At least you will read it that way.

Furthermore, Actionscript 3 programmers can find that some examples are bending the rules of strict OOP. Again, for a seasoned AS3 developer, restructuring the code in those places can be another good exercise.

The book covers obviously more than just scripting. Among other topics, I particularly enjoyed the chapters on particle systems and on 2D GUI (as you will find out, 2D GUI is the weird part of Unity)

Other ressources

An indispensable companion of the book is the Unity scripting reference. The docs are solid and in most cases you'll find what you're looking for. Not always however, and if you feel you need more info I recommend to search the forums. I am not a fan of forums overall, but I must admit that the Unity3D forum is a pretty good resource.

A remark on the Unity3D documentation

A bit off-topic, but I will take the occasion to rant about the Unity3D scripting documentation. Not about the content, but about the form.

In the Unity3D docs the list of classes is sometimes placed on the left column, sometimes in the middle. Sometimes they are listed in alphabetical order, sometimes presented in an inheritance structure. Every property and method is presented on a separate page, which is a big waste of space given the fact that most of them have max 2-3 lines of description. It leads to constant back/forward clicking when exploring the API. And it might get even worse when Unity will introduce namespace support.

It would be cool if the docs followed the good old Java standard, where the list of classes is always in the same place, always accessible and in alphabetical order. The properties and methods are listed in one big table, which is also much easier to browse.

OK, enough complaining, now back to the book...

Conclusion

If you want to get into Unity, it's probably a good idea to buy this book. You'll get yourself a decent introduction to the main aspects of the software. Remember that you won't learn any advanced stuff like stucturing code in large projects, writing custom shaders or making advanced physics simulations. The important thing is that the book explains all the basics leaving you well prepared to explore the rest. I enjoyed reading it and I learned quite a lot!

Unity3D offers a choice between 3 different programming languages: JavaScript, C# and Boo. Each of them has its pros and cons, but for me C# almost immediately came out as a clear winner. That is because it is fully object oriented and it's syntax is similar to Java and Actionscript 3, both of which I am experienced with. However, before I started to play with Unity3D, I never wrote a single line in C#, so I had to learn it from scratch.

As you probably know C# was originally developed by Microsoft and is widely used in the .NET framework as well as in Silverlight development. It is important to understand however that learning C# for Unity3D is not the same thing as learning the .NET platform. In fact you don't have to know anything about .NET to use C# with Unity3D.

While I use all kinds of online documentation, a book is often the best companion, so I thought buying a good C# book would be in order. It turns out that the small O'Reilly C# Pocket Guide is exactly what one needs. It is absolutely unnecessary to buy a 500 page C# bible, as most of the stuff in those books is related to .NET and is not applicable to Unity3D at all.

Of course the book alone is not enough. You also need the Unity3D scripting reference. All the examples in the docs are given in Javascript only. But don't worry, they are easy to translate once you get used to.

C# is a very elegant and powerful language. It's dot-syntax is based on Java, so if you come from a Java background you'll quickly feel comfortable with it. There are a few differences though. The most striking difference is the convention to start property and method names with an uppercase letter. I guess it comes from Visual Basic. I am not a fan of this convention, but it's better to use it and have a consistent code rather than fight it.

The list of all C# features is so long, that it makes AS3 look poor in comparison. C# is really like Actionscript on steroids. I suppose the next version of Actionscript will have at least some of those implemented, so it's good to know about them. Here's a list of my favorites.

Operator overloading

This is the coolest one by far! It allows to define custom actions for common operators like +, -, * or /. The best illustration of this feature comes with vector addition. In Actionscript, to get a sum of 2 vectors you need to write something like this:

This is not very nice, and becomes almost unreadable if more than two vectors are added. In C#, thanks to the overloaded + operator it looks like this:

This is much more readable and elegant, isn't it? It goes without saying that the 3D vector implementation in Unity3D has all the operators overloaded. In case you want to do it yourself however, the implementation of operator overloading is very simple and in the above case could look something like this:

There are some simple rules: the operator function must always be static and must return an object of type it is defined for. However it can take any type of parameters. This allows to define operator overloading for adding or multiplying vectors but also for multiplying vector by a scalar or multiplying vectors by matrices. In fact this can be achieved thanks to another C# feature - method overloading.

Method overloading

Method overloading allows to define multiple methods with the same name provided that they take different parameters. It works with regular methods and with constructors as well. If there a multiple ways to create an object you can define multiple constructors to satisfy each case. As mentioned above it works with operators too.

A good example of method overloading in Unity3D API is the 'Transform.Rotate()' method. It has has been overloaded 3 times with different ways to specify a rotation:

You can either pass a vector of angle values, three floats - one for each axis, or a single angle combined with a rotation axis. This is only logical to call it 'Rotate' every time because this is what the method does at the end.

Actionscript has default parameter values, which in some cases can simulate method overloading but they are not quite as flexible as that.

Getter/setter syntax

C# has a very concise way of declaring parameters. While in Actionscript it takes two functions - one for 'get' and one for 'set', in C# it can look like this:

In this case the compiler automatically adds a private member for this property and there isn't anything else you need to do. Of course such a parameter is not very practical, so here's a more complex code, involving a public getter and private setter:

You will also notice that neither the 'function' nor the 'var' keywords do not exist in C#. In that C# closely follows Java. This is good because both these keywords are completely redundant and do not add any information to the code.

Among other interesting features I recommend to explore indexers, generic types, structures and enumerators all of which are covered in depth in the pocket guide mentioned above but also in the many online C# tutorials.

Editing C#

There are multiple editors that support C#. Microsoft offers a great and free editor called Visual C# Express Edition which features code completion, but is Windows only (obviously). For a Mac there's Mono Develop which looks very powerful, but is not very stable yet. Unfortunately the C# plugin for Eclipse is completely unstable for the moment, and I wouldn't recommend it. On the other hand, it is still in alpha so let's give it some time. Of course there's always TextMate.

Last but not least there's Unitron - the Unity3D default editor. It is not very popular among developers, and I saw people complaining about it being too basic. I don't share this opinion. While it ain't no FDT, it's pretty solid, very stable and has basic auto-completion. The trick is auto-completion is turned off by default (why?). To turn it on go to 'Preferences' and you'll find it at the bottom of the 'General' section. With that, I'm sure that Unitron is enough to get started.

Most of us know JavaScript from the browser environment. JavaScript is often the first programming language people ever used. If this is the case, you may be tempted to just use JS with Unity3D right away and not bother learning anything new. After all, as far as Unity3D is concerned, anything that can be done with C# can also be done with JavaScript.

However in the long term, C# offers better control over the code, full OOP support, strong typing and a lot satisfaction of mastering a robust programming language, so the extra effort is worth it. Plus, for a seasoned AS3 developer, mastering C# is a matter of a couple of weeks anyway, so go ahead and try it out!

UPDATE March 2010. Here's a new post about C# and Unity3D:
Loading and manipulating images in Unity3D
(more coming)

How I learned to stop worrying about plugin penetration and love Unity3D

I started this blog almost 2 years ago with an idea to explore the world of 3D in Flash and learn new stuff on the way. I quickly fell in love with Papervision3D. It offered a whole new world of possibilities for someone like me - bored with buttons & dropdowns and not particularly interested in building Flex-type applications.

Unfortunately the performance limitations of Flash Player prevented me from going far beyond the demos I posted on this blog. Creating a solid piece of 3D in Flash, with a decent frame rate is either impossible or requires an insane amount of code optimization. It often means resorting to low level programming. I think it is dangerous, because it's easy to loose track of the overall picture then. I feel that this is what happened to me the last few months.

I sure heard about Unity3D before, but, as it often happens, I did not have time to take a closer look. I applied for the Unity 2.5 beta test program back in February. I was accepted and got a 30-day copy of the software. What happened next? I opened it only once before the trial expired.

It's just hard to move to another software/platform when you are so completely immersed in Flash. Unity3D ended on my perpetual to-do list alongside with so many other things. I am sure many of you feel the same way.

A new toy

Recently I bought a Macbook Pro. My first Mac ever! A friend suggested that I move all my projects and workspace to the Mac immediately to make the transition fast. Unfortunately I had some difficult and urgent projects to finish, and ultimately I decided to stick with Flash on the PC for a while.

I had to do something with the Mac then... and that's where Unity3D comes in. Additionally, this time I decided to buy a license, thinking that spending those 150 EUR extra will make me even more motivated.

After just a few hours I was amazed. And I mean AMAZED! You can check the Tropical Paradise demo if you haven't seen it yet, download the trial copy and start exploring the 3D Game Tutorial to see what I mean.

It's not only how fast the 3D rendering is. Unity3D has a very intuitive interface organized around a simple and clear concept. I can literally see myself doing 3D games in a matter of weeks from now. Doesn't take long to realize the sad truth that Flash is far behind in almost every aspect.

The myth of high penetration

I do not want to do a list of pros and cons or some Flash vs. Unity3D comparison here. For a person who wants to do 3D for the web Unity3D is the winner by knockout and it makes no sense to elaborate on the subject.

However, there is one common argument against Unity3D. It's the low penetration rate of the web plugin. While Flash Player is at 98%, Unity3D is probably at < 1%. Aye! That sounds bad, doesn't it? I thought so too, but I made some thinking and researched a bit. Now please consider these points:

• Unity3D plugin is only ~4MB and it's installation is seamless. In most cases, it doesn't even require browser restart. Thanks to this it has a high successful-install rate, which means it's share of the market will be quickly growing. You can read a whole article on this topic here.
• Content created with Unity3D can be visually and interactively much superior to anything you can do with Flash. This will convince people that the little extra effort required to install the plugin is worth it.
• Most important argument: people access content from different devices. There are mobile phones, consoles, multi-touch interfaces etc. PC is no longer the king. Unity3D can be published for two of the most successful platforms out there: iPhone and Wii. "Web penetration" has no practical meaning in this case.

So, if you think Unity3D is not worth looking at because of the low penetration of the web plugin, think again!

This blog note may seem emotional. It is! I feel I have discovered the perfect technology, that I have been looking for and I just wanted to share. Now I need to master Unity3D as quickly as possible. On my way I will certainly discover it's flaws... it must have some. Maybe later I will find a more objective way to compare Flash and Unity.

Flash is much more than 3D and there are multiple directions it is evolving in. I am not predicting "the end of Flash" or anything like that - it would be ridiculous. Unity3D on the other hand, with all it's coolness is still the new kid on the block. It might be a huge success but it might as well share the fate of Wild Tangent and Shockwave players (I hope not!).

One thing is sure: if you are into 3D, you can't miss it!