Actually it was at Weta, although we didn't meet directly. I sat amongst others in a conference room to see some stuff. This was most likely before the release of the new tool, as I hadn't heard it mentioned at the time when people had asked about KL.
Sounds really awesome, offering the same low-level support that some people want, while catering to higher level access for TDs. On Tue, Jul 8, 2014 at 11:42 AM, Paul Doyle <[email protected]> wrote: > Hi Justin - I'm assuming we met one Sigg? > > The KL2EDK tool was introduced a few months ago as a way to speed up > wrapping existing C++ libraries as extensions. It's proven pretty popular > at MPC and saved a ton of time. It's always been possible to write C++ > extensions for Fabric, but it was quite laborious until we implemented that > tool - there's more we can add to it to make things even faster, but as it > stands it's proven useful. > > Selling to C++ programmers is a tough proposition, since you can't argue > 'now you can be as performant as multi-threaded C++' without patronizing > them. Now that we're moving into GPU compute territory it's becoming more > interesting, but generally the interest comes more around the > cross-platform/portability aspects and the 'KL as a faster Python for TDs' > - since the bottleneck of TDs->R&D can be prohibitive. > > Building a platform is not a minor undertaking :) We were quite naive but > it's really come together over the past year - now we're about to make the > jump to a new data flow graph and visual programming system and it's really > quite awesome (obviously I'm unbiased). The really good thing is that the > KL discussion becomes less important when we're looking at graphs, even > though you'll be able to jump out and author KL at any point. We'll be > showing it at Siggraph so let me know if you're about - we'll be doing user > groups all day on Tuesday of the show, should be some good sessions. > > Cheers, > > Paul > > > On 7 July 2014 17:47, Justin Israel <[email protected]> wrote: > >> Hey Paul, >> >> Thanks for joining the conversation. >> >> I had actually sat in on a demo you guys did at my studio. It looks >> really cool. Although the room did contain a number of low-level C++ >> programmers and I remember there being a negative reaction to the >> requirement of KL. Taking a glance at the Fabric docs I see there is a >> kl2edk tool that suggests support for writing extensions in C++? Was that a >> newer concept? I don't remember it being mentioned as an option during the >> demo at the time. >> >> >> >> On Tue, Jul 8, 2014 at 2:44 AM, <[email protected]> wrote: >> >>> Hi guys - Paul here, I'm one of the founders of Fabric (previously at >>> Softimage and Autodesk). Someone pinged me a link to this conversation and >>> asked if I could contribute. I hope I'm not intruding. >>> >>> Happy to answer any questions you have. There are a few points worth >>> making: >>> >>> 1) we use our own language because there's nothing out there that offers >>> what we need - the dynamic, rapid prototyping of Python with the >>> performance capability of well-written, multi-threaded C++ (or CUDA). Trust >>> me when I say we didn't want to do it but saw no other option given our >>> goals. However, it really is paying off - a TD can now write Fabric tools >>> that run on the CPU or GPU without any changes. >>> >>> 2) Fabric is not middleware. It's a standalone framework that can also >>> be run inside of other applications (Maya, Softimage, Arnold, Nuke >>> currently - Max, Houdini and more to come). Most importantly, it's open - >>> the only black box is the core execution engine, everything else is there >>> to be changed/extended/replaced as required. 'Middleware' tends to suggest >>> black boxes and opacity, which we set out from day one to avoid. >>> >>> 3) Fabric is really just a commercial version of what many studios have >>> been building for themselves for many years. We've got the benefit of not >>> being pulled in a particular direction by any one production, which means >>> the platform stays more generally useful. We offer source code access as >>> part of site licensing, which addresses many of the concerns that studios >>> have had. >>> >>> 4) Fabric is completely portable - you can move the tools/assets/data >>> between 'Spliced' applications and into the standalone framework. The fact >>> is that pipelines are heterogeneous so we do our best to play nice with >>> everyone. In some cases there's value in building a standalone version of a >>> tool, and Fabric offers that. >>> >>> 5) I can't speak for what other vendors think of Fabric, but we have >>> good relationships with all of them. We're not building a complete DCC and >>> have no plans to do so - we're just another piece of the pipeline. There's >>> an argument that we break 'lock-in' to a particular DCC, but that's >>> something that studios want and vendors have to respond to - initiatives >>> like Alembic have proven that to be the case. >>> >>> 6) we've been in operation for 4 years now, so the technology is >>> maturing well and having customers like MPC really help when it comes to >>> hardening our technology for production. It's still early days but we've >>> been out of beta for a long time now and are about to move to FE2.0. >>> >>> I hoped this helped - feel free to ping me directly if you prefer to >>> talk offline. >>> >>> Thanks, >>> >>> Paul >>> >>> -- >>> >>> You received this message because you are subscribed to the Google >>> Groups "Python Programming for Autodesk Maya" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/python_inside_maya/516a4049-0974-4b09-8a31-a5d926e42357%40googlegroups.com >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Python Programming for Autodesk Maya" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/python_inside_maya/jb0lD8SXk_M/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2PAZ7Yt24LSibG%3DPkemgYBV-00K2wpGJONuQ043xjzPw%40mail.gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2PAZ7Yt24LSibG%3DPkemgYBV-00K2wpGJONuQ043xjzPw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/CALpUA1EP6ketzkwewSqSEtPhG8vTZOKMyvSEEZNF61Fyzy3_4A%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CALpUA1EP6ketzkwewSqSEtPhG8vTZOKMyvSEEZNF61Fyzy3_4A%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA1ZNHcUsfaNPJamPYC5u0p8Sri-WebH_nyqcsXSwjAjew%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
