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 > >
