We do this with a combination of:

• Continuous Integration
• Automated Testing
• Code Hosting
• Code Reviews
• Manual Testing

I’ll talk about how we do the first four of those things here.

Continuous Integration

The Continuous Integration Server

Our builds and automated tests are all run by TeamCity.

We use TeamCity from JetBrains as our continuous integration solution.  One of the things we like best about TeamCity is that it has a very clear UI that gives the end user a good indication of the state of a project.  For testsuites, it’s easy to see at a glance whether the suite passes or fails and what tests are failing.  It can farm builds out to agents on Windows, OS X, and Linux, and keeps an extensive history of builds and tests, which are very useful when trying to figure out why a test is failing or whether there is something wrong with an agent.  Generally speaking, we are quite happy with the feature-set and also with the support we’ve received from JetBrains.

Our only real complaint now is regarding the web UI — it can still be slow to load at times (specifically, when loading a large project page that hasn’t been loaded for a while, or when opening the custom build run dialog when a lot of agents are attached).  It can also be difficult regarding managing multiple branch projects, as there is currently no way to synchronize changes between branches that are copies of each other.  However, the projects are stored in XML, and the schema is not complicated, so I have written a tool to do this instead by modifying the XML directly.

The Build Farm

TeamCity farms builds out to a distributed build farm of between 40 and 50 machines.

Along with TeamCity, we have a build farm of approximately 45 machines, known as build agents.  Most of these are virtual machines running Windows, Mac OS X, and Linux.  We also have a few physical machines used for graphics tests, because testing graphics functionality requires a level of GPU manipulation that we could not achieve with virtual machines.  Our virtual build agents are virtualized with VMWare Workstation on Linux hosts, using a combination of Apple and non-Apple hardware.

The reason for choosing virtual machines, despite the performance hit it gives us, is that virtualization allows us to easily maintain the system — instead of updating 45 machines separately, we update the template virtual machine image for a given operating system, then copy it to the live buildservers.  It also allows us to make every agent appear to be the same hardware-wise, even if they are running on different types of host hardware.  This is important because as we add more build agents, they will be running on different generations of hardware, and for the purposes of testing, we need them to all appear the same.

Automated Testing

TeamCity provides a very clear interface for seeing the status of test suites.

We have several automated test suites that we run on a regular basis.  These are used, along with manual testing, as a metric for how stable our mainline codebase is, as well as when a feature branch is stable enough to be merged back into trunk.  We currently have four types of test suites:

• Unit Tests — these test the correctness of individual functions / small bits of functionality in the code, but they do not test high-level features of the product.  These are used by developers, but not by our continuous integration server.
• Graphics Tests — these work by building a Unity project that renders a set of static scenes.  The project is then run on the target platform (desktop, console, or mobile), and screenshots of each scene are saved.  We then compare the saved screenshots against a set of “known good” screenshots.  If the difference is greater than a certain amount, we assert that the test has “failed”.
• Functional Tests — these work by launching one instance of the editor or player, and testing various aspects of its functionality.
• Integration Tests — these are the most high level tests.  They work by launching an instance of the editor or player, testing a particular action or series of actions, and shutting down the editor or player and going on to the next test.

Our integration tests are executed by our continuous integration server as NUnit tests.  TeamCity can run MSBuild projects directly, and we have a script that runs them with Mono’s Xbuild on Mac OS X.  We developed our own framework for running the graphics tests.

Our regression rig tells us if anything has changed in the playback of previously-recorded content.

We also have a regression rig that we developed ourselves.  The regression rig, similar to the graphics tests, compares content played in Unity against previously recorded content, and checks for regressions.  This is a good way to catch high-level regressions (for example audio having become bit-shifted).

Our test suites are always being expanded, and, along with our regression rig, they have helped us catch a number of regressions and bugs.

Code Hosting and Reviews

Like many software companies, Unity Technologies has run through a few different version control systems.  In the beginning, there was no version control.  Eventually the first Unity Ninjas began using CVS, and eventually Subversion. About a year ago, we started to investigate distributed version control systems and eventually settled on Mercurial.  Now all of our source code is versioned in Mercurial, except for our public Mono, MonoDevelop, and Boo-related repositories on GitHub.

Why Mercurial?

Well, we had a few requirements.  The first was that the version control system work with our continuous integration server, which is TeamCity, so we started off considering Git, Mercurial, and Bazaar, and Perforce.  We also wanted something distributed because we have developers working in several different locations, and we also work on multiple platforms.  A distributed system allows our developers around the globe to interact with the remote server less frequently, and it also allows all of us to easily test our changes on multiple local machines without having to share changes that potentially break some other platform with each other.  We also wanted to be able to do feature development in branches and merge them back together successfully.  So we were left with Git, Mercurial, and Bazaar.  We spent some time evaluating these three systems.  We were interested in:

1. A simple, easy to use and understand command-line interface
2. Good GUI tools for the system on OS X and Windows
3. A good code review tool that works well with the system.

We also wanted a system that we felt had a lot of momentum — an ecosystem that is growing and developing around it.  After a few weeks of testing, we eventually decided on Mercurial because:

1. It was substantially more simple to learn and use than Git
2. It had good GUI tools for both Windows (TortoiseHg) and Mac (SourceTree, and now TortoiseHg)
3. It had a couple of different options for large-scale code review tools
4. It had a good-sized user-base (which is growing), a regular development cycle, and seemed to be well-adopted by both open-source and and commercial projects

Another very big win for Mercurial is that it was the only DVCS (at the time, at least) that had even attempted to handle the issue of large binaries in the repository.  This was done through a few different publicly-available extensions to Mercurial.  Distributed version control systems, by nature, don’t lend themselves well to codebases with a lot of large binaries, so we knew we would need some system that can cooperate with the version control system to store the large binaries outside of the repository, but still let us version them in some way.  Not having to develop our own system completely from scratch was a really big win.

How to Host Mercurial and What to Use for Code Reviews?

After we decided on Mercurial, we needed to figure out how to host it and how we would review code.  With this switch, we also wanted to implement a new development policy.  Up until this point, we had always worked with just one central copy of the codebase, except for when we branched for release.  This led to something almost always being broken, which had a serious effect on productivity.  We wanted to be able to easily do feature development in branches; perform peer code reviews, build, and test verification on the branch; then merge it back into the mainline repository once it is complete.  The goal is that trunk is always in a releasable, or nearly releasable, state.

A Code Review in Kiln.

We looked at a few different code review systems, and eventually settled on Kiln from Fog Creek Software.  Many people already know that we have used FogBugz as our issue tracking system for a while now.  While FogBugz has some room for improvement (specifically, it doesn’t work very well as a public-facing bug tracker), it has done a pretty good job of serving our needs, and we have a really large amount of data in the system.  At this point, we would need a pretty compelling reason to put in the effort to move all of that data to a new system.  Kiln is a Mercurial code hosting system that interfaces with FogBugz and provides nice web-browsing of the repositories, code reviews on a per-changeset basis with one or more reviewers, and a server-side implementation of a Mercurial extension that handles large binaries. We have had some ups and downs with Kiln, mostly with regards to performance.  Our repository size, which is about 1.6 GB with a clean working copy, and has several fairly large binaries, as well as our number of concurrent developers, about 65 and growing, and our build farm, another 45 or so machines, seem to have pushed it to its limits performance-wise.  The self-hosted version of Kiln is currently not built with scalability to large teams (with large repositories) in mind, which results in very slow clones & pushes when there is heavy load. Hopefully, this will get resolved in the future. We’re not sure what our own future is with Kiln, but I will say that its feature set is quite nice, and it has allowed us to move to our desired development model of feature development in branches rather than in mainline.  Beware that it is written in .NET and does not run on Mono, so if you want to consider Kiln, you will need to run a Windows server.  I can say, however, that the Fog Creek support staff has spent countless hours trying to help us work through our various issues with Kiln.

Conclusion

Building and testing for so many platforms is a really difficult task — especially as our development team is rapidly growing, and we find ourselves putting strains on infrastructure and processes in areas we didn’t expect.  These tools and processes are fundamental to how the development team gets things done here at Unity.

What elements make water?

Hydrogen & Oxygen

in Unity?

There are many different types of water you can create or use from prefabs. To take advantage of the latest water effects and scripts I will be concentrating on the Water4ExampleSimple assets which are essentially a couple of 3D meshes representing your water surface, with:

• WaterTile script
• Water shader

An empty object indicating the world space placement with:

• A Water script which exposes the colours, normal texture and main parameters for the effect
• A reflection script
• An optional lighting script for specular effects
• An optional displacement script

How can I make some water?

The simplest way is to drag the prefab into your scene, and assign your custom mesh:

• Assets > Import Package > Water (pro only)
• In the project window open the  Standard Assets > Water (Pro only) folder
• Open up Water4 folder
• Drag the Water4Example (Simple) Prefab into your scene
• Position approximately where you need it
• Select one of  the tile meshes, go to the mesh component in the inspector > select the round target icon on the right and choose your mesh (must be in your project)
• Rotate the Water4ExampleSimple parent node 90 degrees, if your mesh comes in at the wrong angle (this can be caused when you export from a 3D app with a different co-ordinate system to Unity)
• Place your mesh by moving the parent node
• Remove the second tile mesh

Settings

Once you have your mesh as water you can begin to play with the settings. Select your Water4ExampleSimple node, and check the parameters in the inspector.

Water Base

Planar Reflection

This script is for enabling/disabling realtime planar reflections. Reflections are claculated in relation to the height of the parent mesh that has this script attached to. So the local Y transform of child meshes should be 0. Here you can also enable the reflections to include (or not) the skybox.

Specular Lighting

You can adjust the specular power from here and drag’n'drop any transform to indicate a specular light source. This can be your directional light transform or any other game object (doesn’t need to be a light).

Gerstner Displace

Here you can adjust the settings for the wave generation created by the Gerstner waves generation algorithm.

Water art tips

• Go and check out some actual water – its always wise to get some visual ref for what you are trying to do. Make a video if you can.
• Water absorbs red light from the spectrum reflecting back more green and blue rays, in additions to sky, which gives water the impression of being Blue in colour so:
  • You can’t make your surface blue (and you probably shouldn’t)  but if you use green and blue colours on the surfaces below the water such as a pool you can help with the illusion.
  • (I guess this is why Pool designers use green/blue/turquoise tiles).
  • The darker the blue, the deeper water appears – you can use a darker colour on the bottom and tint the refraction darker.

• Moderate the effects, subtlety can help suspend disbelief, be sure to experiment but think about moderating:
  • Scrolling speed of normals
  • Reflection
  • Refraction
  • Fresnel and Normal strengths
  • Displacement

• One useful tip is to turn practically everything off e.g. set sliders to zero and then build up the effects to get the desired impact.
• If you have a convex mesh (such as water fall/pool lip) add poly detail to the curve to help the water ‘bend’.

Next time > Water 4 Advanced is the same tech but with foam and depth extinction.

They’ve also done an awesome job continuing their support of their services for Unity users by releasing several new tutorials that will help you get started. The latest videos will help the Blender, modo and zBrush crowds. Now go animate something/someone!

Blender:
http://www.mixamo.com/c/automatic-rigging-for-blender-unity3d

modo:
http://www.mixamo.com/c/automatic-rigging-for-modo-unity3d

zBrush:
http://www.mixamo.com/c/automatic-rigging-for-zbrush-unity3d

It may be a worthy read both for artists and programmers, as we discuss the possibilities of some unusual special effects and their technical side.

Get it while it’s fresh: Special Effects with Depth (14MB pdf)

Yours,

Kuba and Ole

The goal for the asset store has always been to be a quick and convenient way to get assets for games. With Unity 3.5, we’re taking a huge stride towards this.

Part of 3.5 is a revamped object picker. The idea is that you will be able to quickly browse and assign all assets in your project – and available online – from one integrated window. Something like this:

Ahem.

So yeah, a bunch of us were at SIGGRAPH 2011 in lovely Vancouver, doing talks, meeting people and going to super interesting sessions. Me & ReJ did a long technical session about optimizing graphics for mobile platforms. GPU architectures, shader optimization details, case studies from actual Unity games and so on.

Here it is: Fast Mobile Shaders (17MB pdf).

Enjoy!

Since 64-bit browsers are not yet very widespread on Windows, the 64-bit web plugin has received limited testing coverage during our 3.4 beta. For that reason, we have decided to make this plugin available on an experimental basis for anyone who wishes to test or run Unity content in a 64-bit Windows browser. It is not yet available on our our main Web Player download page and the default JavaScript we supply for embedding Unity content will not link to it, so you have to manually download the installer. If 64-bit browsers become more common on Windows in the future, we will change this and release it as a fully supported product.

Without further ado, here it is!

Even though this is an unsupported product, please use the bug reporter which comes with Unity to report any issues you might have with the plugin!

Unity 3.4

We’re about to enter release candidate 1 with Unity 3.4, which is a feature + bugfix release. Here are some highlights:

Allegorithmic Substance integration

Procedural textures are built directly into Unity. Substance procedural textures can be tweaked in Unity. You can even update your textures at run time. It can be used for anything from ageing effects on textures to customizable characters.

Shadow improvements

Directional lights got a new shadow projection mode called “Stable Fit”. Now there’s no more shadow boundary shimmering when rotating the camera!
Regarding optimizations, we cull shadow casters much better now, which means fewer draw calls. Shadow culling can also use occlusion culling data.

Skinning performance & multicore

Skinning performance is 2-3x faster on PCs due to SSE2 optimizations and multicore improvements. There’s also multithreaded skinning for the latest iOS and Android devices.

Downloadable content with caching for complete scenes and asset bundles

This is a cross-platform  feature including iOS and Android that’s perfect for downloadable content. Asset bundles and even complete scenes can be downloaded on demand and cached locally. The caching API gives you full control over when to download a newer version of the asset. Using the caching API dramatically reduces memory usage and has a huge impact on load times.

Script execution order

Unity now gives you eplicit control over the execution order in your scripts. Awake, OnEnable and Update calls are sorted by execution order. Execution order can be defined on a ‘per script’ basis in an easy-to-understand dialog.

Animation & skinned mesh bounding volumes

Pre-computed bounding volumes for skinned meshes & animations let you have more animated characters in your scene.

Graphics optimizations

We implemented various graphics optimizations, ranging from faster deferred lighting (due to more compact light shapes & better occlusion culling) to faster OpenGL ES 2.0 and more mobile optimized shaders.
Last but not least: Terrain works on iOS and Android now.

Image effects & water

There’s a big upgrade to image effects & water. Both have been optimized for performance and, at the same time, visual quality has been improved. They’re also easier to tweak for artists.

Unity Xbox 360 and PS3 release in parallel

All console versions are now released at same time as 3.4. and projects can easily be moved between all platforms.

Rochard, our first PS3 game, has just gone through the Sony submission process.

Better gizmo/handle control

You no longer need to code to add icons to your game objects. Now you can simply set the icon in the game object inspector to quickly see and select things in your scene view. If you want to see icons for tools like pathfinding nodes, just set the icon on the node script in your project and they’ll all show up in the scene.

You can also toggle the display of handles on a per-component basis so now there’s no need to hold back when writing custom editors.

Fast collider tweaking

If you select a collider and hold down Shift, small dots for resizing the colliders will appear. This makes it really quick to set up efficient collision levels so they run really fast on mobile devices.

Hundreds of minor improvements and fixes

Unity 3.4 also has loads of smaller improvements, shine-ups and fixes.

Next release: Unity 3.5

This year we’re focusing on enabling you to push all platforms to their limits. Unity is the most optimized game engine for mobile devices and we’re working hard to also make this true of all other platforms. It’s a big step for Unity to support AAA productions. We have tons of performance optimizations, better multi-threading and a big graphics engine upgrade. At the same time, we are also improving work flows, especially when working in larger teams. Unity 3.5 is a late summer / fall 2011 release.

Please note that the features in this roadmap are not commitments! They may or may not end up in a final release. If a feature isn’t ready in time it will not be included in the release.

Multithreaded renderer

We will be moving most of the rendering workload and driver overhead away from the main Unity thread and onto another CPU core. This is an ongoing project that is currently working on the PC but we plan to make it available on all multicore platforms, from desktop to mobiles. Plus, we’re going for wider multicore utilization (using as many CPUs as there are) for tasks like culling and particle systems. How much of this is ready for 3.5 and on which platforms is still an open question, but we can say that the performance gains look very promising!

Pathfinding

Unity will automatically generate navigation meshes from your level geometry.
Beautiful, natural-looking crowd simulation using RVO and PLE algorithms wrapped in a simple API. Agents can find paths to target locations with built-in crowd simulation, or can be moved directly on the NavMesh in a similar way to the character controller.

New particle system

We re-wrote our particle system from scratch. The new particle system is completely curve and gradient driven, and is composed of modular blocks to boost functionality. Also, it utilizes multicore CPUs on all platforms!

UI framework

We’re rewriting the in-game GUI system from the ground. We’ve made it simple and intuitive to create modern game interfaces with tons of animations and other effects. Everything is assembled in a visual GUI editor. A lot of effort is going into optimizing the GUI system for minimizing run-time overhead through automatic texture atlases and aggressive coverage-based batching.

Light probes for character lighting

Light probes are an advanced technique for lighting dynamic objects and characters with high-quality baked lighting. We capture incoming direct and bounced lighting within a scene at a number of points (light probes). As a character moves through the scene, nearby probes are picked, interpolated, and the result is then passed to the shader to light the surface. It’s a hard problem to do all this efficiently but thanks to our tetrahedra-based space division, the technique is extremely fast even on mobiles and has a very low memory footprint. For more details check out the video and blog post.

RNM lightmaps

To add more flexibility to our lightmapping solution we’re adding the option to bake directional lightmaps (radiosity normal maps and similar schemes). That will also enable bump and specular effects on surfaces lit by indirect light only.

LOD support

Built-in Level Of Detail support. LODs are currently authored manually in your favorite modelling tool but we’re also experimenting with automatic LOD generation techniques.

Intuitive editor tools for setting and inspecting LODs are included as well as integration into the pipeline to automatically create LODs based on naming conventions. We’re also offering support for fading level of detail transitions using screen-space dithering. Get more information in this blog post.

Integrated Perforce and Subversion version control

We’re working on fully integrated version control support for both Perforce and Subversion. There’s a complete UI including support for file locking.

Text-based scene/prefab/… format

Unity will now write all data in a text-based file format for scenes, prefabs, materials and other binary files in your project folder. The format is based on YAML and is optimized for being easy to merge. Multiple team members can work on a scene at the same time and merge the resulting changes afterwards.

Prefabs

The prefab system has been rewritten. It allows you to add and remove components without breaking prefab connections. Materials can be instantiated with the prefab instance. This paves the way for nested prefabs.

Profile & allocator improvements

A new allocator framework helps us reduce memory usage and fragmentation and improve performance. Now there’s a much better memory overview in Unity’s Profiler.

GameCenter and social APIs

We are working on a pluggable social API with backends for Facebook and Apple Game Center.
Companies like OpenFeint or publishers with custom social platforms can easily create their own implementation. This makes it easier to port games between platforms.

Audio

We are working on low latency audio buffer access. This will enable you to write your own filters, effects or make the audio data precisely affect your application or let your application dynamically mix and procedurally generate audio samples.

Microphone support will also be introduced across all platforms. Microphone input can be accessed transparently as an AudioClip.

WebCam support

We’re adding support for streaming video from cameras or other input devices into a texture to allow you to develop augmented reality games, or for uploading pictures for integration with social networks or other online services. This was implemented at our last NinjaCamp week.

Umbra sPVS rewrite

Umbra’s sPVS occlusion culling system has been rewritten from scratch. The algorithm now guarantees conservative PVS results and baking PVS is around 10x faster.

And loads more!

As usual, we fully expect Unity 3.5 to deliver tons of other small features, improvements and fixes.

More future features that we’re currently working on. They don’t have a specific release yet

Again, the fact that we are working on it is not a promise that it will ship in a matter of weeks. We just want you to know what we’re trying to do. Some plans might change!

Flash export support

As announced, we are hard at work to add support for building a Unity project that can be played back by a browser equipped with the Flash “Molehill” plugin. We’ll bring as many Unity features to the Flash Player as we can, and aim to be the very best tool available for people who want to target the 3D functionality in the new Flash Player.

Cache server

Everyone loves Unity’s completely automatic asset pipeline and the ability to quickly modify any asset in your project folder without jumping through hoops.

But when working in larger teams, everyone has to import the same assets again and again. If it could only be 3000x faster to import all assets… We have a solution for that. Early prototypes show that we can import a project folder with 1GB of assets in 9 seconds.

HDR & gamma correct rendering

Built-in HDR, proper linear space lighting. Making the pipeline, the shaders and the render targets work together to produce the output that artists anticipated. It’s a tricky area to get right across all platforms – which is why we want to solve it for you!

Texture streaming

We’ve been working on a texture streaming solution. Unity will load the textures at the necessary resolution just before it needs it. You have a texture memory budget which Unity will fill with the most important textures necessary. Unity automatically analyzes your scene but you can also manually specify the needed textures & resolutions at specific locations in your game.

This means you can have more textures at a higher resolution, especially on mobile devices and consoles. Unity automatically analyzes your scene to allow for prefetching of textures. Even on iOS we’re able to stream textures in the background at 60FPS.

Audio improvements

FMOD designer support: Import FMOD designer banks (.FSB) and event files (.FEV) and access them as standard audio clips.

Audio DSP graph: Get full access to the mixer engine and create custom routing and advanced signal chains either from a visual node editor or through a simple API.

Dynamic mixing: Mixing audio seems to be the big issue in today’s audio field. We’re working on a dynamic mixing solution that lets you group audio sources and mix them, apply effects, modulations and save these settings as snapshots. You can trigger the snapshots from script or from animations at any time. This makes it easy to duck audio and precisely control the audio levels at all times.

This is only part of what we are working on. We’re also developing more features that are much further away from completion. So stay tuned!

Focusing intensively on creating their technology for use with Unity, String have been working with a number of respected Unity developers to create showcase material as they have worked through an intensive beta stage over the past year.

At today’s Augmented Reality Summit, String will unveil some of their latest developments that go far beyond what they have teased so far. You can watch the String presentation via the following Stream live or as an edited version once their talk has finished -

Democratising Augmented Reality

String touts one of its key selling points as being fast, stable and easy to use, and they are keen to remind Unity developers that they aim to bring a formerly somewhat inaccessible technology to a new audience of developers thanks to their easy to use toolset. Time will tell how you Unity developers take them up on this but I for one can’t wait to see what you all come up with! Demonstrations so far have been impressive and with further super-secret stuff being unveiled at the Summit, the power of String has yet to be seen.

In a press release combined with today’s launch, Alan Maxwell, CEO and founder states “We are delighted to officially launch String™ to the world. We’d like to thank everyone for their support and interest. There’s been huge anticipation from both the global development community and international brands. We’re very excited to finally unleash String™, and to be working closely with our partners to drive innovation. We can’t wait to see the ideas that emerge, and we are working hard to develop the technology even further, so watch this space.”

Dear Unity iOS Developers,

Unfortunately, many (and probably all) Unity iOS applications built with iOS SDK 4.3 are crashing during the App Store Review process while still running successfully on developer’s devices. We have contacted Apple regarding this issue and received confirmation that this is of highest priority to them. Our iOS team is working on a solution as well, but due to complex nature of the problem it will take longer than expected to properly resolve. A currently known workaround is to keep using iOS SDK 4.2.

Many users reported that applications built with Xcode 3.2.5 + iOS SDK 4.2 successfully pass the Apple App Store review process currently. OS SDK 4.2 is not publicly available on the iOS Developer site anymore, but it still can be downloaded via direct link. We want to assure you that building final applications with iOS SDK 4.2 provides all the features the Unity iOS run-time supports and is proven to work fine with devices running older generation iOS (3.x-4.2.x) as well as the newer devices running iOS 4.3.x (like iPad 2).

Please feel free to contact us if you have issues releasing your application to the App Store.

Regards,
The Unity Team

Since then, we have spent many hours listening to your stories in forums, analyzing your builds, and trying out some ideas. We finally nailed the issue: iOS SDK 4.3 introduced a tiny problem with the native code linker improperly calculating how much code should be protected by the AppStore code protection system. The problem exposes itself only when AppStore protection is applied to the application.

Recently, a few forum users reported about successful submissions to the AppStore using iOS SDK 4.3. This led us to the solution (we would like to say big thanks to forum users “susantio” and “ratrodstudio”!). Our investigation of their projects revealed common use of the special linker flag “-all_load” (which is required by some 3rd party ObjC plugins). Using this flag forces iOS SDK 4.3 native linker to properly calculate protected code size and so it solves the problem.

Unity 3.4, which is just around the corner, will include this flag by default. If you can’t wait, you can try it sooner by applying few changes to your Xcode project by hand.

Instructions how to add this flag to your release build when using Xcode 3.2.6 (SDK 4.3):

1. Open your project in Xcode.
2. In the Xcode menu select Project->Edit Active Target.
3. In the Configuration drop down select “Release”.
4. In the Search field type “linker”.
5. Find the field named “Other Linker Flags” and double click on it.

6. Click “+” and add “-all_load”.

7. Clean all targets.

Instructions how to add this flag to your release build when using Xcode 4/4.0.2 (SDK 4.3):

1. Open your project in Xcode.
2. In the Project Navigator click on your project.
3. On the next pane select “Unity-iPhone” under TARGETS.
4. On the next pane select “Build Settings”.
5. In the Search field type “linker”.
6. Find the field named “Other Linker Flags” and double click on “Release” configuration near it.

7. Click “+” and add “-all_load”.

8. Clean all targets.
9. Make a distribution build by clicking “Product”->”Build For”->”Build For Archiving” (Note: don’t use Product->Build, because it will make “debug” build by default and won’t include “-all_load” flag).

We have received multiple confirmations from forum users that this helped them get into AppStore using iOS SDK 4.3. Also we are sharing all our findings with Apple, and we hope that this will help to get some fix included into SDK update.

As always please feel free to contact us if you have issues releasing your application to the AppStore or any platform.

We plan to release light probes with Unity 3.5; all the other effects can already be achieved in Unity!

But is it secure?

“Bububut, waitaminnit! Native code is not secure by definition” you say. Turns out, that isn’t necessarily true. With a specially massaged compiler, some runtime support and careful native code validation it is possible to ensure native code, when ran in the browser, can’t cause harm to user’s machine. I suggest taking a look at the original NaCl for x86 paper and more recently, how similar techniques would apply to ARM CPUs.

But what can you do with it?

So that’s great. It means it is possible to take C/C++ code, compile it with NaCl SDK (a gcc derived toolchain) and have it run in the browser. We can make a loop in C that multiplies a ton of floating point numbers, and it will run at native speed. That’s wonderful, except you can’t really do much interesting stuff with your own C code in isolation…

You need access to the hardware and/or OS. As game developers, we need pixels to appear on the screen. Preferably lots of them, with the help of something like a GPU. Audio waves to come out of the speakers. Mouse moves and keyboard presses to translate to some fancy actions. Post a high score to the internets. And so on.

NaCl surely can’t just allow my C code to call Direct3DCreate9 and run with it, while keeping the promise of “it’s secure”? Or a more extreme case, FILE* f = fopen("/etc/passwd", "rt");?!

And that’s true; NaCl does not allow you to use completely arbitrary APIs. It has it’s own set of APIs to interface with “the system”.

Ok, how do I interface with the system?

…and that’s where the current state of NaCl gets a bit confusing.

Initially Google developed an improved “browser plugin model” and called it Pepper. This Pepper thing would then take care of actually putting your code into the browser. Starting it up, tearing it down, controlling repaints, processing events and so on. But then apparently they realized that building on top of a decade-old Netscape plugin API (NPAPI) isn’t going to really work, so they developed Pepper2 or PPAPI (Pepper Plugin API) which ditches NPAPI completely. To write a native client plugin, you only interface with PPAPI.

So some of the pages on the internets reference the “old API” (which is gone as far as I can see), and some others reference the new one. It does not help that Native Client’s own documentation are scattered around in Chromium, NaCl, NaCl SDK and PPAPI sites. Seriously, it’s a mess, with seemingly no high level, up to date “introduction” page that tells what exactly PPAPI can and can’t do. Edit: I’m told that the definitive entry point to NaCl right now is this page: http://code.google.com/chrome/nativeclient/ which clears up some mess.

Here’s what I think it can do

Note: we have an in-progress Unity NaCl port using this PPAPI. However, I am not working on it, so my knowledge may or may not be true. Take everything with a grain of NaCl

Most of things below found by poking around at PPAPI source tree, and by looking into Unity’s NaCl platform dependent bits.

Graphics

PPAPI provides an OpenGL ES 2.0 implementation for your 3D needs. You need to setup the context and initial surfaces via PPAPI (ppapi/cpp/dev/context_3d_dev.h, ppapi/cpp/dev/surface_3d_dev.h) – similar to what you’d use EGL on other platforms for – and beyond that you just include GLES2/gl2.h, GLES2/gl2ext.h and call ye olde GLES2.0 functions.

Behind the scenes, all your GLES2.0 calls will be put into a command buffer and transferred to actual “3D server” process for consuming them. Chrome splits up itself into various processes like that for security reasons — so that each process has the minimum set of privileges, and a crash or a security exploit in one of them can’t easily transfer over to other parts of the browser.

Audio

For audio needs, PPAPI provides a simple buffer based API in ppapi/cpp/audio_config.h and ppapi/cpp/audio.h. Your own callback will be called whenever audio buffer needs to be filled with new samples. That means you do all sound mixing yourself and just fill in the final buffer.

Input

Your plugin instance (subclass of pp::Instance) will get input events via HandleInputEvent virtual function override. Each event is a simple PPInputEvent struct and can represent keyboard & mouse. No support for gamepads or touch input so far, it seems.

Other stuff

Doing WWW requests is possible via ppapi/cpp/url_loader.h and friends.

Timer & time queries via ppapi/cpp/core.h (e.g. pp::Module::Get()->core()->CallOnMainThread(...)).

And, well, a bunch of other stuff is there, like ability to rasterize blocks of text into bitmaps, pop up file selection dialogs, use the browser to decode video streams and so on. Everything – or almost everything – is there to make it possible to do games on it.

Summary

Like Chad says, it would be good to end “thou shalt only use Javascript” on the web. Javascript is a very nice language – especially considering how it came into existence – but forcing it on everyone is quite silly. And no matter how hard V8/JägerMonkey/Nitro folks are trying, it is very, very hard to beat performance of a simple, static, compiled language (like C) that has direct access to memory and the programmer is in almost full control of both the code flow and the memory layout. Steve rightly points out that even if for some tasks a super-optimized Javascript engine will approach the speed of C, it will burn much more energy to do so — a very important aspect in the increasingly mobile world.

Native Client does give some hope that there will be a way to run native code, at native speeds, in the browser, without compromising on security. Let it happen.

At the end of the week it could do this however:

This is our Bootcamp demo, running in D3D11. So lots of the stuff is working: meshes, textures, shaders, shadows, deferred lighting, Image Effects, particles, skinned meshes, terrain and so on. For the reference, Bootcamp running on DX9:

As you can see, some of the stuff is not working on D3D11 yet. Fog is not working; there’s some lighting difference on grass. Some other things are not working, like fixed function shaders (VertexLit ones or any shaders that use SetTexture) but you can’t see much of those in Bootcamp.

Awesome? Yes and no.

For basically a week of work, I’d like to think this is very good progress.

Is our D3D11 renderer teh awsum yet? No. Currently it’s running slower than D3D9, and does not implement all the features of D3D9 one either (fog, fixed function etc.). And I haven’t even started exposing D3D11 specific things like Compute Shaders, Shader Model 4/5, Tessellation etc. And there are some unsolved workflow issues, for example: when someone is making a game on a Mac, how would we compile shaders for D3D11 renderer? With D3D9 we can do it because NVIDIA’s Cg compiler works both on Windows and Mac, but no such luck with D3D11 shader compiler…

So this is not shipping quite yet. Performance is not great at the moment – which is to be expected. D3D11 potentially can be faster than D3D9, but the path of getting there is not an easy one. We also need to actually expose compute shaders, tessellation and other goodies. And then think about how/if equivalent features would work on other platforms like Macs (DirectCompute on Windows, OpenCL on Mac? etc.).

But, so far it’s promising! Stay tuned, maybe someday we’ll ship this

The idea behind this project is to make use of the Webkit integration that was used for the Asset Store in order to give easy access to learning resources, news and more.

We still have a few more NinjaCamp tricks up our ninja sleeves so keep an eye on the blog.

For our NinjaCamp project, Levi, Vytautas, and I (Na’Tosha) decided to pursue our passion for GNU/Linux — we thought we would invest our time into getting a web player up and running on an Ubuntu workstation.  It’s turned out to be quite the endeavor, but, after a few days of poring through the Mozilla Developer’s Reference, the OpenGL documentation, the X11 documentation, and countless stacktraces (not to mention pouring ourselves dozens of caffeinated beverages), we do have something to show for our efforts:

Our Demo shown at GDC running in Firefox 4.0 on Ubuntu 10.10.

Despite the fact that Firefox 4.0 has not been released yet, we chose to use 4.0 and leverage some goodies from the new API.

It’s completely unpolished – we can’t even reload the unity engine in the same browser instance, and it of course lacks niceties like a splash screen, etc.  Although it is just a demonstration that we put together in a week, and it is not an official Unity project, all in all, we’re quite proud of ourselves.

About the Game:
The game is a 2.5D adventure game called “The Adventures of Steve.” Steve is just a casual guy who has stumbled upon a temple which has some evil traps set for him. His only wish now is to get out so that his life can return to normal.

We’re adding a context menu item in the asset window to “Filter References in Scene”. Selecting it will apply a filter to your hierarchy window to find all GameObjects or their children that reference the selected asset.

Alternatively the filter can be specified manually by using the “ref:ASSET PATH” syntax.

With two days of NinjaCamp to go we expect to finish the “Filter References in Project” option too. It will help you find other assets (prefabs, scenes) that use the selected asset.

Take care, Uniteers!

As our NinjaCamp project Bas and I decided on a cause a bit humbler than many of the other projects going on here: We just want to improve the workflow of creating a new script in Unity.

The current way to make a new behaviour for a GameObject in Unity is like this:

• Create the script in the desired folder.
• Rename the script.
• If it’s a C# script, rename the class to match the file name.
• Drag the script onto the GameObject.

With the solution we’re working on, you can instead just choose “New Script” from the Components menu, and you’ll get this:

This is a work in progress, but much of the base functionality is already there. While the window is open (which will float on top) you can optionally click any GameObject or Prefab to make the script be attached to that, and you can click any folder in the Project view to save the script in that folder. You can also pick which of the built-in callback functions you want included from the beginning (we only have four right now but we’ll add the others as well).

When you click “Create and Attach” the script will be created with the right file name and class name, compiled, and then added to your selected GameObject or Prefab if you chose one.

We’re also adding this partially related button:

 
The idea here is to just make it more obvious and simpler how to add a component to a GameObject – no need to reach for that menu anymore. And no, the button is not part of the AudioSource component, it’s below it and is still missing some style work and a separator line above it. It’s a work in progress!

We’re still missing more work on the script template building options, but I can already see that this thing will save me time in the future, if nothing else.

So, what are we working on? We started the day by compiling a preliminary list of projects and forming teams. Naturally this list could change, new projects could form, and projects could evolve. It is important to remember that this week is experimental — a weeklong extension of Unity’s “Fridays are For Fun” process — some projects will end up in the future versions of Unity… and some will crash and burn.

• Cheap colliding particles on the GPU
• Webkit-based welcome screen
• One-click web publishing
• Collaborative editing
• DirectX 11
• Vertex Painting
• Install Analytics
• Multithreaded Renderer
• NVIDIA Performance Profiling Extensions
• PhysX 3
• AI Sandbox
• Web camera support
• New Script dialog
• New terrain engine
• Supporting any .NET compiler
• Scene creation tools
• Assets Store game project
• Timeline editor
• Dynamic mixing of sounds based on dB
• Blendshape implementation

For more information during the week, head to unity3d.com/NinjaCamp, follow the #NinjaCamp hashtag on Twitter or check out updates on our Facebook page.

The Basics

The problem we are trying to solve is how to use baked lighting on dynamic objects and characters. After lightmapping a scene all static objects have nice, high quality lighting. If we don’t do anything about the dynamic objects though, they might look dull and detached from the environment with their direct light and ambient only.

One solution is to use light probes to sample the nice baked lighting at various points in the scene. We can then interpolate the nearby probes to guess what would the lighting be at the current location of our character (or other moving object) and use the result to light the character.

Let’s see how it looks like in action! (Apologies for the cheesy lighting with over the top light bounce, but it makes it easier to illustrate the effect)

The light probes can be used to store the full incoming lighting or just the indirect lighting (plus full lighting from emissive materials and ‘baked only’ lights), i.e. the Dual Lightmaps style. Either way it’s quite flexible how we can then use the probe in the shader: do full lighting per vertex, per pixel with normal mapping or even per vertex indirect light blended with per pixel direct light with normal mapping.

To use the light probes, you need to add them to your scene, bake and voilà - all dynamic renderers with the feature enabled use light probe lighting, both in edit and play mode.

I haven’t decided yet how will placing of the probes in the scene work, as it ties in with what interpolation technique I’ll use. Probably the probes will either be placed automatically (with some global control from the user’s side) or manually as it has been done in this demo. If I go for the latter, I’ll make sure to add some utility functions to pre-place the probes over a navigation mesh, expose probe placing to scripting and possibly allow probe locations to be part of prefabs – everything to keep the manual process painless while still giving a lot of control.

You can be sure this feature will be released as soon as it’s ready and not later. I don’t know when that might be, though For now light probes remain my FAFF project while I’m focusing on a bigger feature, which should make a lot of you happy as well.

The Details

Light Probes and Spherical Harmonics

To bake a light probe, we need the amount of light incoming from every possible direction – and that’s a lot of directions! But – we also know that most likely the incoming light doesn’t change that quickly between different directions. In other words it doesn’t have high frequency changes, so if we compress that data in the frequency domain on a sphere by discarding all the higher frequencies – no one should notice.

Storing the incoming light using Spherical Harmonics achieves just that. Spherical harmonics basis functions can be thought of as an equivalent of harmonics in Fourier analysis on a sphere. The more bands (groups of basis functions) we decide to take into account, the more accurately we’ll be able to reconstruct the original incoming light signal. Beast can bake light probes directly as spherical harmonics coefficients, which tell us “how much” of each of the basis functions our signal did contain. The original function describing how much light comes from a given direction can then be reconstructed as just a linear combination of the coefficients and the basis functions.

Let’s look at an example. We could ask Beast to bake one light probe for us for a given location. That light probe would just be a bunch of SH coefficients – if we chose that 3 bands are enough, that would require storing a coefficient for each of the 9 basis functions for each of the 3 color channels, so a total of 27 floats. If then a dynamic object would end up in the exact same location as the light probe, we could say – hey, we know what’s the incoming light at that position. In the vertex shader (or pixel shader, if we wanted more precision and normal mapping) we could then decode the SH coefficients for a given direction dictated by the object’s normal and light our dynamic object with the light probe that way.

The real problem: placement and interpolation

That brings us to the real problem: how do we decide where to place the probes in the scene? And how do we interpolate the probes’ values once we have a bunch of probe locations and an object sitting somewhere in between?

The useful property of spherical harmonics encoded probes is that a linear interpolation between two probes would just be a linear interpolation of their coefficients. So if we had all the probes placed along a path and our object was moving along that path (racing game, anyone?), we would just linearly interpolate the two probes at the ends of the current path segment to find the lighting.

At the same time we have to think where do we need the light probes to be located. Surely we only want them where our dynamic objects can go – no point in baking and storing probes which will never be used. Also we want the probes to encode interesting changes in lighting, but we don’t want extra probes where the lighting changes slowly or the change is something our lighting artist doesn’t care about in this spot.

At this point I should probably list the properties I would like the interpolation function to have, but they’re actually quite intuitive. Let me just emphasise the most important one: if there’s a probe at the location we’re evaluating the function for, it should return a weight of 1 for that probe and weights of 0 for all the others. This is another way of saying: light probes sample the underlying lighting information, so there’s no need for guessing there – we know what’s the lighting at those exact points.

Here’s a couple of possible solutions:

Uniform grid. The entire scene is put into a bounding box which is then subdivided to an artist-defined density and a probe is placed at each cell’s corner. This approach doesn’t require much interaction from the user and the interpolation is simple, robust and relatively cheap (it’s just a trilinear interpolation of the probes at the cell’s corner and it’s easy to find the right cell). The downside is that you often have to dial up the density quite a bit to capture that light you care about in just one spot, which makes a lot of the probes filling the major part of the volume completely useless – and that wastes a lot of memory. Also you will get into situations when there’s a row of probes close to the wall and a row of probes just in the wall or on the other side of it (so e.g. much darker): your character approaches the wall and suddenly the darkness starts to creep in although it shouldn’t. The way this has been solved for Milo and Kate and at least one other current title I know about is that each probe encodes additional visibility data which limits it’s influence up to the nearest obstacle. This however adds to the memory footprint and interpolation time. It also might introduce artefacts on it’s own if the grid is not fine enough.

Adaptively subdivided grid. It’s a concept similar to the one above, except that probe density can vary where needed. The structure could be an octree, in which we keep subdividing cells if we expect changes in lighting that need capturing. A good heuristic for doing so might be testing if current cell contains scene geometry – if it does, there’s a better chance of higher-frequency changes in the lighting. After the probes have been baked there’s also the possibility of clustering similar probes. This approach should solve the “memory monster” issue of the uniform grid, but at a cost of slightly more complex and branchy search and interpolation code. It still needs to store visibility information like the previous solution and the subdivision heuristic might be wrong.

K nearest probes. With this approach we just search for K nearest probes and interpolate between them. This time probes don’t need to be placed on a grid – we can put them anywhere. The biggest issue here is that the set of probes used for interpolation can change suddenly at any time – even when the just-excluded and just-included probes had high interpolation weights, resulting in visible light popping. To minimise this effect, we can employ some damping – interpolate from the old value to the new over time. The delay will be visible in some cases, but still better than a sudden pop of lighting.

Tetrahedralisation. Once the probes have been placed, we can find the Delaunay tetrahedralisation of such point set. To find the interpolated probe for our current location, we first search for the containing tetrahedron and then calculate barycentric coordinates which can be used as interpolation weights for the four vertices of the tetrahedron. Finding the containing tetrahedron can be done efficiently by always starting to test the last one we were in. If the test fails (it usually won’t), we find the tetrahedron’s normal most accurately pointing towards our location (highest dot product) and move to the tetrahedron adjacent in that direction.
The first two solutions can be made fully automatic and that’s definitely an advantage. On the other hand somehow I can’t accept the fact that we won’t have more direct control over which areas are important to sample and which aren’t, which will lead to over-sampling and wasting memory in some areas and under-sampling and loosing information in other areas at the same time.

The other two solutions have the advantage of giving us control over where the probes are placed. That might become a problem, though, as when the level geometry changes, manual work has to be re-done. A couple of things could be made to improve the work flow there, like automatic pre-placing of probes over the nav mesh – and these initial positions could then be modified by hand. Also, with probe positioning exposed to scripting, developers could write scripts automatically placing probes in the areas which make sense for a given game and artist workflow, but couldn’t be generalised enough to be included in Unity. Probes could also be parented to objects to move with them (only at edit time) or made part of prefabs.

The K-nearest probes approach seems quite reasonable and it has been used in a couple of successful games. If K is low, the interpolated probe can be calculated efficiently and it’s easy to ensure the property of getting the probe’s value when at it’s exact position. The issues that still bother me is at times unexpected interpolation (K-nearest probes aren’t always the ones you would expect) and temporal damping trying to compensate popping, but sometimes introducing visible light changes when the interpolation tries to catch up even if the object doesn’t move any more.

The video above shows the first interpolation scheme I tried out: 2-nearest probes with temporal damping. I project the character’s center onto the line passing through the two nearest probes and linearly interpolate if the position falls in between or clamp if it falls outside of the segment. If one or both of the nearest probes change, I take a snapshot of the interpolated probe and lerp it out over time as the new interpolated probe lerps in. I think the results are acceptable, but that’s for you to judge. There’s a couple of moments when the character has already stopped and the light is still catching up. The speed of that interpolation can be tweaked per object and can also be controlled from script as a function of e.g. object’s current speed.

The probes in the video are baked in a similar fashion to near lightmaps in Dual Lightmaps, so they exclude direct lighting from Auto lights, but they do include their indirect lighting contribution and also full contribution from Baked Only lights and emissive materials (like the green puddle of goo by the barrel). Their contribution is calculated per vertex, while real-time direct light is calculated per pixel with a normal-mapped specular material. All this is handled internally by the surface shader framework, so the shader on the character is just the built-in bump specular.

Next I will probably try out the Delaunay tetrahedralisation approach. I’m having high hopes for that one, as it seems it should result in interpolation closer to what we intuitively expect while retaining the fine-grained control. Also memory consumption and search and interpolation performance should be on par with K-nearest probes and adaptively subdivided grid, but I should probably test some actual implementations on real-world scenes before getting too attached to those claims. The biggest worry here is that Delaunay tetrahedralisation is at best tricky if the input data forms degenerated patterns (e.g. all points along a line) and it might still create long and thin tetrahedra, especially at the hull surface.

One option worth investigating here is that if we discover all points are roughly co-planar (or at least don’t form more than one layer), the entire problem can be brought down to Delaunay triangulation in 2D and interpolation in 2D as well.

This is it for now. It would be good to hear your suggestions on the topic, so feel free to comment

We are very happy to announce that Unity Android and Unity Android Pro are now available!

Head here to download a trial and read on for extra info on what is included.

Naturally, Android fits straight into the editor like all the other platforms, so its incredibly simple to take your existing games and port them directly over to the new build target. Exactly like the iOS remote, we also have Android remote, which lets you test out your game on the fly.

We have also been working closely with the various android hardware manufacturers to ensure we get lightning fast performance in all areas.

Its also worth noting that since we released the preview version of Android Pro, we’ve already had developers working on nearly 50 real-world projects and seen great successes for guys like Madfinger games with Samurai II: Vengeance.

We are also keeping the same pricing model that we have with iOS. So Unity Android is $400 and the Unity Android Pro is $1500.

Finally, You can get hold of an Android Pro license for free! We are running a competition to give away 4 Android Pro licenses, In order to get hold of them, either become a fan of the Unity Page on facebook or follow us on twitter. Then make a comment on facebook or re-tweet the launch announcement with a sentence to explain why you thing the license should be yours. Read more about the contest here.

These are exciting times. Today, at the Flash Gaming Summit in San Francisco (of which we’re proud Gold Sponsors), Adobe has announced the public availability of a beta version of the Flash Player, codenamed Molehill, that has a very interesting new feature: hardware accelerated 3D support.

Molehill exposes a very low-level shader-based interface to the graphics hardware. Adobe has decided to focus on that low-level part, and do that really well. The molehill pre-release will not be shipping with a 3D engine, scene building tools, model and animation importers / exporters, physics, lighting or lightmap creation tools, etc.

Hmmm….does that list sound familiar? It sounds a lot like what you all love Unity for!

In the past few months, our engineers have been investigating the possibility of adding a Flash Player exporting option to Unity. That investigation has gone very well, and we’re moving into full production.

For Unity users, this no doubt spurs a lot of questions. Questions such as:

• Will Unity on Flash support the full Unity feature set?
• When will it be ready?
• Okay, when will a beta be ready?
• What will it cost?
• Will it do A, B or C?

These, and many other questions, we cannot answer just yet.  We can say that it will be as good as we can make it and we’ll do it as fast as we can do it.

We do however have some concrete answers for you now that shouldn’t wait…

Q. Is this the end of the Unity’s own Web Player?

Absolutely not. The Flash and Unity Web Players both have their strengths.  We’re excited by the opportunity to target the Flash Player and all of its features with Unity, but there will be plenty of experiences that the Unity plugin is better suited for. It will be up to developers in the end, to decide whether they want to target only the Flash Player, only the Unity Web Player, or some combination of the two (now things are getting interesting!)

Q. What programming language will I use?

You’ll have two options:

1. For people with a Flash background:
   Target our ActionScript API directly from Flash. Think:
   var go:GameObject = new GameObject(“Just normal ActionScript 3 code”);
2. For people with a Unity background:
   Script your content in C# / JavaScript / Boo, like you’re used to, and have Unity automatically translate it to ActionScript when you hit publish.

This is an important development for us, and we hope you’re as excited as we are to see your content reach further than ever.

We are so happy to announce that Unity 3.2 is now live and available to download!

Here is a rundown of the major new features and improvements:

For a full list of all of the updates fixes and improvements, head over to the release notes.

Or simply go directly to the download link here and get stuck in with all the cool new stuff.