Games developers will be able to use Fabric Engine to improve their games’ various characters
introduce Fabric to a TA or TD than to get them to write C++. Fabric Engine was designed for
performance and ease-of-use from the outset. This means that we provide the performance that modern production tools require. Our goal is to allow studios to work at real-time frame rates, even when working with very heavy data – in terms of both volume and complexity. We provide all of our code to our
customers – we recognise that studios often have developers that know perfectly well what they want to achieve. We designed Fabric Engine to be modular so that developers can change any part of it – from the rendering right down to how it handles multi-threading. Fabric Engine was designed to be easily
extensible – in particular, we make it easy to integrate with existing libraries. This allows us to provide support for data formats like Alembic, Collada and FBX. Beyond that, it also means that we can support libraries like Bullet Physics and work with streaming data from motion capture devices.
So are you trying to enable developers to replace some of the content creation tools that exist out there? No. Fabric is complementary to existing content creation applications. With Fabric Engine we’re trying to replace the need for bottom-up custom development. Applications like Max and Maya are well established and people work with them every day. Fabric Engine is built to allow smooth interop with these existing tools. We aren’t introducing new formats or anything that
would increase pipeline headaches. There are many tasks that the established tools do not do well, where customisation is required. For all of those tasks Fabric Engine is the
perfect fit.
We enable developers to focus
on building the tool they need, rather than spending time on architecture and plumbing.
Paul Doyle, Fabric Engine
Can you give some examples of what a games developer might use Fabric Engine to create? Fabric Engine is capable of taking on most compute-bound problems – particularly heavy 2D and 3D processing. We have built a few samples showing use
cases from character rigging through to crowd simulation and image processing. We’ve developed a number of examples, which can all be found on our website. For games we have some ideas around solving the headache of getting a good character pipeline going. We believe that tools need to be built back
from run-time, rather than the prevalent approach of exporting data from a DCC tool and dealing with all of the pain that comes with it. Fabric Engine is well-suited for building this kind of pipeline tool.
Could we dig into the technical details a little bit? How do the high-performance bits of Fabric Engine work? The high-performance parts of the application are usually described as a dependency graph – so written in Python or JavaScript –which describes task and data (SIMD) parallelism at a high-level. The operators on the graph nodes are written using a domain specific language, called KL (Kernel Language). KL provides features that are needed for high-performance code. We then take this description and Fabric compiles it on target using the LLVM compiler.
There’s a great deal of diversity of developer make-up and size in today’s games industry. What kind of studio is Fabric designed for? Essentially any development studio can make use of Fabric Engine. Larger projects tend to have greater demands for custom tools, but it really depends on what the studio is trying to achieve. A TA or TD can take Fabric’s existing examples and work from there, or an engine programmer can delve much deeper into our technology.
How does the open source licensing model you offer work? The core of Fabric Engine has been released under the AGPLV3 Open Source Licensing Agreement, which means that developers can download and start working with Fabric Engine free of charge. Additional technology like our PyQt
framework and scene graph are commercial products that we license separately. www.fabricengine.com