Cool. You´re already there.
I guess the reason why the general plattform is less easy to sell than the modules is that it needs a bit more abstraction to see the benefit of investing into it in comparison to a module that either already does solve a specific problem or seems like a good basis to start modifications off from. It requires a lot of faith to start from scratch. Maybe it feels more comfortable to blunder along some more predefined lines for the first steps instead of blindly jumping into the bandwaggon? I´m a bit sad you don´t give away Dunce Caps, thought. Seriously. Cheers, tim On 22.06.2013 16:45, Paul Doyle wrote:
Hi Tim - thanks for the lengthy response. I think you've missed a few things: - the Dunce Cap was a joke about Raff's comment re: our messaging makes it sound like TDs are dumb: http://en.wikipedia.org/wiki/Dunce_cap - it wasn't a promo. - Fabric Engine is the name of the company, it is not a product - Creation Platform is a _platform_ - it is not another DCC application, it is not a turnkey solution. It is a tool for building tools. It is a product for technical people to make it easier for them to build better tools for production. - Have you looked at our Creation Modules (Stage and Horde)?http://fabricengine.com/creation-modules/?preview=true&preview_id=3847&preview_nonce=ac8d70f550 - Stage is a scene assembly tool which does everything you mention and a ton more. This is the first statement on our website: "Creation is a powerful framework that reduces the cost, risk and time required to build custom production tools. Creation can handle a wide range of needs, from image and video processing through to 3D animation and lighting. Creation Modules provide targeted solutions for complex areas such as crowd simulation, procedural locomotion and scene assembly." Having spent the best part of 20 years selling (and then product managing) software (Alienbrain, Avid, Softimage, Autodesk, Fabric) I have a good sense of what the buying process looks like. With technical products there are always two tracks - the technical sell and the business rationale. If you start at the decision maker level, it just gets kicked to the technical team (who have a veto on buying tools). Successful sales come about because the technical team are convinced it's the right solution, and they build the business case themselves. Vendors can help them to do this to a point, but successful deals always happen because the tech team have bought into it first and sold it to management. Splice and the modules are a lot easier to sell than the general platform - it's just very hard to describe what it can do, because it can do so much. My expectation/hope is that Splice will help us better frame the story - we shall see :) Thanks again for taking the time to comment, Paul On 22 June 2013 00:50, Tim Leydecker <[email protected] <mailto:[email protected]>> wrote: Paul, one more thing (in disruptive Columbo style). > We are giving free dunce caps with every purchase Incentive caps are nice but what exactly is the immediate benefit of buying a FabricEngine license and your POS (Point of Sale)? Don´t get me wrong. I really like the honest approach you sport her, not only when sharing your frustration about having created a very open, flexible framework that can also provide interoperability and data transfer between major content creation application and is readily accessible to a large userbase fluent in Python but also having even researched more and listened to feedback by going to all the places and talking to all the guys tasked with solving exactly the problems you could really help with very, very well. Unfortunately, most of these guys don´t have final purchase decision. That was a long sentence and a pretty tough pill. In short. How about a bell that rings with management? What can FabricEngine do now, out of the box? Is it convenient to use? Is it a turn-key option to swap a dataset with Maya/Houdini/XSI/3dsMax/__Cinema? Here´s my personal feedback (you need feedback, to see how your potential clients see you). I like the demos you regularly come up with, Treebuilding, Muscledeformer, Crowds. I can remember them. I can remember you have a viewport that can display 3D data. Would it be an easy to fill niche for you guys to set up an *alembic* scene builder, where you can collect assets, check in an additional assets like that *.fbx that came just in, read/write out asset collections, maybe even write out container formats like *.ass/OpenVDB or mix and repackage them? You see where I´m heading? I´m stripping your framework down to a fileviewer than can batchprocess, actually, it´s a full blown data editor. It´s a easy to use framework, too. That would be one of the many possible POS. Regardless if you use the new UnrealEngine(*.fbx), Arnold(*.ass) or Houdini(*.OpenVDB) or FumeFx for Maya and 3dsMax. It even supports Softimage ICE. That would be the out of the box turn-key benefit. And that´s it for tonight. No patronizing intended. I just think you deserve your chance to sell your idea. Cheers, tim On 22.06.2013 03:41, Paul Doyle wrote: We are giving free dunce caps with every purchase Sent from my iPad On 2013-06-21, at 9:32 PM, Raffaele Fragapane <[email protected] <mailto:[email protected]> <mailto:raffsxsilist@__googlemail.com <mailto:[email protected]>>> wrote: That's why I chose to say it's my gripe with it, and not a level criticism that you should take to heart in any way if you want to sell a single license ;) You have reason to be happy when the worst thing I can bring up about the platform is a personal bias in hearing the videos :p On Sat, Jun 22, 2013 at 9:58 AM, Paul Doyle <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>__> wrote: On 21 June 2013 18:33, Raffaele Fragapane <[email protected] <mailto:[email protected]> <mailto:raffsxsilist@__googlemail.com <mailto:[email protected]>>> wrote: If anything my only gripe with fabric right now is that they keep referring to TDs as the slow children of RnD, as if being a TD means you can cobble together a script as long as you can chain run it to debug, but God forbid you'd be able to run a compiler :p There's a big difference between a trained software engineer that can write multithreaded C++ and the standard TD (that I see most consistently across studios) that can write a bit of C++ but is most comfortable with Python/MEL etc. Finding a domain expert in software engineering that's also a domain expert in VFX is quite challenging - most TDs do not fit this description. What we see is a lot of people that know exactly what they want to achieve, but don't have the time, inclination or skillset to write it in C++. That might not fit your definition of a TD, but outside of large studios I don't meet many TDs that are C++ programmers - they self-identify as such. You're correct in saying that the actual value of KL is in the various multi-threading paradigms (and the ease of access to them). However, having spent the first 18 months of our existence trying to market a language and a multithreading engine, we realised that nobody cares :) Instead we simplified the technical message to "KL is a high-level language like Python, these are normally slow but KL is as fast as highly optimized C++. This means people that are comfortable with high-level languages can now write high performance code". In reality, nobody cares about that much either. What people want to know is "so what can I do that I couldn't do before?". So it might end up being a bit simplistic or patronizing to people that understand the technology, but the intent is to try and make it easy to understand why what we're doing is valuable. Marketing a platform to everyone is difficult - if we make it so technical people are satisfied from the outset, then we lose everyone else. Now we're showing actual solutions, it becomes more interesting to understand 'how?' - so we might have to adapt a bit. You'll be pleased to know we're working with a PR agency who want to rewrite all of our copy :) The last thing I'll say is that the dynamic compilation is as important as the multi-threading - speed of development, ease of deployment, portability of code and outright performance. We used to message heavily around this and it didn't get us very far. -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
