Thanks for the kind words guys. A few responses:
Mossman - get on the beta and you'll be able to see where it's going
In my unbiased view, it's already a game changer
afg - the main reason for the name is to properly differentiate between the core execution engine (Fabric Engine) and the Python/Qt graphics framework (Creation Platform) that is built on top of it. The core is so broad in possible use cases that it was difficult for people to work out if it was for them or not. Creation is focused on professional graphics, so it should make it easier for people to work out who it's for. We hope so anyway!
Pooby - we're working on the things you ask for, as it's clear that people have a hard time getting a grasp on exactly what Fabric/Creation is. The problem with presenting a platform is it's inherently very broad - as you can see from the demos, we're able to build very different tools that touch on a lot of areas. Creation provides a set of building blocks that you can plug together to create the application you want - it requires a TA/TD/programmer to put the pieces together and build the UI/workflow that's needed. More technical people will build their own blocks, or change ours to suit their purposes. So it's perfectly feasible to build a live facial mocap retargeting system with Creation today - but you need to write some of the missing elements. As time goes on, we will provide more and more blocks, broadening the possibilites for TAs/TDs that can't or don't want to get involved in deeper coding.
A good example of this is the asset viewer. Helge put it together in a few days because the required blocks for viewing assets were available. For it to be useful in a pipeline, someone still has to integrate it - but since it's all Python and Qt, this isn't such a big deal.
Creation is similar to ICE in the sense that a range of technical users can work with it - we have abstracted a lot of the high-performance elements without compromising on performance. However, we do not provide a visual programming system - our experience of building ICE applications showed us that there are lots of cases where a code-based system is preferable. When you see the graph in our demos, it is a debug representation of the code - you can edit code within a running graph, but it isn't a system like ICE. It's important to note that by code we don't mean 'you have to write C++' - we're talking about Python and KL (our operator language, which is a lot simpler to use than C++). The goal from day one was to make it possible for a TD familiar with scripted languages to write high-performance applications - and that's what we delivered
As I stated in an earlier post - if and when we provide functionality that works well with visual programming, we will provide it. Most of our programming team worked on ICE and then worked on building tools with ICE, so we have a pretty good idea off how to approach VP.
Hope that helps - happy to answer more questions. It would be useful for us to know what kind of training/presentation material you'd like to see from us.