Makesites

The problem that arises from any paradigm shift in technology is that the right tooling needs time to mature and is at first incomplete or even completely absent. In this case, we have tools to create and distribute 3D content but none of them were developed with the foresight of 3D being published as an online asset. In fact, there's a tradition of 3D being created in native formats, compiled in huge binaries that are copied and stored on a machine locally, with almost no understanding or care about network interfaces. The dynamic nature of the web brings a new set of limitations and capabilities and requires an asset pipeline to be more aware of its environment. Needless to say, it is almost impossible to get the existing tools working efficiently in a modern day web tech pipeline - obviously I'm talking out of personal experience...

Back in November 2012 my team made a firm decision to focus on open web technologies moving forward - that meant 3D projects that were underway had to be recalibrated. We did that because we saw that WebGL was (finally) ramping up to becoming the standard it was always meant to be in browser-based 3D rendering and that networks were increasingly more important for video games, with cloud-based services being the "new" buzz world. Game development was arriving on the Web and we couldn't be happier.

Personally, I balanced my anticipation with a sincere concern about the lack of tools available to aid web developers in their new responsibilities. Delivering 3D content didn't seem to me an issue to be handled lightly. As a result, building a proper asset pipeline for my business became my priority. After researching and talking to other developers I noticed how little interest there was in brainstorming the right tools for the job - I accepted it with great surprise.

On the one side, the status quo was dictating how 3D is done based on tradition, essentially trying to retrofit old methodologies into new systems - some programmers even claiming that the browser should be stripped down to a blank viewport that runs compiled code. On the other side, entrepreneurs with a sense of adventure were trying to "assist" by introducing proprietary solutions for compiling and delivering 3D content - notably built on top of open technologies like JavaScript. Both approaches seemed to me far from the spirit of open source, license-free, collaborative web development we all enjoy and hopefully appreciate.

Throughout my wandering I had compiled a list of the missing bits for a complete 3D asset pipeline for the web and one of them was the automated compilation of 3D assets in binary, production-ready, formats. It had to be automated for a number of practical reasons. First of all that's how all other media is compressed in web development (images, audio, video...). And in reality manual compression would never be widely adopted - asking a web developer to use 3D software is as awkward as asking a 3D artist to export in a web ready format... Moreover, that's how web developers are known to be more productive - through automation. Instead of waiting for a solution (which would inevitably surface) I followed the common advice you hear in open source: if it's not built YOU have to build it. With the pinnacle requirement. Being automation I was led to Grunt.js, the most popular tool for automating tasks in web dev, and from there Grunt 3D was born.

How can Grunt 3D help

As an overview, Grunt 3D takes an existing 3D asset and compiles it to a compressed, human-unreadable format. As you can imagine its utility is very narrow Grunt 3D Helping you Setup 3D Asset Pipelines for the Web CSS3 and WebGL have made 3D on the browser a reality. This has long been the dream of many web developers and it's an exciting time to experience first hand all the innovation happening in this area on the web. But there's definitely room for improvement on the existing tools for publishing 3D content online. en.sdjournal.org 35 Grunt 3D considering the full spectrum of an asset pipeline, but its contribution is a rather important step in the process. The compression Grunt 3D offers is needed both for performance during the delivery of the asset over the network and its loading into the 3D engine but also for copyright protection, as any commercial product is required to have.

The input formats supported are ascii based, and source files are for the most part universally readable formats like OBJ, 3DS, FBX and COLLADA. These formats are great for sharing 3D during the development cycle but do very little to fit a production - ready format. For the output, there can be a variety of options as well. Three.js has its own Binary JSON format, the Kronos group is working on glTF, a binary specifically optimised for WebGL, and OpenCTM is gaining popularity as an open source format. Currently the branch from OBJ to Binary JSON is operational - but the list may be extended with more formats as add-on plugins.

The adoption from the community will dictate how broad the format support will be.

I should emphasise that Grunt 3D is not trying to endorse any specific 3D technology or even adopt a preferred file format. It is simply offering a unified API that groups different compression methods for different 3D file formats. The key word here is 'compression' - and should not be confused with conversion. To make a parallel with other media, we use UglifyJS to minify JavaScript and the H.264 codec to compress video because that's how we distribute online content. The reverse process of uncompressing content is not a popular use case - and thus Grunt 3D is not scoped to satisfy that need.

Not tying Grunt 3D to specific formats is intentional and agrees ideologically with other open source tools web developers are using. The compression should be content agnostic and simply lookup preconfigured folder locations for 3D assets in a non-opinionated way. This mindset lifts limitations of existing asset pipelines that dictate more steps as to how assets are handled before and after the compression. In contrast, Grunt 3D fits any existing development pipeline and is well suited for a web tech pipeline.

The programming interface was another big concern and ideally Grunt 3D should be able to be used by the novice developer. Again, this goes against a culture of manual setup and execution of hard to read scripts that traditional asset pipelines usually offer. Grunt.js was a perfect fit in that regard as one of its main goals is to provide a simplified API for developers to configure rather complicated tasks. As an immediate result, the Grunt 3D API is kept simple, and the syntax should seem very familiar for developers that have used Grunt.js before or just know JavaScript. This piece of code for example is all that's required to lookup for OBJ files in the "media" folder and output them in Three.js JSON format:

grunt.initConfig({
    three_obj: {
        options: {},
        dist: {
            src: ['./media/*.obj'],
        }
    }
});
grunt.loadNpmTasks('grunt-3d');
grunt.registerTask('default', ['three_obj']);

It's worth noting that this configuration is only done once and from there on executing Grunt should be enough to parse any new files, under the pre-defined parameters.

As you may have already assumed, Grunt 3D, built on top of Grunt.js, is powered by Node.js. In fact Node. js is the only dependency for Grunt 3D to run in any environment, which makes it very modular by nature. Technically, it can be setup remotely and operate as a network service. This allows an asset pipeline to gain some characteristics of a cloud service, something most existing solutions want to achieve but hardly any of them can offer this functionality effortlessly and with no significant costs.

This sums up the main characteristics of Grunt 3D: To be automated, content agnostic, with a simplified API and modular in its architecture. To top it all, Grunt 3D is open source software, released under the MIT license and everyone is free to contribute [on Github](http://github.com/ makesites/grunt-3d)

A bright future for 3D on the Web

To respond to the growing demand of 3D content online we'll have to setup asset pipelines that are tailored for online publishing, not stay bolted to old architectures and take advantage of the possibilities the web and its browsers offer.

Web developers have their own tradition of creating software that automates tasks over networks and we should honor that by incorporating 3D into existing web dev practices. Trying to overlap responsibilities between web devs and 3d artists or even merging the two disciplines is not going to be productive. The web has experienced this already with desktop publishing and the hybrid role Graphic designer/Web developer never really took off.

3D artists are perfectly fine to continue doing what they are used to and with automated tools like Grunt 3D everyone can stay in their comfort zone...