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]>> 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]>> wrote:
On 21 June 2013 18:33, Raffaele Fragapane <[email protected]
<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!
