we've had some questions around Fabric's DFG vs ICE vs Bifrost (I'm assuming due to Marcus' response to an audience question). Phil posted this on vimeo in response to a question from Sebastien (
https://vimeo.com/103474550):
I found the comments from Marcus a bit confusing also, particularly the comment about the ICE graphs being hard to understand. I think he is referring to the way ICE graphs represent a data-parallel workload, meaning that many points can be being computed at once so any given connection can be computing 0-many elements at a given time. The graph therefore doesn't have a direct correlation to data-flow. Our DFG will support a pure data-flow model (as Marcus defines it), while also supporting the data-parallel approach that ICE uses. Peter refers to that concept as a 'block' in his talk, where a sub-graph could be executing on a per-element basis of a large data set. By stepping up out of a block, the user would be back into the pure-data flow graph. Marcus mentioned writing expressions and converting those to graphs. In our DFG, you can write expressions directly using KL. This KL is compiled directly into the graph.
As for pull-vs-pull, this is another case which won't change the user experience while being quite radically different under the hood. The push model is a much simpler underlying representation and is faster in some circumstances. When solving smaller problems the push model is more efficient. When operating on very large data sets (e.g. Scene Assembly), the pull model is more efficient as it avoids redundant computation.
All large graphs use the pull model, e.g. the Maya, Soft, Katana, Houdini scene graphs, while smaller tools such as solvers can use the push model.
A high level way to understand if one of our DFG graphs would be push vs Pull, would be it if compiled to run on the GPU, it would use the push model, else it would generally use the pull model. A fluid sim would be a good case for push evaluation. Either way, the user shouldn't need to know the difference.
I think things will be a lot clearer to everyone over the next few months, both Fabric and AD have a bit of work to do in explaining the differences between the myriad of different visual programming systems that are out there. In our case it's still the same core engine and KL language that we've been building for four years, so I think there is less 'new' stuff for our existing users to grasp - and also that much of what they're currently doing on FE in the meantime will be viable in the new DFG (since it's all ultimately KL). We also don't target artists directly (since we're selling a platform) so that makes it a lot easier as well.
Now we're back from Sigg you can expect to see more information and demos in the coming months. The front-end we were showing at Sigg was pre-alpha, most of our focus has been on the underlying DFG. The cool demos are on the way though
The 'Blocks' that Phil refers to are pretty damn cool, so I look forward to sharing that stuff in the future.
You can see the user group videos here:
http://fabricengine.com/2014/08/fabric- ... raph-2014/
Cheers,
Paul
