From Unity to Three.js

Over the last several years, Unity has been quietly revolutionising the way we create interactive content. Since we started using it in 2009, it has evolved into a powerful solution for 3D and now 2D development, with remarkable smooth workflows.

Although HTML5 isn’t (yet) among the many platforms Unity supports, we can still take advantage of its robust toolset for our WebGL projects.

The Three.js 3D engine is our library of choice for building interactive experiences for the web. It’s fast, powerful and always getting better.

While working on HelloRun and Lights, we found ourselves increasingly using Unity in the asset pipeline. Initially writing custom JSON exporters for proprietary formats, and later on supporting the native Three.js Object spec.

But these are quick and dirty approaches that require a considerable maintenance effort to keep up with the features of each project and the development of the engine. We want our workflow to rely on existing tools and open formats wherever possible.

This post describes the asset pipeline from the Unity Editor to the Three.js WebGL engine, using the Collada format.

But why use Unity in the first place? The most immediate advantage is that of importing 3D assets and arrange them in the scene with little effort.

And that’s just the beginning, the Unity Asset Store is full of useful packages and plugins covering everything from textures, models and animations to whole project examples, tutorials and editor extensions.

Some tools are great for optimising our models and reduce render time, like Mesh Baker for combining multiple meshes and materials together, or Cruncher for reducing polygon count.

We also rely on the Asset Store for purchasing game-ready 3D models or building them from scratch. There’s plenty of modelling extensions for creating all kinds of objects and a huge library of high quality 3D models at very affordable prices.

On top of that, the Pro version of Unity includes an integrated lightmapping tool that perfectly bakes lights into textures for amazing quality and performance. It leverages Autodesk’s Beast, a set of tools for creating realistic lighting in games, to dramatically enhance the quality of our visuals.

Last but not least, we also use Unity to rapidly prototype our ideas. It’s much faster to iterate with and allows us to try out different concepts and designs quickly.

If you haven’t tried it yet, we suggest you download the free version of Unity and take a look at its excellent learning resources.

Unity can import 3D models, bones, and animations from almost any 3D application, just by dragging the file to the project panel or the Assets directory in the project folder.

Select the model file to display the Import Settings inspector and adjust the scale factor and how normals and tangents are imported.

Also make sure you set the Material Naming option to From Model’s Material, so the original material names are maintained.

For more information about getting your assets into Unity, check out the Importing Models page in the manual or The Project Panel and Importing tutorial.

To export assets from Unity we use the Collada Exporter from the Asset Store, a very comprehensive extension with support for animation, skinning, terrain, material properties, lightmaps and physics (colliders, rigid bodies).

The exporter generates a DAE file containing object hierarchy and mesh geometry data in Collada format, a XML-based interchange format that allows information to be easily shared between authoring tools.

An additional feature of this extension is that it creates PNG textures for the included materials, which comes in very handy when using textures with alpha channel.

The file format we use for the exported textures generally depends on whether they have an alpha channel. For 24-bit textures (without alpha channel) we export to JPG format using Photoshop’s Save for Web and Devices to minimise file size.

If the texture includes an alpha channel we use 32-bit PNG format, but not from Photoshop because it saves transparency instead of alpha. There are ways to solve this, but fortunately the Collada Exporter does it for us and correctly converts PSD files with alpha channel to PNG format.

Since Collada is not a delivery format, it’s not well suited for web applications. We can load DAE files directly into Three.js, but in order to save bandwidth and reduce loading times, it’s preferable to convert them to Three.js native JSON format.

The easiest way to do this is using the Three.js Editor. Just drag the DAE file into the editor and export it back as an Object file. You can repeat this step whenever you need to update your model files to the latest revision of the engine.

We also use the editor to check how models look in WebGL and ensure the conversion has worked correctly without any errors.

If you don’t see your model after it’s been imported, select the root DAE object in the Scene panel and make sure that its scale is not set to zero.

To load the exported Object file into Three.js just use the THREE.ObjectLoader class. Make sure you are not using the older THREE.JSONLoader class because it supports a different JSON format.

Please note that due to security restrictions, loading from a file system is not allowed by the browser. When loading models or textures from external files, you need to run from a local server.

Another option is to start Chrome with the allow-access-from-files flag: /Applications/Google\\ Chrome –allow-file-access-from-files (Thanks to Andy for the tip)

In our workflow we usually create materials and shaders from scratch in JavaScript, instead of trying to import them from Unity. This way we know we’re looking at the real thing and can assess quality and performance.

We hope you find this asset pipeline helpful. We work constantly on improving our processes, and we know that many other developers do the same. If you have any question or advice, please leave a comment.

Posted by

Hi, I'm Carlos Ulloa, an interactive designer, based in Brighton and co-founder of HelloEnjoy. You can find me on Twitter and Soundcloud.

16 comments Write a comment

  1. Great insight info, thanks for sharing! the The Collada Exporter could do me a favour of importing Unity inside Openframeworks too!

  2. Is that last screen shot WebGL? Looks amazing. One of these days I will learn Unity :)

  3. Thanks for sharing guys. Can’t wait to see the upcoming project, looks v nice.

  4. You mention animations, but I believe that you can’t get animations through the entire workflow you describe. As of a month or two ago, the Three.js editor did not handle morph target animations. You may also want to refer to types of animations (skeletal vs morph targets).

  5. Great write up !!
    I followed the steps without any issues right through until loading the model with Three.js

    When I export the model from Three.js/editor, the model is exported as an object type, not geometry type.

    Trying to use JSONLoader, the loader is looking for geometries, not objects.

    Which ObjectLoader class did you use to import the model ?


    • Thanks Phil, we are using the THREE.ObjectLoader class to load the exported model. I’ve updated the post to avoid confusion.

  6. C4RL05, that’s a great article, I liked your speak about the making-of in madrid, It was a nice experience!

    • Thanks Volkan! I haven’t tried exporting colliders directly. I use meshes instead, setting them up as colliders in JS.

  7. “you need to run from a local server”

    Incorrect. You just need to start chrome with the allow-access-from-files flag

    /Applications/Google\\ Chrome –allow-file-access-from-files

  8. Hi!

    Very nice post. I’m working on a three.js project and Unity3d project in parallel right now. Unity3d really is the way you go for serious development at the moment. three.js is very nice and the community is very vibrant but I think it isn’t quite there yet, i will take another year or two but WebGL and three.js are definitely the future, though I think platforms like unity will never die completely.

    The most amazing thing about three.js and WebGL is the proof that JS CAN be really fast, if done right. But the workflow and IDE’s (beside WebStorm) really suck for game / graphics development. I dont want to arrange my 3d models using VIM oder Emacs. …

  9. Nice work man. Do give you a hand I’m going to build an editor in unity to complete the entire
    level of creating games on Unity’s editor. But there is a question. How would you involve game’s codes in Tree.js?

Leave a Reply

Required fields are marked *.