OpenFX implementation

[J.P. Turcotte]

Hello everyone,

This is a follow-up to this github thread: https://github.com/opentoonz/opentoonz/issues/419. I want to discuss a possible implementation of the OpenFX standard. What it would allow:

• Access to commercial and open source plugins by Genarts, BorisFX, Disney, The Foundry, Natron, GMIC, and more;
• Importing from and rendering to most formats, including professional ones such as DNxHD and ProRes, on any platform;
• Maintaining plugins separately from the software;
• Contributing to and benefiting from an active development community.

What are your thoughts, and would some of you contribute to a bounty? Thank you!

Sincerely,

J.P. Turcotte

[astr0...@gmail.com]

it's an interesting feature request, but i think it's important to fix all the small problems Ot has first.

it just crossed my mind that it will destroy compatibility with Toonz Premium.

so right now i'm against this actually.

[J.P. Turcotte]

it's an interesting feature request, but i think it's important to fix all the small problems Ot has first.

Of course, and that is why the devs decided to focus exclusively on that in the next cycle (1.1.4).

it just crossed my mind that it will destroy compatibility with Toonz Premium.

Sorry, I do not see how?

[astr0...@gmail.com]

Sorry, I do not see how?

if you make a project using these plugins, they won't be able to load in Toonz Premium. (unless they get added obviously)

[J.P. Turcotte]

Right, that is very interesting. I am not sure it has to be that way, though. Maybe it could be "baked" into the files, as layers, for example. You could not adjust all the parameters, but you could at least open and maybe even modify the files a bit. By the way, could you tell us how you use both versions together, and why keeping compatibility is important to you? Thank you!

[TurtleTooth]

I believe there are already some effects in OpenToonz that are not part of the standard Toonz- so there is already a level of incompatibility.  

[J.P. Turcotte]

Thank you for that bit of info, TurtleTooth! Yamisama on Github proposed that I ask for help on OpenFX, TuttleOFX, and Natron's mailing lists. Would that be alright, you think?

[TurtleTooth]

You bet.

[Skyler Madison]

Here's the main reason I think we should keep compatibility at all costs.

nothing stops Opentooz and Toonz from being an industry standard. The next generation of animators have access to a powerful tool here.

OT is free, so as long as a kid's family has a computer, the kid has no reason why he can't start learning to animate. Once this kid gets old enough to get a job or once this kid puts Toonz on his Christmas list, he can get it for cheaper than just about any other full featured commercial 2D application.

Once this kid gets older and becomes a professional animator, he can still open his childhood files and and keep working on them

[J.P. Turcotte]

Hey Orphanlast!

I understand what you are saying, and I would like to investigate a bit further. Here are two questions for you:

• If OpenToonz rivaled Toonz Premium in terms of functionality and stability, would you still use the latter, and why?
• What is currently missing from OpenToonz that makes you think of it as a "lesser" version of Toonz Premium?

Thank you very much for your input!

[TurtleTooth]

J.P. is correct here.  Right now the main advantage that Toonz has over OT is stability.  But there are a bunch of features that are in OT that haven't made their way over to Toonz.  If we can figure out stability, there isn't much reason for someone to move over to Toonz.  They both come from the same program and code base.

[Konstantin Dmitriev]

I am 100% agree with J.P. and TurtleTooth. Taking compatibility with Toonz as top priority will be a significant slow-down and obstacle to OpenToonz development.

P.S. I am "morevnaproject" from GitHub.

[J.P. Turcotte]

Hello Konstantin,

I have talked to someone from the OpenFX Association, who was very supportive. They put me in touch with the Natron and TuttleOFX folks. I will contact them as soon as possible. Tell me if you prefer to talk to them directly. Thank you!

[J.P. Turcotte]

Hello everyone,

I have received an answer from Mr Fabien Castan of TuttleOFX. He was very responsive, and said we have an interesting project he believes could benefit from OpenFX support. Mr Castan would be available for a conference call starting Monday, June 12th, to explain the standard to us, and tell us the best way to implement it. Konstantin, what do you think?

[Konstantin Dmitriev]

@J.P. Turcotte My concern is that I am not a developer (at least for OT code) and my (spoken) English is far from perfect. Our hired developer 9Ivan Mahonin) doesn't speak English either. Keeping the discussion would require knowledge of OT plugins internals, as well as basics of OFX. So I am not sure I will be able to have both of this by that time.

From my point of view it would be the best if our dev would study OT plugins model and OFX standard. And then, if questions will appear, we wil have  a matter to discuss them.

At the moment all our efforts are targeted on bringing MyPaint brushes to master branch That's require to adapt our changes to OSX and MSVC platforms. Actually, I was expecting that MSVC and OSX maintainers will take a step here. But, unfortunately, it seems there is no interest from their side. So, we will be unable to dive deep into OFX topic until we get finished this what's already started. I hope for your understanding. ^__^

[J.P. Turcotte]

Of course! I just wanted you to know that we can get backup if we ask to. I know you are both already busy with the MinGW and MyPaint PRs, and that the next dev cycle will focus on bug-squashing anyway, so we are targeting out first efforts for 1.1.5 at the very earliest. Mr Castan and others will likely be available through the summer and fall, so there is no rush. We can carefully prepare the meeting together for when you will be available, and keep everything in text to help Ivan. Would that work with the both of you? Also, is this group the best place to coordinate our efforts or do you want me to set up something like a Kanban board? Right now, I am also very concerned with the state of things on macOS, so I will devote my time to dev recruitment. Are there special skills that are sorely needed? Thank you very much!

[TurtleTooth]

@JP  I wouldn't mind if we got the ball rolling on setting up a bounty for OFX.

It would be awesome if you could recruit some dev help.  I am pretty useless when it comes to graphics processing.  The greatest needs right now are Mac issues and vector consistency.  Vector fill is a huge area of frustration from many users.

[J.P. Turcotte]

Hi TurtleTooth,

We could re-open (and rename) the issue on GitHub (#419) so it becomes available on Bountysource, but then we would still need to have an idea of the cost, and to advertise it. It seems like the kind of idea that is more easily sold to technical persons than general users, and they are the ones we need to contribute financially. In fact, I just got word from Mr Alexandre Gauthier-Foichat of Natron, who gave me a lot of tips, but also offered his paid services for this project. Should I get a detailed, broken-down quote from him as a starter? I should also mention I do not really like Bountysource as a platform, and got burned last time I used them. We basically need a crowdfunding campaign with a clear rationale, goals, and breakdown that we can post around. Anyway, I want to hear people's opinions on the matter. As for macOS development, it would be great if we could assemble a technical list of issues and areas of concern. Can I post about that on GitHub so I can tag the devs? Thank you!

[TurtleTooth]

That makes sense.  Thanks for all your work.

[Konstantin Dmitriev]

Would that work with the both of you?

Yes, that's good.

Also, is this group the best place to coordinate our efforts or do you want me to set up something like a Kanban board?

I assume, by Kanban board you mean GitHub's Project Boards? - https://github.com/opentoonz/opentoonz/projects

The GitHub Project Boards are good to track certain goals as a set of tasks. And put them into certain order.

The difference from plain issues list in GitHub (categorized by labels) is that they are placed in certain order and have horizontal categorization by status.

For example:

1. We have implemented MyPaint brushes engine. But still some work have to be done to make it better - we need to resolve some issues - polish UI and add some functionality. So, I am creating MyPaint Project Board and collect issues relevant to this feature, ordering them - https://github.com/blackwarthog/opentoonz/projects/1

2. We have a goal to release next version for Linux. I am collecting critical tasks that we aim to resolve for next release. Like this - https://github.com/synfig/synfig/projects/1

So, I think it's a bit early for Project Board for this feature. It will be needed when we will have some initial implementation.

It would be nice to have a board to collect (and order!) critical issues of Linux and similar board for OSX.

[Konstantin Dmitriev]

@JP  I wouldn't mind if we got the ball rolling on setting up a bounty for OFX.

 Yes, it is OK to have bounty as soon as it is clear that the feature/fix is doable. There are higher chances to get this done faster.

[Konstantin Dmitriev]

we would still need to have an idea of the cost

Generally, it is OK to open bounty even without cost understanding.  This is a common practice on BountySource - people post a bounty showing their interested. As bounty increases this attracts developers. It's literally a bounty.

Also, if sum is not enough, any dev can set a goal - "I can do this for AMOUNT". That sets the goal naturally.

Check the "the goal set by... " event mark here - https://www.bountysource.com/issues/34932107-feature-libmypaint-for-brush-tool-in-raster-levels

[Konstantin Dmitriev]

just got word from Mr Alexandre Gauthier-Foichat of Natron, who ... offered his paid services for this project. Should I get a detailed, broken-down quote from him as a starter?

That's also a good idea. Maybe they will take this task and OT will get more contributors.

 I do not really like Bountysource as a platform, and got burned last time I used them

Do you mean a bounty for MyPaint Brushes? It's not really problem of Bountysource that the process is too slow. Form my experience crowdfunding is no less demanding in terms of waiting and efforts.

Preparation of good crowdfunding takes at least one month from my experience. It is also very demanding in terms of efforts. Remember that money go directly to a person who started crowdfunding, right after its successful completion. Who will handle that responsibility? Dev itself? Someone else? I had many crowdfunding campaigns, they weren't really big, but let me assure you - hosting any of them took an effort (you have to answer comments, ship rewards, etc.).

With Bountysource the money go to dev only after the issue is closed. That stimulates the dev to complete the work. On the other hand, there are certain risks -  it is possible no dev will get interested in implementing tasks. Then the money get frozen forever. But I think in this case it is possible for all contributors to agree on force-close issue and output money to some trusted person, who can handle them to other issue.

Being said all of that, I have to say: I am not against of crowdfunding idea. I just would like to make sure everyone understands the differences, underlying effort and risks.

[Amo Tarzi]

Really exciting to see this happening. However I'm on the side of getting the important bugs and problems fixed first that actually prevent to use the software. STUDIO GHIBLI achieved so much great work that there's little use in (my view) for more FX (which on certain shots can definitely be achieved elsewhere much simpler. 

For a software that is targeted at traditional 2D animation workflow (there aren't that many great 2D softwares and certainly not Opensource) this is definitely the easiest and best implemented workflow-wise.

But things like basic audio playback (which doesn't work at all for Mac, meaning you can't sync any animation to audio at all!), cleanup behaving really buggy and causing crashes everytime, a clear documentation missing (e.g. if you hover over any button get an explanation of its function like in Nuke) and general stability.

I think OpenToonz does (perhaps on other platforms more stable) a few key things really good and it would be great to make sure that those areas work. If anyone's interested in setting up a Kickstarter video to get some Mac devs on board, I'd be able to create some good looking content for it that would be appealing for a Kickstarter audience and get the software up and running at its best!

[Rodney]

Turtletooth recently submitted a fix for the Mac audio issue so look for that soon!

[J.P. Turcotte]

Hello everyone!

It is always great to hear your thoughts. Here is a long overdue update. Alexandre Gauthier-Foichat, the co-lead of Natron, replied to me at the beginning of June with more info that I am going to translate you.

He said that OpenFX is a specification written in C with only string definitions to pass via function pointers. You can find the detailed specification here: http://openfx.sourceforge.net/Documentation/1.3/ofxProgrammingReference.html. There is also a C++ wrapper to help with the implementation of the plugins and host. It is now actively maintained by the Natron developers here: https://github.com/devernay/openfx. The "Support" part refers to the plugin side, while "HostSupport" has to do with the host. You can also find a really basic host implementation in HostSupport/examples. You can then refer to Natron source code for a complete implementation, and to https://github.com/devernay/openfx-misc for plugins.

Mr Gauthier-Foichat is interested in doing paid development for this, but he first needs to meet with someone familiar with the architecture of OpenToonz to determine the extent of the modifications to make, and what can or cannot be done. He doubts OpenToonz can support the full OpenFX 1.4 specification, but a minimal implementation could still support most existing plugins, such as those by Genarts, RevisionFX, Hitifilm Ignite, and Natron. I am yet to confirm Gmic compatibility with him. Here is his proposal:

1. We tell him our desired end result;
2. He explains OpenFX to us, and tells us what it can and cannot accomplish;
3. He meets with the OpenToonz developers to familiarize himself with our codebase, and evaluate the necessary changes;
4. He proposes an architecture to add OpenFX support to OpenToonz;
5. He implements it;
6. We create the interface (he thinks we are better suited to this task).

He is ready for the first two. Then, #3 will require probably more than a week of back and forth between the developers and him. #4 and #5 being where the heavy work is at, he proposes to have them done in a separate contract from #3. As soon as the first two points are done, he will give us a quote for #3 and #4-5.

Here is what I propose:

1. We try to come to an agreement on #1;
2. Whenever the Morevna people are ready, we meet with him. Alternatively, we can first meet with Fabien Castan, who also knows about OpenFX;
3. We agree on a quote for #3 both for the Morevna people and him, because they will be working in tandem;
4. I create a bounty for #3;
5. We discuss our next steps.

What do you all think? Thank you!

[Konstantin Dmitriev]

Hello J.P.! This is sounds like a plan. Thank you for managing this!