To give some context, we have historically operated in a model where our 3D artists, animators, etc. output their content from a Digital Content Creation (DCC) suite of software like Autodesk Maya directly into our data conversion process, asset by asset. This process is responsible for converting the DCC output into our different asset-type-optimized runtime data formats for geometry, animation, etc. So for example, let’s take Jesse from Control. In our current workflow, an outfit for Jesse would be assembled in a DCC by our talented rigging team, who’d then export the full outfit to an intermediate file format such as Autodesk FBX. Our data converter picks up on this FBX file and translates that to the corresponding runtime data format.

This kind of artist crafted unique content has worked well for us in the past. However, with OpenUSD we foresee that we can maintain the same level of fidelity yet enable parallel editing workflows between artists; setting the stage for exploring generative ways of creating content variation and vastly improving content production workflows. In essence working smarter, and not harder.

Circling back to our Jesse example; when we consider an OpenUSD workflow, things get rather interesting. Instead of an artist assembling an outfit in a DCC and exporting it as a singular unique asset, all components of an outfit (shoes, shirt, faces, hands, etc.) could become their own assets and be combined using OpenUSD. This allows for far more flexible workflows as OpenUSD acts as a sort of intermediary “assembly” stage between DCC and converted data.

So in this case using OpenUSD means that these individual garment pieces could be updated in isolation, resolving into much faster turnaround times. Additionally, data is no longer duplicated thus reducing loading times of the assets. There would be for example only one OpenUSD asset that represents Jesse’s head instead of having it duplicated in all outfits.

While being able to de-duplicate is a great boon for modular content, OpenUSD also offers the ability to express variations, override existing data non-destructively, create cross-engine and project-portable data, and so much more! If you want to know more about OpenUSD itself, have a look at the Book of USD, our Open-Source beginner-friendly guide to OpenUSD.

But how to get to the smarter-not-harder point in practice? We’ve been recently weighing our options for the tricky transition period where we move from our current status quo pipelines into a situation where we can benefit fully from OpenUSD. One way to achieve this would be to slowly move the underlying services to use OpenUSD but leave the content creators’ side alone. For example, we could enable our conversion process to use OpenUSD under the hood. (This implies that the conversion process would be able to ingest OpenUSD data and output into our optimized runtime data.) That said, supporting only this would still incur a disruptive change on the content creation side as the content pipelines must output OpenUSD data.

To avoid this disruption, we’ve decided to opt for a OpenUSD plugin solution, which should make the transition period much more palatable for our pipeline and content teams. We’re writing plugins for OpenUSD that can read data formats that we currently use, such as Autodesk FBX. Such plugins will allow the use of our current file formats within OpenUSD as-is. The plugins are responsible for taking format-specific data and outputting OpenUSD data, effectively enabling the OpenUSD conversion process to operate on these formats as if they were native OpenUSD.

Over time, this ensures that pipeline and content teams can migrate to OpenUSD whenever they see fit; but under the hood, they could have been using OpenUSD in the content conversion pipeline already. On top of that, there is also a plethora of existing content that we can support out of the box using this plugin mechanism without having to convert them to OpenUSD manually.

And why are we telling you this? Because even though Northlight is our own proprietary tech, we want to keep true to the spirit of Free Open Source Software that OpenUSD is – we are happy to announce that we are open sourcing our usdFBX OpenUSD plugin. We hope it can serve as a basis (or drop-in solution!) for your pipeline migration into OpenUSD.

Get the usdFBX plugin and contribute

Read Book of USD

(Contributions welcome at Github)