Hi everyone - we're gearing up for Siggraph, so I wanted to give a preview of what we'll be showing and let you know we'll be in LA the week before the show for meetings/meeting up.

Creation Platform - you'll see us referring to Creation rather than Fabric. Creation is the name we're giving to the Python/Qt framework and associated modules. Fabric Engine = the core execution engine. Creation = the elements on top of FE for building graphics applications/tools. Hopefully it causes less confusion now

Subdivision performance: https://vimeo.com/45316255
Jerome has been working hard on our new subD implementation. We're doing some of the processing on the GPU now, and getting excellent performance. GPU computation is an area of focus and we aim to build on this first implementation. We're seeing performance around 35 times faster than on Maya 2012, which you'd expect with GPU (we're around 2-3 times faster purely on the CPU). This is on a laptop GPU so we'd expect a significant boost on workstation cards.

Streaming mocap data/live retargeting - https://vimeo.com/45323370
Phil's been working on our mocap tools, and here he shows the new full body retargeting system working with the OptiTrack Arena platform and a RocketBox character.

Asset Browser - https://vimeo.com/45259333
Helge put together a demo of how powerful Creation can be for things like asset review of mocap data, 3D assets, LIDAR data, video etc.

Siggraph/LA - we're available for meetings in L.A from the 1st to the 9th August. So drop me a PM if you want to see us

Comments/questions most welcome. We're still in beta, so email me if you'd like to sign up (beta@fabricengine.com).

Cheers!

Paul

p.s. I'll be reposting this in a few forums

Moderator edit - Cleaned up the tags - HB

Node Graph API didnt make it into this release Paul?

Hi - it won't be a v1.0 feature. If/when we move to areas where that workflow makes sense over code (particles/simulatiion etc) then we'll push on it.

Wow! I have to admit I'm starting to get really excited about this project. And I'm so curios where this is all heading, let's hope it can become a real game changer....

This looks better and better. Keep up the good work on this!

I noticed that there was a lot of critique about the name of the project but I think it's very fitting and has a good sound to it. Just saying.

I am really intrigued by fabric engine. I just wish I could 'get it' properly.

I wish there was a few examples on the site of the scope of what you could make with it and what that would entail. I feel like its the sort of thing I would want to learn (along with Python), It it would enable me to make, say a live facial mocap retargetter That could stream to motion builder or other standalone apps.
Is it like ICE? if there were a standalone nodal ICE-like programming tool I'd buy it like a shot.
I've had it explained to me before but it's still not completely sunk in, despite watching all the videos and reading all about it.

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.

Cheers,

Paul

What make ICE so popular and the reason why people like me or Paul want to see the visually represented code is that we see the benefits of it over straight lines that expirenced programmers like you guys do not think of.

The reason why ICE is so awesome:

1. Speed of development. You can open a window, drag with only one mouse button few nodes and get a working prototype within of few minutes. You shouldn't type a full name of a function with classes and run it to get an error for typo or missing colons/indentations.

2. Debugging. When you write lines of code you can't see changes until you hit compile or run (which is dynamic compile still) button. You can't see the changes immediately or with respect of time change for various parts of the code, switching between different debug modes for values that you choose to display while deleting existing functionality and connecting new one.

3. Sharing. Reinhard's site is perfect example how tools that people made can be found easily. You mention that everything will be extended via code of other people, you should create a centralized resource for plugins then, like openFrameworks have for example, so everyone who interested in using your framework can acces all the other stuff for it from one page.

Autodesk can't take such a risk decisions in those areas because of size of their products and features that they should make to sell each release, but since you're not a big monster that don't know code of your product, you can experiment with it, by not making things looks cool on a video but rather help debug and speed up development time for your customers so we can grow and share with each other more effectively.

Here is the link that can help you understand more deeply why are this things so important, since it Creation Platform: “Creators need an immediate connection to what they create.”

Thanks for the reply. Four of our engineers were involved in developing ICE, and I spent about a year selling/evangelising it So we get where you're coming from - visual programming can be very powerful. I have a few responses:



Sure - rapid iteration is great. However - when developing more involved applications, the nodal approach can become a spaghetti mess. There are times when code is the better approach. Especially if the code is scripted rather than compiled.



Creation provides some very nice debugging tools (including a graph representation of the application), and also supports dynamic recompilation from the debugger view. So you can change a running application and see the changes immediately. Over time we will introduce more tools that will enable faster development/debugging.



Yes I agree - when we launch we will provide sharing/community tools.

I guess the way to think about it is this - right now you need to be a programmer or a strong TD with Python/Qt skills to get the most out of Creation. As we progress with our development, it will become more and more accessible to less technical TDs and TAs. Our start point cannot be the highest level of abstraction without inherently constraining ourselves - we decided we wanted to provide performance and breadth first. I hope that makes sense.

Paul

p.s. I've seen the video before, it's a good talk. You might enjoy this - http://video.google.com/videoplay?docid=-8860158196198824415&ei=DAZ-SbyhA5jY2gLZjuinBQ&q=growing+a+language# - it's very clever and I find it fascinating

Newcomer (<20 posts) alert: please use the URL tags - HB

Yes, I know, and I think everybody should know it, that's why I'm more looking forward to what you guys are doing


Yes, it does and a lot! Thanks for that, I really appreciate this decision since you cannot build layer of abstraction on a slow core functionality indeed.

And thanks for the keynote! I'm watching it right now

P.S. Only imagine AD CEO answering the questions on a forum and talking about development decisions!