Not with the current engineering resources available to us - we've geared the team for building a platform. Building a complete DCC is something that requires a lot of investment and a much broader team. Building one that's competitive with the incumbent solutions is a whole other matter. Even if it was possible to build a new DCC that was significantly better than maya in every way (IMO not remotely feasible even with millions to spend on it), I think it would fail. The fact is that artists know a few applications, and pipelines have been built around those applications. Even when a studio starts from scratch, they'll generally pick Maya as the baseline and then R&D guys will come and build on top of it.
If you view the incumbent DCCs as hosts for customization (very true for Houdini and Maya, more a plugin host for Max, and Soft the most out of the box of all) then our approach makes sense. They all provide rich front-ends that do many things extremely well, and there's no value in trying to replicate that - even if you did, what studio is going to bet they can hire artists for it? Fabric fits (or soon will) into all of them. Portable R&D has value, empowering TDs has value - it's hard to see where a new DCC provide real value. Fabric can be used to build niche applications like Horde, but even then people prefer to see it hosted in Soft or Maya. It's not like these applications are bad, they are well-honed for production for the most part. Performance chugs for most of them, but guys like us can address that. There's a lot of noise about ditching AD, but we're talking about something far more involved than just an application that moves triangles. Thousands of trained artists, years of R&D investment, capital outlay on software etc etc. The risk of change is prohibitive. There's a lot to be said for production-proven software and just knowing it will get the job done. Our view is to complement the existing solutions, try and reduce the cost and risk of R&D, and look at building functionality for areas that haven't been well-served already. Sent from my iPad On 2013-08-05, at 9:38 PM, Sebastien Sterling <[email protected]> wrote: > > not that you would want or need to Paul, but do you reckon the fabric engine > team could create a current generation DCC ? no follow up question or tricks > i'm just curious. > > > On 4 August 2013 17:40, Paul Doyle <[email protected]> wrote: >> It depends how we approach it. I'm confident in our ability to find a model >> that works. Ultimately we'd be providing a version of our engine (including >> source code), so I think the middleware/commercial engine approach is the >> way we would go. The stuff we're doing with Splice suggests we (and our >> customers) can implement some pretty nifty game authoring tools. Horde shows >> that we can encapsulate rich characters with secondary dynamics - and we're >> pushing on animation systems generally as an area that we think is ripe for >> innovation. >> >> Right now our core team is working on KL targeting the HSA architecture >> automatically - so KL rigs will have GPU compute available to them >> automatically. The pieces are certainly there for something compelling. >> But... >> >> My bigger concerns are around runtime footprint and budgets. I've been in >> the room when middleware vendors have made all kinds of promises, and then >> the reality of runtime budget bites them on the ass. We won't make the same >> mistake. We want to see how things pan out as game devs start hitting the >> GPU for compute on next-gen architectures. Right now we think it could be >> awesome, but we're waiting to see what devs tell us before we go further. >> >> In the meantime we will continue to push on KL rigging and procedural >> animation (along with our production RT renderer). I see some genuine >> convergence of game and VFX now, certainly for the way we think about things. >> >> >> On 3 August 2013 13:35, Matt Lind <[email protected]> wrote: >>> <quote> >>> I think you're pretty off on the games figures Raff - I'd say current/last >>> gen was 50/50 (with a lot of Soft still in Japan). However, AD made clear >>> that Maya = Games a long time ago. Skyline was Maya only, and all the >>> middleware stuff has been Maya-first/only. Next-gen pipelines are >>> interesting because the amount and quality of content required is getting >>> close to the problems film faced a decade or more back - how are we going >>> to create and author all of this content? I think this gen is going to be >>> all about game engine content creation tools rather than export pipelines. >>> >>> On a related note - take a look at the PS4 and XBone architecture, then >>> look at HSA. We're excited :) >>> </quote> >>> >>> >>> I agree. >>> >>> Having working in games on and off since the mid 1990’s, I’ve always worked >>> on titles using proprietary engines. The single biggest hurdle is the >>> iterative turnaround time to make an edit to content and see it in the >>> engine. No 3D application will solve that problem – not even a super-Maya. >>> >>> What is needed is a library that can seamlessly integrate with both the >>> engine and artist content creation tools which acts as a bridge between the >>> two environments and also provide a true 1:1 what you see is what you get >>> workflow. >>> >>> The library needs to be easy to integrate, agnostic to platform, and rich >>> enough to provide all the functions artists expect. Developers need >>> something that is extremely light, easy to manipulate, and doesn’t require >>> them to rework their code to accommodate, but can still be abstracted away >>> from the engine so it doesn’t become a licensing and distribution issue >>> when it comes time to ship the game. >>> >>> Something like Fabric Engine is much closer to the mark, but I think that >>> last point will be a sticking point of contention. >>> >>> Matt >
