Explain it to me as one TD to another

Fabric Engine is a platform to build custom applications. Using this platform you have access to high performance computing from a dynamic languages like Python or Jscript.

You can construct a Fabric Engine dependency graph that defines your application nodes and their connections/dependencies.

In simple terms, a node is an object where you can define your data e.g. point positions, and your methods e.g. a deformer. This node can have dependencies on other nodes (some inputs for example) and so will evaluate those dependencies first if needed. The nice thing with this dependency graph is that it can run several graphs in parallel (if they are not dependent on each other). In this case Fabric performs “task-based” parallelism.

In addition, Fabric can evaluate an operator in parallel if  you have more than one element processed by this operator (like the point positions for a deformer). In this case, Fabric uses “data-based” or “SIMD” parallelism.

KL is a language designed to run performance-critical sections of dynamic-language programs. As such, programs run as quickly as possible on modern hardware. The KL syntax is similar to JavaScript/C so it is very easy to learn if you already know one of those languages.

Creation Platform is the python interface to build those dependency graph in your application. So it lets you define, create/delete and connect those nodes together. It also gives you all the common components needed by 3D applications, like a 3D viewport for openGL rendering, an Undo/Redo system, a persistence system, manipulators, a timeline, some parser nodes to imports Alembic, or FBX or Lidar files for example.

You can add any C or C++ library to Creation Platform using the Extension system. This system let you access those libraries directly from the KL language.

Finally, with the new CAPI, you can now run the Fabric Engine Dependency Graph from your C++ or C application (like Arnold, Softimage or Maya) and use FEDG, our new portable description format to save those dependency graphs.

Is Creation Platform open-source?

No – the Core engine is closed-source, everything in Creation Platform is open, but not open-sourced.

When is it going to be released?

We’re moving into paid beta in early October 2012. We need to build some back-end infrastructure to handle things like licensing and billing before we can officially launch v1. If everything goes well, we expect to launch in early 2013.

Weren’t you guys making a browser plug-in?

We were – but a few things became obvious, and we decided to change the path we were on:

• The graphics industry has largely homogenized to Python and Qt for tool customization and development. Expecting them to move to JavaScript and HTML5 is unrealistic when everything else they do is with Python and Qt.
• We were having trouble getting the browser to perform as well as a desktop application. Some elements were not fixable by us, so we decided to move to an environment where we had full control.
• Browser technology is moving fast – WebGL and WebCL are looking very good, and plug-ins are not popular for developers or their customers. We think that vanilla web technology will be ‘good enough’ for many use cases.
• Working client-side in the browser doesn’t make much sense when working with lots of data. Streamed web applications make more sense, and don’t require plug-ins. This is an area we are working on.

Why did you build Creation?

When we looked at the content creation tools available on the market, and when we looked at how studios were working with them, we saw some significant issues.

DCCs were not designed to be platforms

Modern production pipelines require extensive customization of off-the-shelf DCC applications – there are simply too many diverse requirements to be covered by out-of-the-box solutions. Fortunately, many of these DCC applications provide customization tools that enable developers to  extend and adapt the application to fit requirements. However, few of these applications were designed to be platforms, so developers can expend a lot of time and energy navigating inherent limitations. Worst still, the core of the application is often inaccessible to programmers – they are prevented from making the changes they need.

If the DCC route doesn’t work, you have to build from scratch

When DCC tools cannot be customized for the studio’s needs, the only recourse is to build a custom tool from scratch using a language like C++. This means spending a lot of development time and resources on building back-end ‘plumbing’ for applications, rather than spending those resources on work that relates to the shot at hand. Even if you have the available programmers in-house to do this work, this is not an ideal use of their time. Creation handles the back end performance layer so you can concentrate on key functionality and workflow.

The need for a modern DCC framework

Many current DCC applications were not built to take advantage of multi-core CPUs – the core architecture was created when powerful single-core processors were the norm. Fewer still have been designed to take advantage of more advanced approaches, such as GPU computing and cloud computing. Computer graphics is one of the most performance hungry domains, and it’s important that applications keep pace with hardware advancements. As we see real-time production methods gaining in importance – particularly in areas such as previz and virtual production – performance capability is absolutely critical.

Monolithic

Most DCC applications offer a ton of functionality, and each year offer new tools and widgets. This has resulted in very broad, monolithic applications that carry a lot of legacy functionality. Much of this is redundant functionality or has been superseded by newer tools within the same application. In some cases there is over a decade of legacy functionality included, which creates a drag across the whole application experience. At the same time, most users are specialists that are only concerned with certain workflows – niche applications are much more relevant to how modern professionals work.

So we made Creation Platform

When we tied all of this together, it became clear that what we wanted to do was provide the common components that every studio needs for building custom applications – things like undo/redo systems, persistence and all the core elements that are required when building a custom tool. Beyond this, we build deeper functionality with modules for handling things like motion capture and animation. These are further connected together when we build sample applications to handle things like virtual production.

It was also clear that building another monolithic DCC application made no sense – the 3D generalist has been replaced by specialist artists, riggers, animators, lighting artists etc that prefer to work with specialized tools that are focused on their specific workflow rather than wade through layers of irrelevant UI. We realized that we couldn’t (and shouldn’t) provide complete applications for these specialized tasks – we can’t know exactly how productions want to approach these tools – so we decided to provide sufficient tools and controls for the customer to build what they need.

Lastly – possibly most importantly – we had to make Creation play nicely with existing pipelines and tools. This means supporting common formats such as FBX and Alembic, as well as providing integrations into the major DCC tools. This allows us to provide immediate benefit to a production without being disruptive to the pipeline.