And to throw some fanboi conspiracy theory gas into the flames:

If you integrate with all the DCC apps, you’ve essentially built up the trust 
with all the user bases and have the ability to suck them into your DCC of the 
future to reduce any and all risk of switching a production pipeline to another 
base application.

At least give us a ray of hope, Paul. ;-)


Matt


From: [email protected] 
[mailto:[email protected]] On Behalf Of Paul Doyle
Sent: Monday, August 05, 2013 7:46 PM
To: [email protected]
Cc: [email protected]
Subject: Re: OT: Yost Group - related to the Naiad/SIGGRAPH discussion

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]<mailto:[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]<mailto:[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]<mailto:[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



Reply via email to