I'll take a stab (although I haven't really spent any time using it). Often in production, we face problems that need solving. They can be generic problems that are common across a studio, like "fur" or "grass," or they can be show-specific, like "create time-lapse footage of a building being constructed." These examples are fairly small in scope, but studios may have even broader needs, like "We'd like a way to visualize our models quickly, without turntables, with an embedded Shotgun page for doing reviews."
There are lots of tools at our disposal for solving these things, but the most powerful toolsets all exist with various DCC packages. So any solution you come up with tends to be tightly coupled with one package. For example, a studio might come up with a good procedural forest solution in Houdini, but then every time they want to use it, they have to make sure they have a Houdini artist to run it. If the rest of the show is in Maya, you now have to deal with porting lots of assets over, and the additional crew. Or, more often, the technical artist or rnd person gets asked to "simply" port the tool over to the other package. Once you port the tool, you now have two separate sets of code to keep up to date, and eventually you have to hire more technical artists and RnD guys to keep up with demand. And the ones you have are unhappy because they're spending time keeping code in sync and porting features back and forth, rather than making cool stuff artists want. Perhaps the most common situation is that we see all of the issues above in advance, and opt to have an artist "figure it out themselves," or "do it by hand." Not because us technical guys are lazy beer-sipping jerks, but because it's actually cheaper to do it the hard way than to make a tool that will have to get rewritten by the time you use it again. >From what they've released so far, Fabric Engine goes a long way towards remedying these kinds of situations, and does so in a very clever way, that's geared for extremely high performance and flexibility. At its core, Fabric Engine gives us an API for graphics built with multi-threading and optimized machine level compiling in mind. With the Splice integrations in various DCC packages, we gain a direct way to integrate tools built in Fabric Engine into all our DCC packages with a single implementation. The tool you make for Maya Splice works in Softimage Splice, and does so far more elegantly than any one-off tool a TD is likely to create. Magic. So, for the artist, it means your studio can build better tools faster, and make better use of them across packages. Gone are the days of seeing what someone has in tool X and wishing you had it in Y. Also, gone are the days of worrying about building a toolset for a package (say, Softimage) and losing your R&D investment overnight because a publicly traded corporation thinks you should be using a clunky pile of aging Mel scripts with serious scalability and workflow problems instead. ***If Fabric Engine can improve the return on investment of RnD, you not only make better use of the RnD resources, but in the long term, you are incentivized to increase the RnD budget.*** Now, taking it one step further, we've made use of sites like rray.de, xsibase, creative crash, etc. Imagine if every new script or tool someone wrote could work in all the Spliced packages! The same arguments about RnD budgets at the company level apply to the community efforts as well. Not only do we get better utilization from the efforts people are making, but there's also a stronger incentive for developers to make more tools, because they can reach a wider audience. And on top of that, FE gives you a license for personal use, so there's nothing stopping individuals from contributing tools right now. The situation we're in now is a chicken/egg scenario. In order for all of the above to take off and revolutionize our industry, we need an audience of studios and individuals ready to consume all of these tools people will make. It's still very early days, so it's not in any way too late for this to happen -- if anything it's probably closer to being too soon. What I mean is, this isn't like Softimage, where the industry is turning a blind eye to a great tool. It's exactly the opposite, as some studios (MPC, Hybride) have already site licensed, when the tools are just getting off the ground. Given what's happening right now, there's a very unique opportunity with a captive audience of Softimage users on a 2-year ticking clock. Just by showing an increase of interest and sales, the value of FE is already growing on paper, which can help a young company get where they need to go even faster. That's my "pitch." No affiliations with FE whatsoever, but that's how I see it playing out. No guarantees it will happen, but I do believe the potential is there. It's important to note that a move in the direction of FE by no means has to be a move away from other DCCs. Just as it gives you a framework to build tools inside the other apps, it also gives you a better framework to bridge the work you do in various DCCs together. The scene assembly application idea is just one example of how it could do this. The other note is that I don't think people should be too quick to swear off commercial software solutions (i.e., non open source). I love open source as much as the next guy, but it's always either there or it's not. You can't will it into existence. It takes a lot of effort to build something great, and even more effort to do it with a team of disconnected individuals. I'm all for using what's out there and adding to the pile as much as possible, but if we hold our breath for an idea, we'll likely suffocate (i.e., be stuck on Maya). SItoA and MtoA have shown a great model for how open source tools can be built in concert with commercial software. It's a great way to gain the structure and supervision of a company while still gaining from the community and letting companies stay in control. I would argue that the core of Fabric Engine is a piece of software that really doesn't need to be written by VFX/animation/game studios (well, maybe the games guys, but not the ones using DCCs). IMHO, the balance between what's open and what's closed with Fabric Engine is really pretty good. On Wed, Mar 5, 2014 at 7:37 AM, Mirko Jankovic <mirkoj.anima...@gmail.com>wrote: > Anyone can explain a bit what are options with Fabric Engine for non tech > guys but purely artist type? > Start and work? I understood that it is creation platform for people to > get it and create their tools but what are chances that in time there will > be enough tools and libraries that will enable non tech guys to pickup > various tools and start working? > Or I misunderstood what is behind Fabric Engine completely :) > >
