Fabric Engine 2: Discussion, Videos & News

Alright so I mentioned this in passing a few times in some other threads, but its at that point where it deserves a thread of its own. Whats happening on the Fabric Engine 2 front is just outright fascinating…especially given the next gen workflow, its also an area that Blender is missing out on.

So to start off, what is Fabric Engine?

https://vimeo.com/132732105

To put it simply, its a framework that works across multiple applications. In other words, imagine creating a tool and having it work in Maya, Max, Modo, C4D and even UE4. Imagine not losing those tools or developments between applications. Imagine say you rely on XSI and Autodesk shuts it down, that you are not losing all the work you put into developing around it. Thats just the tip of the ice berg in what Fabric Engine is trying to achieve.

When is it launching? Apparently Siggraph 2015

https://vimeo.com/135353349

Website:
http://fabricengine.com/

Quote from Paul @FabricEngine on pricing (individuals, small studios)

“With regard to our business model - we sell site licenses. Giving people software for free makes it easy for them to prove that Fabric is useful, ultimately leading them to getting approval for deploying across their studio. Fabric is a framework so we have to approach it differently to selling boxed software. It’s working pretty well for us so far.”

Examples & Demonstrations:

https://vimeo.com/132523543

https://vimeo.com/132562529

https://vimeo.com/132535737

More: https://vimeo.com/user6371427

Bookmarked / subscribed to thread. Some of these videos I haven’t seen (& little time now). Plus have stuff to mention later :stuck_out_tongue:

And before you ask, this is something that even forking Blender or shaking up its leadership won’t be able to fix. You would have to practically write a new FOSS application from scratch if you want something like this available for free. The alternative is for the BF to roll its own node-based solution, though it may not be possible for that to then become an open standard for this sort of thing.

It’s a good idea, but like many good ideas, be prepared to pay at least 1K for the opportunity to use it in a 3D modeling environment.

THis is nice!

my walking ragdoll could be soooooo smooth.

Why would I ask? lol
It was obvious that the licensing model is going to be a major compatibility issue. In many ways though it would be worth seeing a new more modern free 3d application spring up with FB2 compatibility in mind, as I think it would be a perfect sandbox for such an approach. I believe that is the intent of Natron’s developers as well with their Nuke copy.

@Subject
FB2 & Unreal Engine 4 via CANVAS:

https://vimeo.com/121620265

What about Houdini Engine, Realflow, Shave and a Haircut, Thea, ect…

If you have all of those in mind as well, you can theoretically create a free 3D application that just has the basics rolled into the main package with all other functionality being provided by both free and commercial extensions. The downside though is that by the time you get the complete package, you might’ve just spent more than you would’ve on a Modo license (which would hurt adoption to say the least).

Ace, I’m not quite following your line of thought on this… what are you talking about and what does that have to do with my comment?

Fabric engine works like a massive plugin if I understand it correctly, that would theoretically make it possible to combine it with the other major commercial plugins sold for most, if not to all of the known commercial applications.

So in a sense, a theoretical free application that is a base built outwards by commercial plugins would also have the Fabric Engine as a contributor, but the fact that it would be ‘free’ with strings attached due to the commercial extensions would likely hurt its adoption, at least among Blender users.

Crazy stuff, maybe if we’re lucky there is a way to implement it into Blender without much tricky stuff to do in it. Octane did a pretty good job on it so maybe Fabric Engine can as well. If they’re actually interested. I mean it would only be as a favour to Blender to be honest. Putting it in Maya/Modo/Renderman was probably the smartest thing they could have done.

So, having watched the videos I missed last time, it hasn’t changed any of my original impressions. It’s still pretty awesome but comes with some limitations & provisos that some people (here at least) might miss.

Fabric Engine can be used at two different levels - the “universal plugin” level and the “universal engine” level.

FabricEngine - Universal Plugin:

At this level, FabricEngine has basically implemented what I am trying to do for/with Blender (but am taking way to long to get done). Namely, it provides a generic API & libraries for people to write their own geometry generation, deformation, animation, import/export, etc tools. They also supply the “integration layer” for the main DCC applications on the market (that don’t require GPL compliance).

Essentially what this allows is for a third-party developer to write a plugin (in C/C++ or their KL scripting language) that can be loaded on Maya, Max, XSI, and any other host software that FabricEngine developers have implemented a host library for. Instead of writing a city or building generator that can only be used on Maya or 3DS Max, the plugin can now run on ALL supported FabricEngine platforms. That awesome muscle deformer plugin will work for ALL the DCC suites. That crowd simulation engine no longer requires Maya to run. And so on.

In a hypothetical world where FabricEngine were willing to make their API & integration code GPL-compatible (say MIT or Apache licensed), that would enable them or another developer to create the host code for Blender such that we too could use FabricEngine plugins. Sadly, that’s unlikely to happen.

FabricEngine - Universal Engine:

The biggest thing to realise about FE is for the “cross-platform, cross-software” benefits to be realised, you need to have it replace the guts of your DCC software. If you want to have that same rig work on Maya, Max, and other FE2 “hosts” - it needs to be completely implemented inside the Fabric Engine plugin(s). It’s not going to give you AD’s Biped in Blender or CGCookie’s Anna rig in Maya.

Depending on what you do & how you do it, this may not be a big issue. However, if you intend to use FE this way, you have to start considering that you DCC software is simply a highly functional (and somewhat expensive) “skin” to the FabricEngine’s guts. Good for large studios with teams using diverse software setups… not so great when the FabricEngine happens to not have a plugin you need.

I think FE will get great traction on this level from the medium to large studios that contract out animation & rigging jobs to the cheapest they can get away with. After all, if the rig is implemented in FabricEngine and the keyframes fed into it are the same - who cares if they did it on 3DS Max, Maya, or XSI? If the output to the renderer is the same - you’re golden. For smaller teams that rely on tools that come with their DCC software to speed things along (e.g. 3DS Max’s Biped) - it’s not going to provide a much bang for your buck.

I hate to be the cynic here, but this tech is aiming towards providing an industry solution. That’s immediately why it probably won’t ever happen in Blender.

Blender’s development style has never been about being industrial cutting-edge. Even if this framework were feasible within Blender (both in development and in licensing issues), the problem is that Blender Foundation’s made it pretty clear over the years that they do things to their own priority, at their own pace.

They’re generally not interested in fitting in with the industry, as an industry-ready tool, simply because Blender serves community interest, rather than professional (industry) interest. And even if they were to perhaps look into Fabric Engine (or most any other great newly-emerging developments out there), it’ll be years before they finally implement it.

That’s just the pace with Blender. It’s fast with developing its own priorities, but slow with adopting the cutting edge. It’s still plenty useful as a tool, and there’s nothing wrong with being a community-oriented software, but if we’re to ever look at it as an industry potential that’s incorporating of these newer-emerging technologies, core Blender development will have to feature more focus, direction and unification towards that end.

Otherwise, Blender will remain the ad-hoc community-effort project that it is–respectable and generous, but in terms of industry, impractical and inefficient about adopting newer options in cutting-edge solution. No insult intended. Just observation, as someone who hangs out around Blender community as a fan and works around industry as a working professional.

lets see this fabric engine, this is very promising, but looks like this is a software for BIG productions, not small/mid size studios.

For what it’s worth, when it has come up on the Fabric Engine mailing list their CEO has been a lot less pessimistic about the possibility of a Blender integration than the folks around here. While being very clear that their customers are not asking for a Blender integration, and therefore it isn’t something they are going to work on he has also indicated that they would support any third party developers that wanted to pursue it. I think that is primarily how the Houdini integration has progressed.

Unfortunately I can’t make it to Siggraph this year but hopefully they will post videos of their user group presentations like they did last year. I’ve been keeping a pretty close eye on FE and now that 2.0 is ready will need to find some time to get beyond the toy applications I’ve written so far. Even for a tiny company like mine I can see a lot of potential advantages to using it for some of our tools.

I don’t know. The Octane developers had to do some pretty tricky workarounds for Octane to work with Blender and that is basically just exporting data from Blender to Octane.

From what I can understand about Fabric Engine (with my extremely limited non-programmer brain) it will integrate with Blender on a pretty deep level which would mean that at last some parts of their code would have to be GPL-compliant.

I would love to have Fabric Engine for Blender. It could probably solve most of the integration issues with Blender and other software (I think)

I didn’t see any discussion of changing their license to make it GPL-compatible in the mailing list from the CEO or other developers. I did notice that they mention (a couple of times) there is no call by studios for FabricEngine compatibility with Blender, which I have no problems believing.

My pessimism regarding the issue of Blender integration is not based on the ideology or focus of the Blender Foundation, but rather on the fact that for Blender integration - the FabricEngine C/C++ API headers & libraries must be made GPL-compatible. I don’t see the folks at FabricEngine making that change for a variety of (legitimate and understandable) reasons.

Of course, even if FabricEngine does relicense their interface to allow Blender integration, there is still the ideological barrier within the Foundation (they have stated they are not interested in commercial plugin support before)… but I don’t think it’d ever get to the point where we’d be able to ask them for a merge to official distribution in the first place.

small minded people like me wont see the benefit of this until shiny images come out.

after all that was the secret of UE4’s success(the shiny images part)

How does the core of Fabric Engine’s business differ from Gaffer or OpenAlea? For the latter at least, the core is a domain-agnostic dataflow (node) based execution engine supporting loops composite-nodes. It is also pure python (which can hurt performance when exchanging data between nodes or running pure python nodes) - nodes can be anything exposable as Python.

Well, for OpenAlea, their own website should give you the primary difference:

OpenAlea is an open source project primarily aimed at the plant research community. It is a distributed collaborative effort to develop Python libraries and tools that address the needs of current and future works in Plant Architecture modeling. OpenAlea includes modules to analyse, visualize and model the functioning and growth of plant architecture.

As for Gaffer, there indeed appears to be some overlap (as there is with other ImageEngine libraries)… but it would be hard to argue FabricEngine is not more complete, has a more user-friendly interface, and covers more area that does Gaffer and it’s ImageEngine buddies. Never underestimate the appeal of staying within one’s preferred DCC software (where do you think all the love for BGE comes from!!!).

That said, Gaffer does appear to be a foundation that the Blender Foundation would likely find more appealing. One doesn’t get the same level of interop between Max, Maya, etc that FabricEngine already has established, but at least Gaffer is BSD licensed (allowing for proprietary plugins when desired/required).

I’m not sure why they would need to do this. The most likely scenario seems like it is FE keeps doing their thing using their current license, the BF continues their thing using their current license, and some third party writes a Splice plugin that integrates the two using a MIT or BSD license. All three components are distributed separately and it is up to users to meet the licensing requirements imposed by combining them in the process of building their own tools. Requirements that may or may not be acceptable to various classes of user. After all it isn’t like FE is going to start distributing Blender any more than they’re going to start distributing Maya.

It’s mostly of interest to people like TDs and Technical Artists. It isn’t so much about shipping with some magic Easy button for making shiny images, its more about a toolset for easily building fast portable tools.

For individual artist who aren’t working in a facility with in-house tool development one change they might see is that more plugin developers will do what Mootzoid are doing, port their plugins to run inside FE. If that means they only need to maintain one code base then more time should be available for feature development rather than just maintaining separate ports for Softimage and Maya and Modo and 3DS Max and …

Although the, new in 2.0, visual programming highlighted in the videos above is cool it is a relatively minor component of FE. What’s really valuable about FE is that its KL language allows you to easily write high performance tools without worrying about a lot of the low level implementation details. For example the same KL code can be compiled at run time to run on either the CPU or GPU depending on available resources. The MPC talk from last year’s Siggraph gives a pretty good overview of some of the R&D issues it helps with.

For the record, I don’t think anyone here (myself included) are being “pessimistic”–just realistic about prospects. No one’s saying that there’s no chance of Fabric Engine seeing Blender integration.

At least with myself, I’m just saying that it’s not very likely, for the realistic reason that these kinds of industry-focused developments are rarely, if ever, in Blender’s wheelhouse. Especially when it involves a commercial product.

No condemnation Blender here. Just a practical look at how Blender’s community-oriented, and not industry-oriented. That factors into what dictates Blender’s chances of incorporating something like Fabric Engine, which is chiefly for the purpose of improving industrial pipelines.

Even if Fabric Engine would be willing to support Blender, you still need three things:

  1. Blender Foundation has to first decide to embrace it.
  2. Blender and Fabric Engine’s developers have to ensure their licenses won’t cause issues.
  3. Blender Foundation would have to start a new initiative to work on Blender integration–i.e., a crowdfunded effort to set aside dedicated time and resources for the undertaking.

We barely saw Project Gooseberry supported towards its goals. And some people still throw stones at Blender Market. And those efforts are community-focused. So, the community would have to prove that they truly want this effort.

Fabric Engine is a solution for industry work, and just realistically, industry just isn’t the community’s priorities. Those pushing for endeavors like Fabric Engine are the minority around here. I don’t mind being proven wrong someday–I just sincerely doubt I will be.