I have just posted a new message to the list covering some of this - I'll read through this thread again now and respond as best I can.
On 5 March 2014 13:00, Andy Jones <andy.jo...@gmail.com> wrote: > 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 :) >> >> >
