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 (p...@fabric-engine.com) - 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 <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 :) >> >> >
