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!

So, most of you have probably heard the news: Apple is going to release Mac OS X 10.6 “Snow Leopard” this Friday. This release will give Mac users plenty of new feature goodness and new technologies to play with, and brings a lot of changes under the hood. Unfortunately, I must inform you that one of these changes may cause some grief for Unity users, at least for the time being:

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.