Introducing Canvas - visual programming for Fabric 2.0

[FabricPaul]

Hi guys - we're really happy and proud to give you the first proper look at Canvas, our visual programming system for Fabric 2.0.

Quick highlight video:



Tons more information here: http://fabricengine.com/canvas-videos/

This is the first part of the FE2.0 plan, and we'll be showing this in more detail at GTC on March 18th - please contact me if you want to meet up.

Looking forward to hearing what you have to say, and hopefully getting you on the alpha/beta when we open things up (there is a sign up form on the Canvas page).

Cheers,

Paul and the rest of the Fabric team

[FXDude]

At first glance, it looks very much like ICE at least in most important aspects.
(seemingly a closer alternative to ICE than what Bifrost would become (and years sooner) and seemingly closer than Houdini)

But In your opinion (if you could be as objective as possible ;) ) what are currently the differences, or pros and cons?
while of course considering it's very early.

Some things looked like alot of nodes for somewhat simple functions,
but I assume there will eventually be many "presets" made factory or made by others.


A few questions if I may,
1- Is generated geometry "real"?, to tweak it or otherwise treating it as regular geo, applying properties etc.. ?

2- And it looks like you started with geo before particles, but I assume that like ICE wasn't a big stretch to cross over from particles to geo, that it is also the case here but going the other way. (?)

How about UV's, ... driving DCC parameters... other reaches..


3- And.. as you might have guessed, what about Softimage?

We are of course already pretty well served there with ICE, but at least for authoring for or in several environments and interop, how do you go about connecting things to "outside" in Soft ?


4- And lastly, Is this the announcement you were recently alluding to here (at the end of a Houdini thread if I recall)?

I imagine that it is, not being a small thing, but if not, I would have hoped it would be that you finally decided to make your own DCC,

Because you are in such a perfect position to do so...
and because many find that Maya is in many respects really not the ideal environment they would have hoped for to say the least, very-much including myself,
(many considering themselves 'forced' to use it for lack of better term, or for lack of solution that could be "as powerful" but much (MUCH!) more artist-friendly, or just not completely unfriendly, awkward, or difficult, with meager hope of that ever changing in a truly significant way.)

In any event, thanks (and congradulations!)

[MauricioPC]

Do you guys intent on putting canvas on 3ds Max as well? I can see lots of Max TD FX taking advantages of this.

Hell .. I never wanted to learn scripting, but I kind of want to play with that. Looks very cool and way less complex for the beginners (it seems).

[FabricPaul]

At first glance, it looks very much like ICE at least in most important aspects.
(seemingly a closer alternative to ICE than what Bifrost would become (and years sooner) and seemingly closer than Houdini)

I don't know much about Bifrost beyond the public videos, but clearly it's a powerful system that could/should be complementary to Fabric. There's inevitably some overlap, but that's true of Fabric within any environment.

As for ICE, it's been a long time since any of our team worked on that project - obviously there's going to be some affinity as we liked what that team built, but this is a visual programming system built around Fabric and KL. There are a few Softies on the alpha group so I expect them to make comment as they get to grips with Canvas.

But In your opinion (if you could be as objective as possible ;) ) what are currently the differences, or pros and cons? while of course considering it's very early.

That's a really lengthy topic that I would rather someone like EricT covered I also don't want to get into 'but ICE can do that...' conversations. ICE is a great system, but unfortunately it's stuck within Softimage. The biggest differences that I usually raise:
1) Fabric was designed as a general compute engine that we then built a 3D layer on top of. ICE started out as a particle system that became more generalised over time. Fabric is extremely broad and can tackle any processing task. People tend to hit certain limitations with ICE due to the original purpose of the design.
2) ICE is extremely well-integrated within Softimage. Fabric is more like Bifrost (my understanding at least) in that it is a self-contained unit that is being accessed through the host application. This means that...
3) Fabric is completely portable. We can move data and the tools for working on that data (including manipulation etc) between Spliced applications and inside our standalone C++ application. The downside is we can only be as integrated as the host SDK allows us to be.
4) Openness - everything bar the core engine is written in KL, which is human-readable. You can change pretty much any aspect of the system.
5) Extensibility - you can open any node and edit the KL code directly. You can create new nodes by writing KL. Those nodes will be as performant as any preset we provide.
6) Performance - Fabric is extremely fast. With transparent GPU compilation we are able to leverage GPUs for compute without requiring you to do anything other than write KL.

There are much more significant technical differences but I won't cover that here.

Some things looked like alot of nodes for somewhat simple functions,
but I assume there will eventually be many "presets" made factory or made by others.

Sub-graphs (kind of like compounds, but doing some other interesting things) aren't in this alpha - when you see what we're doing there I think you'll be impressed.

As for what we ship with, I'll cut and paste a response I wrote elsewhere:

The Data Flow Graph that Canvas is built upon is written entirely in KL (Fabric's language that enables us to hit the performance targets we set). What this means is that any node in the graph can be opened and edited directly - it's all KL. This in turn means we were able to write a tool to automatically generate Canvas presets from existing KL code. It means that the preset library for Canvas is extremely rich, as we were able to go through 4 years of our own code to build it. (more info here: ).

Where it gets a bit crazy: we have a tool (KL2EDK) that automates a lot of the wrapping process for C/C++ libraries and exposes them fully within KL. So with this new KL2DFG tool we can wrap a library and then generate a visual programming interface to it, and then run that within any host application (and our standalone). There are some very cool demos coming soon that show this in action.

A few questions if I may,
1- Is generated geometry "real"?, to tweak it or otherwise treating it as regular geo, applying properties etc.. ?

2- And it looks like you started with geo before particles, but I assume that like ICE wasn't a big stretch to cross over from particles to geo, that it is also the case here but going the other way. (?)

How about UV's, ... driving DCC parameters... other reaches..

Geometry is real, yes. I think the coil demo shows changes being made etc.

Fabric can already do particles (nothing like ICE though, yet), we just didn't see it as an interesting start point for Canvas Remember, Canvas is just a new front end for Fabric. Everything that we could do before, we can do in 2.0.

3- And.. as you might have guessed, what about Softimage?

Yes, we need to do this soon as we have key customers using Softimage. We hit Maya first because it's pretty much ubiquitous, but we will be supporting a range of DCCs. Fabric is free and easy with who it sees

We are of course already pretty well served there with ICE, but at least for authoring for or in several environments and interop, how do you go about connecting things to "outside" in Soft ?

You can look at the existing Splice integration into Softimage to see how we do it.

4- And lastly, Is this the announcement you were recently alluding to here (at the end of a Houdini thread if I recall)?

I think so I can't think of anything else on the radar...

I imagine that it is, not being a small thing, but if not, I would have hoped it would be that you finally decided to make your own DCC,

Because you are in such a perfect position to do so...
and because many find that Maya is in many respects really not the ideal environment they would have hoped for to say the least, very-much including myself,
(many considering themselves 'forced' to use it for lack of better term, or for lack of solution that could be "as powerful" but much (MUCH!) more artist-friendly, or just not completely unfriendly, awkward, or difficult, with meager hope of that ever changing in a truly significant way.)

This comes up a lot, but I am fundamentally opposed to Fabric attempting to become a Maya replacement. Fabric is a platform for other people to build upon. Building an entire DCC is a colossal undertaking - so someone may come along and want to license Fabric to build their own DCC, but it's not something Fabric will do itself.

There are thousands of highly-trained artists that are familiar with Maya, Max, Softimage, Houdini, Modo, C4D etc etc. I just don't see the big opportunity there. I spent a lot of time trying to sell Softimage against Max and Maya and there is just a massive inertia around DCCs once they are in a pipeline. What Fabric seeks to do is make it easy for people to work within those applications and solve certain problems (performance, R&D portability). Our standalone makes it feasible for a small team or an individual to build very powerful, specialised tools.

We're opening up the 3rd party developer program soon, and I hope that will lead to more and more artist-level tools built with Fabric. Some of the things our customers are building in production are mind-blowing

In any event, thanks (and congradulations!)

Thanks - it's been a tough 15 months or so to get here (that was when we started on 2.0) but now we're at the fun part of seeing people build with it. It should be a fun year

[FabricPaul]

Do you guys intent on putting canvas on 3ds Max as well? I can see lots of Max TD FX taking advantages of this.

Hell .. I never wanted to learn scripting, but I kind of want to play with that. Looks very cool and way less complex for the beginners (it seems).

Yes absolutely. Now we've done the Maya integration we have a good start point for the other integrations. One thing that we didn't like with Splice in Fabric 1.x was that the integrations were very different in each DCC. We are aiming to have something much more consistent in 2.0.

I won't commit to public timelines on this, but the work will start soon.

[pluMmet]

Well it's crazy annoying that all the listed integration support is AD specific...

"The Splice API lets you run Fabric Engine inside of your existing applications – right now we support 3ds Max, Maya, Softimage and Arnold, with more to come"

Moving away from programing restrictions by making them work with the most restrictive stuff is counterintuitive IMHO.

[FabricPaul]

Watch this space

[Draise]

I hope someone will splice this into blender or unreal, we'll since they have open sdk!

Thank you for all the answers. This clearly opens doors into the future.

[nodeway]

1. When 2.0 will be available for normal people?
2. Will there be also individual free license like with 1.0?

[FabricPaul]

1. When 2.0 will be available for normal people?

We're in alpha now. We're going to open up to more and more people through the request form here: http://fabricengine.com/canvas-testing-program/

I can't say when it will be released as that depends on how well the alpha/beta goes. But I expect anyone to be able to jump on the beta within a few months i.e. it will just be downloadable off of our site. The closed alpha/beta is just so we can manage the support load while we iron out the kinks.

2. Will there be also individual free license like with 1.0?

Yes of course The Fabric50 program will still be going as well. We're committed to people having easy and free access to our tools.

[Manticor]

I have a question about the standalone stuff as you deprecated the python scene graph a few versions back ... just as i was starting to learn it
Will it be possible to add/build UI elements/gizmos and other things like weight painting tools with canvas ?
And will there be a "from scratch " tutorial for building standalone applications ? ... as I couldnt find any tutorials about the old scene graph( maybe I wasnt looking in the right place)

[FabricPaul]

I have a question about the standalone stuff as you deprecated the python scene graph a few versions back ... just as i was starting to learn it

It was too complex for our customers to deploy, so we decided to pull it as everyone was just using Splice anyway (and we knew that 2.0 was coming - admittedly a little later than we planned!)

Will it be possible to add/build UI elements/gizmos and other things like weight painting tools with canvas ?
And will there be a "from scratch " tutorial for building standalone applications ? ... as I couldnt find any tutorials about the old scene graph( maybe I wasnt looking in the right place)

Some of the logic running inside of a tool (like raycasting for painting) can be handled using a Canvas graph. For tools and gizmos there is also some code involved, at least for the first drop of 2.0. Over time this stuff will get more and more artist-friendly.

Yes there will be tutorials for the standalone framework. This is something we'll expand on when we push the 3rd party developer program, as obviously people will need to know how to do it

[pluMmet]

Watch this space

Absolutely

[FXDude]

I imagine that it is, not being a small thing, but if not, I would have hoped it would be that you finally decided to make your own DCC,

Because you are in such a perfect position to do so...
and because many find that Maya is in many respects really not the ideal environment they would have hoped for to say the least, very-much including myself,
(many considering themselves 'forced' to use it for lack of better term, or for lack of solution that could be "as powerful" but much (MUCH!) more artist-friendly, or just not completely unfriendly, awkward, or difficult, with meager hope of that ever changing in a truly significant way.)

This comes up a lot, <-- I absolutely have no doubt about that.

but I am fundamentally opposed to Fabric attempting to become a Maya replacement.

Fabric is a platform for other people to build upon. Building an entire DCC is a colossal undertaking
- so someone may come along and want to license Fabric to build their own DCC, but it's not something Fabric will do itself. <-- Why?

Colossal (to a certain extent) perhaps, but as an example, Exocortex did it... (with a small team)
"Clara.io Grows to 100,000 Users in just 600 days"
and they seem to be doing pretty well to say the least (!) (I personally wished they weren't web based)

But in either case, weather from yourselves or a 3rd party,
*non-awkwardness* being quite noticeably a clear trend, or at least a very big priority for "future software"
just by looking at what studios develop themselves (pick any one) , ... or what new things like Akeytsu (or Clara.io) are like,
to a certain extent also being one the first things many that are at the heart of the industry are waiting for,
... waiting for something like that to become available to a wider public.

And you just made something that works (most) with some "the worst" (despite the most standard) of them in those regards.
(while seemingly having no problem about that)

There are thousands of highly-trained artists that are familiar with Maya, Max, Softimage, Houdini, Modo, C4D etc etc.
I just don't see the big opportunity there.
I spent a lot of time trying to sell Softimage against Max and Maya and there is just a massive inertia around DCCs once they are in a pipeline.

Perhaps but "thousands" also watch American Idol and "Jackass" (or (whatever) things are the most pushed/publicized).

And Difficult to introduce different tools to existing pipelines?
While that also surely may be true, not to mention being exactly why **forced** migration is really not cool, respectful, or at-all 'right'...

but all up until 2008, Softimage was very-much in the midst of an exponential growth,
(had posted some XSIBase stats on the list about that)
... all the way up until ICE which would otherwise normally have (absolutely) further accelerated that trend, had it not been for the almost simultaneous aquisition.
(what probably motivated that very move, and also putting an emphasis on such growth happenning *before* ICE or it not being ICE-centric )

Nevertheless, I'm convinced that this growth was because the obvious can only be ignored for so long, which made for lots of **VOLUNTARY** migrations to XSI.

What Fabric seeks to do is make it easy for people to work within those [ comparativley awkward and counter-intuitive ] applications
and solve certain problems (performance, R&D portability) [ but not counter-intuitivity ] .

Our standalone makes it feasible for a small team or an individual to build very powerful, specialised tools.

We're opening up the 3rd party developer program soon, and I hope that will lead to more and more artist-level tools [ or an *artist-level* standalone platform (!) ] built with Fabric.

You said earlier...

There's inevitably some overlap, but that's true of Fabric within any environment.

And that is precisely what seems to be what you are actually mostly fundamentally opposed to.. *overlap*


Bending, compromising or being at the mercy of Market demands... ending-up being to a certain extent controlled by it.. which reminds me of yet another very new (and highly coincidental) release...



Which I guess could apply to any choice purely or mostly based on "popularity".

[FabricPaul]

Thanks for taking the time to get your thoughts down. I'll answer as best I can

colossal (to a certain extent) perhaps, but as an example, Exocortex did it... (with a small team)
"Clara.io Grows to 100,000 Users in just 600 days"
and they seem to be doing pretty well to say the least (!) (I personally wished they weren't web based)

Which productions are using those tools? I don't know how Ben measures usage, but for reference there are about 100,000 total users of DCC software in professional M&E. So I think it's more a case of pulling in web users and other groups than any sea-change within our market. I could be wrong, but that's my take on it.

Clara is in no way even close to the full feature set of Max/Maya/Softimage et al, and I don't see it being targeted at the same market (professional studios). That might be the long-term plan, but I suspect there's a far better opportunity for Ben in the web space. He would have to speak to that.

To be clear - I think Clara is really interesting and I think there's a good opportunity in web-based content creation and deployment. But that's not what we're talking about here.

But in either case, weather from yourselves or a 3rd party,
*non-awkwardness* being quite noticeably a clear trend, or at least a very big priority for "future software"
just by looking at what studios develop themselves (pick any one) , ... or what new things like Akeytsu (or Clara.io) are like,
to a certain extent also being one the first things many that are at the heart of the industry are waiting for,
... waiting for something like that to become available to a wider public.

Studios are adopting Fabric because it makes it cheaper/faster/easier to build on top of it. We are now expanding our reach with Canvas. The third party developer program will make it possible for people to build, deploy and sell their Fabric applications. The standalone framework is there for people to build specialised tools and workflows, and I hope to see those kinds of applications sooner rather than later. What is attractive for devs is that those tools will also run within a wide range of other applications.

And you just made something that works (most) with some "the worst" (despite the most standard) of them in those regards.
(while seemingly having no problem about that)

I have no problem with it at all. It's what our customers want us to - I have hard evidence from my time at Softimage and also my time at Fabric pre-Splice: studios do not want to replace their existing applications. They want to improve and enhance them. What we offer is a path between all of these applications, and to a specialised standalone when it makes sense.

but all up until 2008, Softimage was very-much in the midst of an exponential growth,
(had posted some XSIBase stats on the list about that)
... all the way up until ICE which would otherwise normally have (absolutely) further accelerated that trend, had it not been for the almost simultaneous aquisition.
(what probably motivated that very move, and also putting an emphasis on such growth happenning *before* ICE or it not being ICE-centric )

Nevertheless, I'm convinced that this growth was because the obvious can only be ignored for so long, which made for lots of **VOLUNTARY** migrations to XSI.

Softimage was not in exponential growth, not remotely. I was there, I was in sales in EMEA and then in N.America - I know how often we converted a Max or Maya studio to XSI, and how often we had to deal with Max or Maya coming into our key accounts. I think that ICE might have created a new glory period for Softimage, but I'm not sure - the inertia was already in favour of Maya and Max. Perhaps if we had been able to execute on the ICE roadmap things would have been different - but it's moot now.

And that is precisely what seems to be what you are actually mostly fundamentally opposed to.. *overlap*


Bending, compromizing or being at the mercy of Market demands... ending-up being to a certain extent controlled by it.. which reminds me of yet another very new (and highly coincidental) release...

I'm opposed to trying to make a 'me too' application that will not compete. Displacing existing DCCs is a bad strategy and I'll repeat - our customers do not care about that. Our very first product meeting with a massive west coast studio we had the statement "I don't understand why you don't just put this in Maya". And we said to ourselves "man, these guys just don't get it", and we kept pushing our vision. And after 2-3 years we realised that we should have listened, because as soon as we even mentioned Splice we had people getting really excited.

There's a phrase in product management: "for a new market entry to succeed, it must be ten times better in at least one important regard". I don't believe that's remotely viable, even if we had the time, inclination and budget to attempt it.

Fabric is a business, we have to pay our developers and we have to deliver what our customers want to see from us. We also have to look at market trends and opportunities and decide where we want to place ourselves. We decided to place ourselves alongside rather than against all the existing players out there. I think Splice showed that over the past 18 months and you'll see much on this theme over the next few weeks and months.

TL;DR: I believe trying to build a complete DCC with Fabric is a terrible idea. I also believe we can empower a lot of developers to build useful 'low friction' tools that run both inside and out of existing DCCs.

[FXDude]

Thanks for taking the time to get your thoughts down. I'll answer as best I can

colossal (to a certain extent) perhaps, but as an example, Exocortex did it... (with a small team)
"Clara.io Grows to 100,000 Users in just 600 days"
and they seem to be doing pretty well to say the least (!) (I personally wished they weren't web based)

Which productions are using those tools?

I don't know how Ben measures usage, but for reference there are about 100,000 total users of DCC software in professional M&E. So I think it's more a case of pulling in web users and other groups than any sea-change within our market. I could be wrong, but that's my take on it.

I agree. Perhaps that figure may also count the users subscribing for logins to try it.

Clara is in no way even close to the full feature set of Max/Maya/Softimage et al, and I don't see it being targeted at the same market (professional studios). That might be the long-term plan, but I suspect there's a far better opportunity for Ben in the web space. He would have to speak to that.

To be clear - I think Clara is really interesting and I think there's a good opportunity in web-based content creation and deployment. But that's not what we're talking about here.

I also agree that It's a different thing for a different market, and that it's comparatively limited to a certain extent,
... limitations that are due to it being web based IMO, which is why I wished they weren't,
yet as you say, -for- a web based app... it's pretty incredible what they managed to do (!)

But the point was that weather web based or not, it is a self contained and at least a somewhat complete platform,
(while getting more complete) ,
and also to say how "colossal" can be relative, in this case working over a severely limiting medium,
and was also a reference to it's "friendliness".

But in either case, weather from yourselves or a 3rd party,
*non-awkwardness* being quite noticeably a clear trend, or at least a very big priority for "future software"
just by looking at what studios develop themselves (pick any one) , ... or what new things like Akeytsu (or Clara.io) are like,
to a certain extent also being one the first things many that are at the heart of the industry are waiting for,
... waiting for something like that to become available to a wider public.

Studios are adopting Fabric because it makes it cheaper/faster/easier to build on top of it. We are now expanding our reach with Canvas. The third party developer program will make it possible for people to build, deploy and sell their Fabric applications.

The standalone framework is there for people to build specialised tools and workflows, and I hope to see those kinds of applications sooner rather than later.
What is attractive for devs is that those tools will also run within a wide range of other applications.

Here I don't think you addressed basically any of the points I made, which doesn't come to any surprise, because I think this concerns the very crux of the main issue.

And you just made something that works (most) with some [of] "the worst" (despite the most standard) of them in those regards.
(while seemingly having no problem about that)

I have no problem with it at all. <-- [ and I think that if I have a problem with Fabric, it would be Fabric not having a problem with that ;) ]
It's what our customers want us to - I have hard evidence from my time at Softimage and also my time at Fabric pre-Splice: studios do not want to replace their existing applications. They want to improve and enhance them. What we offer is a path between all of these applications, and to a specialised standalone when it makes sense.

Here I truly believe you are referring to customers that have mostly or only ever experienced Maya.
(and there are no doubt -lots- of those)

but all up until 2008, Softimage was very-much in the midst of an exponential growth,
(had posted some XSIBase stats on the list about that)
... all the way up until ICE which would otherwise normally have (absolutely) further accelerated that trend, had it not been for the almost simultaneous aquisition.
(what probably motivated that very move, and also putting an emphasis on such growth happenning *before* ICE or it not being ICE-centric )

Nevertheless, I'm convinced that this growth was because the obvious can only be ignored for so long, which made for lots of **VOLUNTARY** migrations to XSI.

Softimage was not in exponential growth, not remotely. I was there, I was in sales in EMEA and then in N.America - I know how often we converted a Max or Maya studio to XSI, and how often we had to deal with Max or Maya coming into our key accounts. I think that ICE might have created a new glory period for Softimage, but I'm not sure - the inertia was already in favour of Maya and Max. Perhaps if we had been able to execute on the ICE roadmap things would have been different - but it's moot now.

I don't know, but I was exclusively referring to the amount of Job posts, (almost doubling every year)
followed by a sudden sharp and steady decline post acquisition (despite sumultaneous ICE introduction)

And how often did you have to deal with (either) Max or Maya coming into key XSI accounts?
As far as I could tell, most of every place (or individual users) that adopted XSI, never really looked back (for some reason).

And that is precisely what seems to be what you are actually mostly fundamentally opposed to.. *overlap*

Bending, compromizing or being at the mercy of Market demands... ending-up being to a certain extent controlled by it.. which reminds me of yet another very new (and highly coincidental) release...

I'm opposed to trying to make a 'me too' application that will not compete. Displacing existing DCCs is a bad strategy and I'll repeat - our customers do not care about that.

How about one that would more than absolutely compete..
which is what can be soo frustrating, seeing what you -can- do, and everything that you -do- do (!)

Our very first product meeting with a massive west coast studio we had the statement "I don't understand why you don't just put this in Maya".
<--[ ... from people that most-likely only ever experienced Maya. ]

And we said to ourselves "man, these guys just don't get it", and we kept pushing our vision.
<--[ which I think you should have done exactly that (pushing you vision) despite possible extra challenges that may invoke, if only to stay true. ]

And after 2-3 years we realised that we should have listened <--[ to people that only ever experienced Maya?.. or perhaps certain investors(?) ]

because as soon as we even mentioned Splice we had people getting really excited. <--[ no doubt, ... everything you do is nothing short of awesome! ]

There's a phrase in product management: "for a new market entry to succeed, it must be ten times better in at least one important regard".

And that is exactly what I am -convinced- whatever you would have made,
had you made a standalone solution, would not only have been 10 times less "bad" at least in some regards (if not more regards later-on),
but would have been at least a start of something that could eventually be identified as a true(r) next generation DCC in most forementioned aspects.

I don't believe that's remotely viable, even if we had the time, inclination and budget to attempt it.

I think "viability" is mosty -dependent- on "inclination" (or will) which I think is most, if not all that would have, or *would be* needed, but that's not up to me or anyone but you guys.


____________________

Fabric is a business, we have to pay our developers and we have to deliver what our customers want to see from us. We also have to look at market trends and opportunities and decide where we want to place ourselves. We decided to place ourselves alongside rather than against all the existing players out there. I think Splice showed that over the past 18 months and you'll see much on this theme over the next few weeks and months.

I have no doubt you would make more money (faster or at first) by exclusively sticking to what people
(that mostly or exclusively only ever experienced Maya) want.

But what if you had a very well based hunch as to what they would rather use after having tried it?

TL;DR: I believe trying to build a complete DCC with Fabric is a terrible idea. I also believe we can empower a lot of developers to build useful 'low friction' tools that run both inside and out of existing DCCs.

Running inside exisiting DCC's that are proven to be comparatively very "high friction" themselves when it comes to actually making thing work,
or *working fast* in a time when jobs are being exported...
(taking advantage of differing salary standards or currency valuations (to make more money) ... at the cost of (indirectly) compromising entire local economies)
.. which is the entire point of studios going the length of making their own more efficient yet powerful solutions, and to me probably currently being a pain in the ass ;)