What is it?
A tool that lets you use 3d Studio Max to make great looking lighting for your game.

I’ve been making lightmaps for ages already, why would I care?
Because with this tool, you can actually layout your scenes in Unity. Previously if you wanted to use lightmaps, you’d usually layout your scenes in 3d Studio Max or Maya or some other tool, and would have had a hard time moving things around in Unity later on.

Do you have some examples for this?
Take a look at this video tutorial from Michał, going over the example project included with the tool.

Great. Do I need to prepare my assets in any way to make this work?
You need to provide lightmap texturecoordinates for all meshes that you want to have lightmapped. However each object can have its own seperate lightmap sheet. The tool will take all lightmap sheets from all specified objects in the scene, put them all into one mega lightmap sheet, export your scene to fbx, have Max import the fbx, have Max generate a lightmap, and then that lightmap gets picked up by Unity automatically.

Take a look at this more detailed screencast, which goes trough this process, and shows how to go from an empty project to a lightmapped environment.

But I don’t use max! I use …..
There’s nothing in the tool that makes the technique inherently limited to 3d Studio Max. However the tool does provide some nice extensions to Max that make the lighting baking a one click process. With a bit of effort, one could take this project, and make it work for other authoring tools.

I still have some other question
Try out the new answers.unity3d.com and get it answered!

Many thanks and congratulations from the Unity team go out to Michał for being part of the Summer of Code program. You can find more indepth info on the tool on Michal’s website.

If you want to help make Unity 2.6.0 a flawless release, there are two simple things you can do.

1) Auto-update to the 2.6 webplayer plugin by visiting this Auto-Update test page.
2) Go play as many webplayers as possible.  Try out lots of players old and new!

If you have any problems at all during the auto-update process or running a webplayer, we want to know about it immediately. Please post about it in a reply to this thread on the Unity forums. Include the URL of the problematic webplayer, and the OS, browser, and graphics card you’re using. We really want to fix everything so if you run into problems, don’t forget to post! And thanks!

Apple reengineered Safari to run as a full 64-bit application. While this is a good thing, it has a pretty big impact on plugin developers like us. Even though plugins do not actually need to be 64-bit binaries themselves, since they are now running as separate processes, they need to communicate with Safari using new 64-bit capable APIs. Basically, the old Carbon-based NPAPI is being replaced with a Cocoa-based version, which requires a lot of restructuring of plugin code.

Unfortunately, this change sort of caught us by surprise – the APIs which are now required have just been publically released in Safari 4.0, and are now being made mandatory to use in Snow Leopard less than three months later. Which now means that we won’t be able to ship a working web plugin for 64-bit by it’s release date this friday. We are working on it as hard as we can, and we do have a working proof of concept of Unity web content displaying in 64-bit Safari. We aim to release an updated plugin in October.

Until then, there are two possibly ways to play Unity web content on Snow Leopard: One is to use Firefox, which still works as always. The other one is to set up Safari to run in 32-bit mode. To do that, click Safari in the Finder, select Get Info from the context menu, and click on Open in 32-bit mode.

When users open web pages with Unity content in 64-bit Safari, all they will see is a blank screen where the content should be. However, it is possible to detect this situation from JavaScript, so you can at least display a meaningful error message on your site. When the plugin fails to load, the GetPluginVersion() function is undefined. Here’s some sample code, showing how to use that to display an error message:


if (navigator.appVersion.indexOf("Safari") != -1
&& navigator.appVersion.indexOf("Mac OS X 10_6") != -1
&& document.getElementById("UnityEmbed").GetPluginVersion == undefined)
{
document.write('<br>You are running Safari in 64-bit mode, which is not yet supported by ')
document.write('the Unity web plugin.<br>');
document.write('To see the content, switch Safari to 32-bit mode, or use Firefox. <br>');
document.write('See <a href="http://blogs.unity3d.com/?p=1358">this blog post</a>');
document.write(' for more information. <br>');
}


If you are using our default html template, you can just add this code after the line document.write(”);.

We apologize for any inconveniences this causes, and, as always, we will try to resolve the issue ASAP. Looking forward, though, moving to these new APIs will make the Unity web experience a better one, as this allows us to do more robust input handling, and proper layering of Unity content with other parts of your web site.

Oh, and before anyone asks: The Unity editor as well as standalone games made with Unity are unaffected by this issue.

We’re just 9 days away from the August 31 deadline so it’s time for an update. I’ve been working on Detonator, which is a parametric explosion system. It’s supposed to make getting nice, scalable explosions into your game really easy while at the same time providing a framework for more complex effects.

The good news is that it’s almost done, and that means a ton of changes since the first concept Unity players that I posted on my blog. The main effort has been towards making Detonator entirely code driven. This involved creating a new particle component (DetonatorBurstEmitter) that calls some of the scriptable functions on the standard Unity particle system, but makes one shot emissions and the other sort of scaling effects easier to create. The Unity particle system is surprisingly powerful and is similar to the rest of Unity… if there’s something you can’t do through the UI, you likely can through scripting.

So, what about actually using it? The simplest use case is to take a GameObject, attach a Detonator component to it (in code or in the Inspector), and either call Explode() in code or check the “Explode on Start” checkbox in the Inspector. That will do a whole bunch of stuff… create all kinds of emitters, a light, a force, all corresponding default materials, and then BOOM, you’re exploding. That usage case was a primary design goal and it’s met.

If you want to take it one step further, you can tweak parameters on the Detonator component. The default explosion has a 10m radius, and that can be changed to whatever you’d like – all effects scale accordingly. As anyone that works with particle systems knows, this is not a trivial thing because it needs to change particle size, emitter radius, velocity, emitter position, and forces all in unison.

Performance scalability is also a concern with effects, because, well, they can scale. For that there’s the detail parameter, which affects the number of particles spawned, and even whether or not certain entire sub-components get created. Each piece has a detailThreshold parameter that lets you customize how your Detonator explosion scales to different performance specs. I’ll be looking into how this will hook into the global Unity quality settings as well – no promises for release but I’ll get it in shortly after if it doesn’t make it then.

After detail there’s color. Changing the color of the main Detonator component will have differing effect depending on its alpha value. Since using alpha purely for transparency didn’t make a lot of sense in this context, it instead serves as the color influence. So if you make your color Blue with 50% alpha, then colors of all sub-components will be 50% blended to that blue. Since the normal fireball is orange and other parts are white, this gives a nice non-uniform coloration. If you’d like to go for a stylized look, crank the alpha to 100%.

Duration can also be adjusted. This was tricky because just altering this naively made the explosions really dim, so the alpha values of all the emitters’ color animations try to stay more opaque when the duration is shorter. Everything is tuned to make changing parameters make sense. Of course, we’ll learn a ton more when people are using this en masse, but I’ve given it my best shot to start with.

So that is the main Detonator component. Many people will just use that, but underneath is a full-fledged explosion construction kit. For instance, DetonatorFireball is one of the sub components that a Detonator normally auto-creates. Instead, you can make your own by dragging a DetonatorFireball script onto that same GameObject. You can add one, two, or ten of these and then get busy changing their relative positions, sizes, colors. You can even time when they go off (with randomness) to create startling layered effects. Then add some sparks, smoke, a glow, a light, or whatever you want. In just a few minutes I was able to make a pretty nice mushroom cloud. I can’t want to see what people do with this.

And for the artists out there like myself, you can switch out the materials and textures that your Detonator components use. Either replace them at the top level and let them cascade down to subcomponents, or replace them piece by piece, it’s up to you. I’d really like to see what is possible with stylized or toon explosions with this system.

So what needs to still be done? I still need to reimplement a few components that were in the concept effect… namely the chunk emitter (which sprays any gameobject you’d like with trailing smoke) and the physics force (which acts on rigidbodies and even sets them on fire if you want). The UI of the main Detonator could use some spicing up, but that would mean reimplementing material slots through the drag and drop API, which might not be worth it at this stage. The main thing the UI would do is put buttons in to create each subcomponent so one wouldn’t need to manually drag scripts onto it. It feels like that would add a nice level of polish so I’ll have a look.

If you’d like to follow along more closely and see past progress, including a Unity player with the concept effect, check my site at http://variancetheory.com.

What’s lightmapping?

If you’re not familiar with the terms “baking” and “lightmapping” then let me introduce them to you a little. Baking is an operation of prerendering expensive details (in calculational sense) like illuminated lightning, highlights and shadows into a texture so that it doesn’t have to be renderered at realtime. It requires some additional effort from the game designers, but it benefits hugely in performance. This solution is pretty old, but according to words of John Carmack it’s still up-to-date and will be – even in high end games.

What is the Lightmapping Tool?
It’s a tool for lightmapping scenes in external applications (yeah, I know most of you would  wish to see an integrated system, but it’s not that easy to write this kind of system; however there are several huge benefits from using an external one, especially as powerful one as VRay).
As you may have heard before, my job is to wire lightmapping process tightly with 3dsmax and VRay. The system automates the process of both external baking, and setting up the lightmaps in Unity.
Lightmapping tool manages up to 99 lightmap atlases (could be even more but the interface would have to be modded for such extreme jobs) which hold object information with resolution proportional to their size on the stage. It can start external applications (currently only 3dsmax), assign appropriate renderer or load a preset max scene which holds information about lightning and so on. I’m planning to make a short screencast video when the work is done, so you can be sure you understand everything clearly

This picture presents about 1/6 of a whole scene lightmapped with only one 2kx2k lightmap rendered with VRay on medium settings

What makes this solution different?
Many people have asked me how my tool will change the way the lightmapping is done. The answer is  quite simple – it gives you the power to decide whatever in scene will be static (and lightmapped) or not – at anytime without much pain.

Let me introduce how the workflow is looking:

1. Open a the lightmapping tool (all the previously lightmapped objects from the scene will be  already present at Lightmapping tools lists),
2. Setup export options,
3. Export to 3dsmax and make anything that’s needed to make the scene look good,
4. Max will be opened (if not opened before),
5. Setup lightning in 3dsmax and store presets with light and renderer settings using the the  additional tool Lightmapping. You’ll be able to switch between them later to render the scene,
6. Bake them with a single click.
7. Come back to Unity to see the effects of your work. No texture drag and dropping – everything is automated

How is the work going?
Most of the options you’ve seen are implemented and working, today the system hits it’s first beta day and will be given to first beta testers (by the way: if you’re interested in beta testing, please write a message to masteranza at gmail dot com).

It’s over four weeks of developing right now, and I must say that the original idea really evolved. I’ve read some feedback coming from the community  and I decided to generalize my system. Of course I stick to the guide lines (Main Goals) send to Unity team, but I try to generalize whenever is possible. Let’s look at the “Advanced” window – it was not designed to fit 3dsmax or VRay options only, but with a little effort every external tool.

What’s more, after exporting, the FBX file system waits for lightmaps to appear so, automatic setting up them is also tool independent. I will do my best to help everyone willing to extend the system in future for such tools like Blender, Maya and so on.

What’s left to do for this week:

• correct the material setting subsystem
• correct some issues with lightmap edges
• eliminate bugs
• optimize the code
• try making GUI more intuitive
• gather feedback from beta testers and make improvements
• make icons and additional graphics for both (Unity and Max) interfaces

Personal experience
Developing the system gave and still gives me a lot of satisfaction. I’ve learned a lot of things and had a chance to use things I’ve learned in school in practice. Starting from Immediate-GUI, going through the ‘normals space’, up to some deeper MaxScript insights. Although it took me almost half of my vacations [and a small eye strain ;-D] I’ve already planned a game development in Unity as soon as I get my Unity Pro license.

What I noticed during development is that Unity makes some things really easy to do and it’s not only about the Unity Engine internals, but the way things are organized here – I’m thinking about the huge community, enormous library of already written scripts and almost instant help on any problem.

I talked about developing graphics technology for small games (PDF slides). Mostly on hardware statistics, GPU features, testing and stability.

ReJ talked about low level iPhone (pre-3GS) rendering details (PDF slides). On inner workings of iPhone’s GPU, OpenGL ES drivers, command buffers, VFP assembly and so on. Some awesome tech stuff in there!

If you’re going to watch some demos from Assembly 2009, make sure to see:

• Frameranger (1st place demo). Imagine that on a big screen and a good sound system!
• The Golden Path (3rd place demo) – for something fresh.
• Muon Baryon (1st place 4 kilobyte intro) – that’s what kids do with sphere marching on the GPU these days. Everything in 4 kilobytes!

…see you at Breakpoint next year?

1. Additive-Projector (can be used to fake spotlights)

2. Blob-Shadow

3. iPhone-specific shaders

4. Default Skybox asset

5. Joystick and TouchPad scripts

6. Easy-to-use water reflection script

7. Control schemes aplenty: 2D side scroller, camera-relative, FPS, FPS w/ tilt, player-relative, tap-to-move

With the Unity iPhone 1.1. release imminent, you’ll be enjoying all of these goodies, soon!

First a tech demo video to set the context:

As can be seen, the looking behavior works regardless of which animations are playing. (One problem though is that when the two hands are holding the gun together, they are not always properly coordinated, but that’s a problem to solve another time!)

Use Cases
When two characters in a game are talking together (one of which might be a player avatar) they can look at each other to make the interaction look more sincere.

When the avatar comes near a health pack, a weapon that can be picked up, or another important item, he could look at that item. Besides looking natural, this can also make the player more attentive to the item if she hadn’t noticed it herself.

When there’s nothing of particular interest nearby, simply making the character look around at different random points in space looks much more natural than just looking straight ahead. It can also express mood – if the character looks around only at points directly in front, he is probably pretty focused, while if he looks around to the sides and behind him too, he is probably more exploratory or searching around.

Head Look Controller
In between the main things we’re working one here at Unity, we sometimes get to do some projects on the side. In order to make it simple to make a character look at any point in space without requiring extra animations, I have made a head look controller script component as such a side project:

Head Look Controller example project

Head Look Controller (script only) at Unify Community Wiki

This script can be used to make a character look towards a specified point in space, smoothly turning towards it with for example the eyes, head, upper body, or whatever is specified. Multiple ranges of bones can be specified, each with different settings for responsiveness, angle constraints etc.

In the video above the controller on the character is set up with one range of bones for the spine and one for the neck and head. Unfortunately the eyes of that character can’t turn, but that could be set up as well with an appropriately rigged character.

Segments should always be specified with the bones/transforms closest to the root specified first and the ones deeper in the skeleton specified after that.

Here’s the settings I used in for the component:

I have set the Threshold Angle Difference for the spine to 30, since the spine shouldn’t turn if the target angle (the angle between the direction towards the target and the direction straight ahead) is less than 30 degrees. The Bending Multiplier control how much the segment bends or turns compared to how big the target angle is. The segment will attempt to be no more than Max Angle Difference away from the target angle, though it won’t bend any further once it reaches the Max Bending Angle.

I set the responsiveness of the head segment higher than that of the upper body, since people tend to turn the head quicker. If segments had been specified for the eyes as well, they should have had an even higher responsiveness.

I specified the left and right arm under Non Affected Joints, so that the arms keep keep pointing in the original direction despite the bending and turning of the upper body. By setting the Effect to 0.3 I let them be affected a little bit though.

The Head Look Vector and Head Up Vector are just used for reference to know the default alignment of the head. Per default they are set to forward (0,0,1) and up (0,1,0) respectively.

The Target point that the character should look at is specified through scripting.

“Pro Tips!”
I said above that a character could look around at random points when there’s nothing else to look at. Actually, looking around at a few different points looks more natural in any case. Even when talking to a person or when having found an important object, people rarely tend to stare incessantly at the same point. Introduce more variation by looking at the main point of interest most of the time, but look away at some random points in space now and then.

And if your character supports it, don’t forget to blink once in a while! That is super-easy to do, either with a procedural script or with a traditional animation that only affects the eye-lids and which plays all the time at a higher layer than the other animations. Blinking a bit can really help make a character look less artificial, so if the eyes of a character are ever seen in your game, it’s worth spending the small amount of time it takes to implement.

Go on! Make those characters more believable!

The Locomotion System is all about making walking and running in games look better and more believable without requiring dozens of animations. The system automatically blends your keyframed or motion-captured walk and run cycles and then adjusts the movements of the bones in the legs to ensure that the feet step correctly on the ground. The Locomotion System is available for free when used in a Unity game.

Video Introduction

The best way to understand what the Locomotion System is all about is by watching a short introduction to it:

The Locomotion System was also presented at last year’s Unite conference:

Besides the Unite conference presentation, the Locomotion System was also presented at GDC 2009 in a fully packed session.

Recently it has been used in the online game Robin Hood Showdown accompanying BBC’s popular television series. The system allowed the characters in the game to run in arbitrary directions while aiming against the player, while still keeping the number of used animations down, thus helping keeping the web-player size small.

Like Unity itself, the Locomotion System has been designed to be highly flexible, while still being painless to use:

Automatic Adjustment to Uneven Terrain
You want your character to walk on hills, on stairs, over rocks and debris and other small obstacles? No problem. Need your character to face in one direction (let’s say, aiming at something) while walking in another arbitrary direction? Done; no extra work involved. The Locomotion System can automatically adjust animations made for a specific speed and direction on a plain surface to any speed, direction, and curvature, on any surface, including arbitrary steps and slopes.

Full Control of Style
Animators are experts in creating motions with specific styles and personalities. The Locomotion System uses keyframed or motion-captured animations as input and only adjusts them minimally to move the feet correctly in a dynamic and detailed environment.

Full Control of Behavior
Move your character around by any means you desire, be it a CharacterController, a RigidBody, or your own custom movement logic. The Locomotion System simply observes the position, alignment, velocity and rotational velocity of your character and deduces everything from that, along with some raycasts onto the ground. This means the system can be used equally well for player avatars and for AI characters; for third person control, point-and-click control, scripted movement paths, or whatever control scheme you need.

Use With Any Legged Character
The Locomotion System is not just for animating humans. It can be used for just about any character with legs, and indeed the project folder comes with a human, a heron, and a coyote. As can be seen in the videos above the system has also been tested with a bear and a wolf. Give me a holler if you try out the Locomotion System with an animated spider. I didn’t have a spider model myself for testing, but I sure want to see it in action! (Actually, give me a holler no matter what you use the Locomotion System for – I’m interested in seeing where people take it.)

Simple Automagic Setup
If you think that all this advanced tech is complicated or cumbersome to use, you’d be wrong! The Locomotion System features a fully automated motion analyzer that analyzes all the provided animations and figures out the velocity of each and well as the times that the feet lift off the ground and land, and lots of other data that it uses at runtime. All it needs from you is a little help with pointing out which bones constitutes the different legs, and a few other simple details. It can all be specified using drag-and-drop and typing in a few values. No scripting required!

Indie Budget Compatible
Big game studios these days are able to create quite realistic walking and running on uneven terrain, but it typically requires hundreds of animations to pull it off. The Locomotion System takes a different approach and attempt to do much with little. Even with just an idle animation and one walk cycle, you still get walking on any uneven terrain and in arbitrary directions, including turning. You can supply more animations too, if you want, and then the produced motion will look even better. One user used walking and running in 8 directions each, and it looked great. So supply as few or as many animations as you like, and the Locomotion System will take what you have and make the best of it. How’s that for Indie friendly? Oh, and did I mention that the Locomotion System itself is completely free to use in Unity games?

Try For Youreself!
You can take the Locomotion System for a spin yourself, right here! Watch the automatic demo mode or take control yourself. There’s a bunch of visualization options too! Just click the image to load the web-player.

Please view the full post to see the Unity content.

Press the Auto-Demo “Off” button to take control yourself. Move the character with the keyboard arrow keys. Optionally, the facing direction can be controlled with the W, A, S, D keys. Hold down shift to walk instead of run. Use + and – keys to speed up or slow down time.

Alternatively, with a game pad, such as an XBox 360 controller, the direction and speed can be controlled precisely with ease, while independently controlling facing direction with the secondary stick.

Download the Locomotion System yourself and see if it might add some extra life to your animated characters!

To harness the power of these tubes, Unity Tech has begun working with a content delivery service called Akamai.  Akamai provides server mirrors with fast connections around the world in order to make sure your downloads are as speedy as possible.  They do this for lots of big, well-known companies that you can see on their web site: http://www.akamai.com/html/customers/index.html

Because this download service affects users globally, we’d like everyone to help us make sure there are no kinks in the system.  If you can spare a moment, we have two tests for you to run.

Test #1: Download the Unity 2.5.0 webplayer installer through Akamai:

• For Mac: http://webplayer2.unity3d.com/download_webplayer-2.x/webplayer-universal.dmg
• For Windows: http://webplayer2.unity3d.com/download_webplayer-2.x/UnityWebPlayer.exe

Test #2: Auto-update from 2.1.0 to 2.5.0 using Akamai

Steps:

1. Download the 2.1.0 webplayer (not using the Akamai service)
   * For Mac: http://unity3d.com/download_archived_webplayer/2.1.0/webplayer-universal.dmg
   * For Windows: http://unity3d.com/download_archived_webplayer/2.1.0/UnityWebPlayer.exe
2. Install the 2.1.0 webplayer
3. Restart your browser
4. Visit this url to auto-update using Akamai: http://beta.unity3d.com/AkamaiTest/

Both test #1 and #2 should be blazing fast.  If you can, please leave a comment about where you’re located and your average download speed, we’d greatly appreciate it!