(thread appeared in the end)
On 5 March 2014 13:29, Paul Doyle <[email protected]> wrote: > My new thread doesn't appear to have made it to the list. There's a copy > of it here: > http://www.si-community.com/community/viewtopic.php?f=36&t=4950&start=0 > > I honestly don't have much to add to what Andy wrote - he nailed it. The > last two points in my post are: > > "We can't do it alone - if you want to see change happen, you have to get > involved. Small companies like Fabric need your support, we need you to > kick things around and tell us what you think. We need to know what you > need. It's immensely frustrating to be told "this is cool, if only it did > X" and then we do X and the response is "now if it did Y then I'd take a > look". Get involved - it's free! > > Let's get creative - we are open to creating a consortium and finding ways > to open-source work done there. Obviously there are hooks into Fabric and > the concern will be around vendor dependency - however, a lot of that can > be addressed in the design of a particular project. We have done deals that > give source code access to customers after a certain number of years, and > we will work with studios to give that kind of security. We see this as > something where we would not be controlling anything, but working on a > partnership basis with the studios that want to do this. It has to be > driven by studios that want to see some control over their destiny, with > companies like Fabric getting involved to support and drive innovation. We > are a platform, so for us this is the way to success - providing > high-performance, dependable components that can be used to build > production-specific tools. If you are interested in becoming a part of this > Fabric working group then please email me ([email protected]) - > right now I'm just gauging interest with the hope that we can do something > amazing together." > > We started Fabric because we thought there was a better way to do things. > I won't lie - we took a few wrong turns with things like web technology. > However, the core engine has been consistently developed throughout, by key > members of the Softimage team. What we have now is an extremely powerful > platform that is hitting maturity - Fabric 2.0 is coming soon and it's got > a lot of people excited. For it to become everything it should be, it needs > support. I see it as a two-way street though - if we want studios to commit > to building on our platform, we have to be open to providing assurances > (contractual!). That's all I want to add - we're there and we are excited > to do something that breaks the studio/vendor mould. > > > On 5 March 2014 13:00, Andy Jones <[email protected]> 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 <[email protected] >> > 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 :) >>> >>> >> >
