Hi guys - this is my first post here (I think I have may posted a long time ago when I was at Autodesk). I’m a co-founder of Fabric Engine (Phil Taylor of CAT is one of the other founders) - we just launched oour v1.0, but that’s not why I’m here We just released a video overview of our work-in-progress on characters http://vimeo.com/38596950
Please note that this is moving to our PyQt framework, so ignore the fact that it’s in a browser right now
We’re looking for a few things:
comments on the approach we’re taking
potential beta testers (for the PyQt framework, and then later the character stuff when it’s ready) - email beta@fabricengine.com
Hey Paul, congrats on the 1.0 release.
Ever since I got my first demo of of Fabric from Phil I through it was an awesome piece of tech.
I’m curious about the move to Qt/Python framework? Phil made it a point to note that they decided not to utilize any 3rd party GUI frameworks and stick with HTML5 and JS.
We were quite militant about web technology back then Ultimately we had to accept that the entire film/games/vfx industry has homogenized to Python and Qt for customization tools - we were spending way too much time evangelizing web technology instead of showing how powerful Fabric is. One of the biggest benefits is that you can keep working in the dynamic language you’re comfortable with, yet get multi-threaded C++ performance. Forcing people to move to html/JS lost that benefit - it created a lot of friction.
We also spent a lot of time working around browser issues (file IO, security, general flakiness) - it got to the point where we realized that the browser is a long way from being viable as an application platform. It could become a great content deployment platform, and things like the medical visualization demo have real world viability. We’ll see what happens.
Since we moved to PyQt we have been flying along - even better, our performance is close to 2X faster now we’re out of the browser.
Can you drop me a line at beta@fabricengine.com ? I’ll add you to the testing program.
Thanks for that info. I’m kind of sad and happy about the shift at the same time.
I thought the push for web tech made perfect sense, however I knew in CG industry it will meet a lot of resistance. I though that you might not be focusing on this market primarily (it’s so small) so it might not matter as much.
That said, I absolutely love Qt framework and really excited to see how the integration will go!
We spent a long time in the web space, and are still putting time and resources into Fabric on the server/in the cloud. I think that web technology is awesome in many ways, but I think that browsers suck as application platforms html apps are going to become very popular - Windows 8 gives support for desktop html, and I expect to see similar from OSX. The more likely scenario is that we’ll see the app ecosystem dominate on the desktop as it has in mobile/tablets.
So view it as a shift away from the browser rather than away from web technology The cool thing is that Fabric can be integrated with other languages and frameworks very easily (weeks rather than months).
Paul, is there a plan for the team at Fabric to develop specific commercial applications for 3d authoring, or is the plan to just focus on the platform and leave the development of applications to 3rd parties?
"It is hard to pigeon hole - we are both a developer platform and a provider of vertical stacks of industry-specific technology. We do not intend to be releasing complete applications ourselves. I’ll take a pass at explaining it. There’s a lot going on, so let me know if it’s unclear - it helps us work out how to present things on our site
What it is
There is the core of Fabric Engine - this is the multi-threading engine that takes KL code (operator code) and makes sure it runs extremely fast. This core has a compiler built into it, which is what enables us to hit performance comparable to multi-threaded C++.
On top of the core we provide integrations to different platforms and frameworks - the browser plug-in, the integration to node.js (a JavaScript server framework), the Python binding and the PyQt integration. Think of them as frameworks that can access Fabric Engine i.e. interfaces that allow you to call on Fabric Engine when you need performance.
We have an extension system for Fabric that allows people to include existing libraries - we have built a lot of these ourselves: Bullet physics, Kinect SDK, Lidar data, Collada, FBX etc
Then there are industry specific technology stacks that we are working on - so the 3D animation scene graph, the character animation tools, high-level functions for data science etc The goal is not to provide a complete application - it’s to provide an open framework for people to build on that handles a lot of the work for them and allows for extensive customization. The entire framework is open, so developers can change anything they want - there are no black boxes.
I think we probably need to have some industry specific pages (beyond the Use Cases) so that we talk about Fabric in more specific terms."
As for your questions:
we are working on industry specific technology stacks that will help people build applications - we don’t want to sell complete products ourselves. Our experience has been that every production requires a ton of custom development, so providing a ‘one size fits all’ tool is not feasible and leads to big monolithic applications. We are aiming to get people 80% of the way to a solution by providing a completely open platform to work on.
Great stuff Paul. From my own POV, I see the benefit to going the pyQt route. Less to learn from my POV ;). Agree with Sergeui that there are pluses and minuses to this move though, but for my own selfish reasons - woot.
We’re certainly seeing a lot more interest around PyQt, and it’s enabling us to work much faster since we’re not having to hack around the browser’s limitations
As for MoBu - it’s not a target for us right now, but that doesn’t mean someone else can’t make the Python sockets work. All of our code is open, so people will be able to build their own implementations. We’re doing quite a lot of work with animation, characters and pipeline so people may prefer just to use Fabric for some of the common tasks - we should have our Alembic exporter up and running soon.
What are you using for the communication layer? Plain sockets (please no)?
Also, if you’re going to show code, can you guys write something up or use a lower screen res? I couldn’t really read the text, even at HD (which loads too slow for me), which is unfortunate because this is the stuff I’m particularly interested in
Hi Rob - point taken on the code, it was probably a result of me using windows movie maker so I could stick our splash screen on the front (I cant get it to work with Camtasia Studio or Premiere). If you join the beta you get access to all the code
How this works right now: the Maya node just copies data to a shared memory space. The Python operator then fires an event in Fabric, this event causes Fabric to read the data, modify it, then put it back for Maya to read.
This solution enables a Fabric application to run inside of Maya reading and writing Maya data using our multi-threaded dependency graph. What is nice, is that the Fabric dependency graph is constructed using Python, so this means that we can use our entire scene graph description in Maya, and load persisted graph definitions etc… This opens up a lot of possibilities for TDs working in Maya who can simply use Fabric as a ‘co-processor’.
It has a couple of limitations with the free version (Max 10min Capture & WMV output only). But It will capture anything on the screen and audio output from the pc (So you can hear the code)
The problem is that our splash screen intro clip is a different resolution to when we capture - Camtasia Studio doesnt like this and only supports the res of the first clip I put in there. Premiere is impenetrable to my complete lack of skillz WMM just makes it work with a lowest common denominator approach - which sucks when showing code… We’ll sort it out. Thanks