Is it Flash and Papervision? Is it Unity3d? No, its both!

So this blog has been in a near comatose state for most of the year, simply put, I’ve been busy. Like crazy forget-to-put-on-underwear-when-you-leave-the-house busy. On the up side I can say that a year ago I was a junior dev at starting out at Hello Computer, and now I’m the lead developer on a project that not only pushed our own boundaries, but also gave the boundaries between technologies (Flash, Papervision3d and Untiy3d) a damn good run for their money.

Side by side of the flash and unity on

Side by side of the flash and unity on

The problem at hand

From the moment this project landed in studio it was clear that we had some massive challenges ahead of us. Basically the brief from BP South Africa was to take their previous Ultimate Ride campaign, and make it bigger, better and totally more bad ass. So we knew that we were going to make some kind of car ‘avatar’ creator, and there was going some kind of gaming/racing element. Right at the beginning there was a lot of discussion around making the right technology choice for the project. Flash is of course the old faithful for creating interactive experiences that we’re all familiar with. Unity3D on the other hand is the relative new kid on the block, aimed squarely at gaming experiences.

The performance abilities of Unity3d, together with its snug relationship with everything 3D, makes it massively more capable when it comes to delivering a compelling 3d gaming experience. Unfortunately getting client sign-off on something like Unity it’s still quite a hard sell. Its penetration figures, while showing impressive growth, simply can’t compare to Flash’s near ubiquity. Coupled with the minimal exposure the dev team has had with Unity, that always means a few bruised knees getting to grasps with a new platform. In a few moments of inspired madness we decided the solution would be to use both. By building most of the site in Flash, together with Pv3d, we would have access to Flash’s near total market penetration, as well as being able to really maximise the tech we’re intimate with. This would also allow us to gently break users into the Unity realm, by giving them a very large part of the overall experience before they have to install anything. Then with Unity, not only were we able to deliver a much more compelling game experience – making use of high poly environments, dynamic lighting, etc – but the limited scope also provided the perfect opportunity to really get a good sense of what Unity was all about, without completely being in over our heads and drowning.

The gory details

The key to making the project work is the U3DOjbect library by Aquiris. It’s basically Javascript bridge which allows Flash and Unity to communicate through ExternalInterface, and it also uses some js trickery to dynamically resize the flash and unity objects. It’s something they’ve successfully employed on several of their own projects, and credit to them – it’s down to their inspiration that we even began to consider this approach possible. The real trick though was to get the user to feel like they were racing “their” car inside Unity. The problem here is that the car gets created in Pv3d. This meant finding a way to transfer textures between the two was an absolute necessity.

At the core of the Papervision implementation is a data ojbect that represents the location and colour information of all the decals on the car. In order to start 3d-rendering Flash loads in this data, then loads in the appropriate decals as vectorised swfs and layers them onto a texture using Flash masks, which Papervision then renders as a movie material. Obviously, all very Flash specific. This meant that sharing the data object would simply be impossible, and therefore we needed to find a way for Flash to provide a texture for unity. The first option was to simply save a jpg onto the server and have Flash pass a reference to this location through U3dOjbect. Unfortunately this means turning a few kB’s of swf vectors into a very colourful 1024×1024 jpg which can’t be cached. Multiply by thousands of cars over tens of thousands of races and suddenly you’re talking about a very massive hit to server bandwidth. Sadly given the state of internet South Africa, server bandwidth is a precious commodity so this wasn’t really an option either.

The final solution was to actually send the texture through the JavaScript bridge, as this means no bandwidth hit as everything is happening client side. There has been some limited experimentation with this in the community, but there isn’t really much information on how to proceed. Basically it comes to sending a Base64 string via JavaScript. The problem is that there is a 16kB limit on what you can send through JavaScript. This means you have to send the string in chunks. With the help of the talented Robert Stuttaford, we were able to extend U3dobject to this end (sadly, I’m not in the position to release this back to the community). The end result is a seamless integration between flash and unity.

The do-not-try-this-at-home warning would be that is debugging the whole set up is a massive pain, as not only do you usually have to compile both Flash and Unity, but you also have to test everything in the browser, away from all your wonderful debuggers. I also ran into several weird issues with unity not being able to preserve imported textures across level loads. This leads to a situation where flash and unity have to a very specific two step back and forth to get the end result working. Because unity makes good use of the GPU, we didn’t have too many problems with CPU performance (a welcome break after having to optimise the hell out of Papervision), however the memory hit of running two memory intensive apps next to each other is always going to difficult to manage. I think we got to a point where it’s workable, but none the less the whole site is definitely at the memory “intensive” end of the scale.

Be back in five…Gone Racing.

Despite the fact the game mechanic is very elementary and basic, it’s been rapturously received by our user base. We could have saved ourselves a lot of blood pressure medication if we decided on a simple Flash game, but I have no doubt the immersiveness of the experience would have suffered. At the end of the day, it’s really nice to see how well two technologies can co-exist together. Especially with all the Html5 hyperbole that been floating around, it really does come down to choosing what’s going to be best for the task at hand. I honestly couldn’t imagine building some of the flash elements in unity, and vice versa. So I say rather than rant about technology choices, let the tech do what its good at!

  • Stacky

    It rocks bro! Great job! Don’t suppose you can now do one with Audi vs BMW for some healthy office competition!