Fusion: Tweak Fusion integration

[BigRoy]

Brief description

This is a replacement PR for #2752 with the code coming from our studio's colorbleed branch which had tweaks done to the Fusion integration.

Description

This is a first pass to expose the tweak we've been doing on our end to discuss the changes.

1. Instead of copying scripts into the user's local Fusion folder this instead relies on using Fusion masterprefs - which is way to override settings, through which we can customize the 'path map' locations for scripts and thus load them directly from OpenPype. --> Note: users that had launched the older integration would still have those original scripts in their scripts folders!
2. The OpenPype "menu" is now accessible as top-level OpenPype menu as opposed to hidden in Fusion's Comp scripts.
3. At the top of the OpenPype menu (the Qt floating menu) in Fusion it now shows the current context (where Avalon thinks it's operating in the current session) with regards to the current asset - since the Python scripts in Fusion run in a completely standalone process it can be non-trivial to find this out without a visual clue.

Additional Context

• Related "Fusion Thread" in OpenPype Discord
• Brief discussion about some pipeline implementation details in Davinci Resolve Plug-in Developers discord

Testing notes:

1. go through testing Fusion from the ground up - as if a new user

[BigRoy]

This is currently a code merge of a few things which I haven't tested yet. I'm expecting to test by Tuesday the earliest.

[antirotor]

So, could this be tweaked a little bit to provide PySide2 and OTIO for Resolve? Just asking how much is it bound to Fusion logic.

[BigRoy]

So, could this be tweaked a little bit to provide PySide2 and OTIO for Resolve

This actually still doesn't provide PySide2 and OTIO out of the box - or at least PySide2 it doesn't. I'm not sure what'd be needed on OTIO end since I hadn't tested that at all.

The master prefs might be fusion specific - I'm not sure about that. Also, with regards to the top level menu in a .fu file - I'm not sure how well that transfers to Resolve unfortunately.

Can't provide much information here.

[BigRoy]

Tweaked some more things for this PR and tested it in Fusion. Seemed to work fine.

Aside of these issues:

• Save Prompt opens behind Work Files tool -> fixed with #2784
• OpenPype logs are errors in the Fusion console -> separate issue #2797
• Set Resolution in OpenPype menu does nothing - to be implemented
  • should set: Comp settings > Frame Format -> Resolution
• There's no button to set the "Current FPS"? And there's no "new scene" callback to enforce it for the current comp. So should there maybe be a Set FPS button like Set Resolution and Set Frame Range until callbacks are in place?
  • should set: Comp Settings > Frame Format > Frame Rate

---

Not a direct issue, but settings we might want to set for the comp by default too:

• Comp Settings > General > Frames Start From > Sequence (instead of start from one)

At the same time since the Loaders already do so for published files this might actually be "forcing too much" by default? Nonetheless it makes me think once we have new scene callback/default settings implemented we might want to just expose a user to apply custom prefs overrides in OP admin settings.

---

@jakubjezek001 any chance you could also take a look at the current state and let me know what feels off to you?

[BigRoy]

when some work has been done in one shot context and then in workfile want to open other shot context, a dialogue window (in red rectangle) is showing under the workfile window

Correct - as mentioned that's fixed in #2784

I have to change FUSION16_PYTHON36_HOME environment key in prelaunch hook as it is not supported by app setting yet. Reversing it to PYTHON36 was fixing it for me for the test.

I set that in the Application environment - just like how it was set before for PYTHON36.

loading rendered image sequence or mov works but having an issue with correctly setting frameranges

What's the issue? :)

[mkolar]

Task linked: OP-2667 Fusion: set framerange from menu button

[jakubjezek001]

What's the issue? :)

So I was testing it one more time and found out there is problem with the set_framerange. It is defining render range exluding handles and if publishing of the render node is done during those render range defined, it will render only range without handles.

Once it is loaded back to workfile, it is set to the first workfile frame and it seems to be wrong. I wonder if the render range could be ignored during publishing. The handles identified by those limits shown in image are cool and we are used to work with those in Nuke. User is interactivly shown what is in edit and what is handle.

It would be good to tel rendering plugin that it should render full range.

[BigRoy]

@jakubjezek001 Thanks for being so verbose about the issue - but somehow my mind is having a hard time grasping exactly what issue you're having with the handles. Any chance you could do a screen recording of the issue?

[mkolar]

I think what @jakubjezek001 is trying to say is that you are rendering frame range without handles, 1001-1005 in the example, however it should be rendering with handles included for consistency.

[BigRoy]

I'm thinking of also exposing FUSION_PROFILE_DIR as a setting to the OpenPype fusion integration so that it by default also uses a custom settings location for Fusion. So that whatever gets "set" as settings inside OpenPype never influences what is set outside of OpenPype.

What would be a good default location for OpenPype to expose Host specific settings/files? Of course we could expose the default value in settings. Would %LOCALAPPDATA%/pypeclub/hosts/fusion be a decent default?

Also, the most recent Fusion release 17.4.6 also adds a /execute argument that you can pass along with Fusion launch to directly run a lua script on Fusion start. Here's an example of that:

fusion /execute "print(fusion:GetCurrentComp():GetAttrs().COMPS_FileName)" "P:\path\to\file.comp"

So I expect we could also use that to force a script to run at startup, e.g.

fusion /execute "fusion:RunScript('/path/to/python/script.py3')" "P:\path\to\file.comp"

However it does not run early enough to set up Fusion Path mapping (which is needed to customize where Fusion looks for Scripts, Menus, Callbacks, etc.) and requires to restart Fusion at least once before it's picked up - something we don't want. And thus we'll still need to rely on using Fusion Master Prefs to override until Black Magic Design exposes alternatives in future versions.

---

Fusion Integration documentation with this Fusion integration refactor

Once the integration is tweaked and confirmed to go into the right direction then I'll also work on setting up the User and Admin docs to go along with the Fusion Integration

[BigRoy]

What would be a good default location for OpenPype to expose Host specific settings/files? Of course we could expose the default value in settings. Would %LOCALAPPDATA%/pypeclub/hosts/fusion be a decent default?

Anyone any pointers on this? :)

[mkolar]

Anyone any pointers on this? :)

%LOCALAPPDATA%/pypeclub/hosts/fusion is totally reasonable. I'm, however, unable to comment on much of the rest as I'm really not versed in fusion in general.

[jakubjezek001]

What would be a good default location for OpenPype to expose Host specific settings/files? Of course we could expose the default value in settings. Would %LOCALAPPDATA%/pypeclub/hosts/fusion be a decent default?

Anyone any pointers on this? :)

To be honest I am not very happy with the pypeclub part of the path. I would rather prefare%LOCALAPPDATA%/OpenPype/hosts/fusion. BTW, I do realize we are using pypeclub in the locals but I disagree with it. Pypeclub is the business name and not the package name.

[jakubjezek001]

Hey @BigRoy how are you doing with this one? Can I help somehow to finalize this one? I believe it might be just a little bit from the grand finale, right?

[BigRoy]

@jakubjezek001 I'm pretty much swamped these days at work as I'm about to leave on Holiday for a few weeks. All I can say is we use an 'equivalent' of this PR in our OpenPype setup and it's been working fine as far as I know.

If there are any minor issues in this PR that you feel like you can tackle easily feel free to do so.

[mkolar]

To be honest I'd be happy to merge this, considering the testing going on in colourbleed. We just need to sort out the conflicts.

[BigRoy]

I've merged with latest develop and fixed the merge conflicts. I have also started to make some first tweaks with regards to this comment and making sure start + end frames are set as expected to include rendering of handles. But I'll still need to test+fix those changes - hopefully this week!

[BigRoy]

• Fixed refactoring for merge with latest develop
• Added some tweaks to support Fusion 18+ (note that Fusion 18 supports multiple Py3 versions, in particular Python 3.3-3.10)
• Added default settings for a Fusion 18 application entry
• Added OCIO config setting which will set OCIO env var on Fusion launch if the setting is enabled (or maybe I should remove the enabled checkbox and allow to just skip if an empty OCIO config path was set in settings?
• Fixed loader issue where it wouldn't align frames correctly if there were start handles.
• Allow to minimze the OpenPype Menu dialog.

[BigRoy]

@jakubjezek001 The default environment for Fusion is currently set to this:

{
    "FUSION_UTILITY_SCRIPTS_SOURCE_DIR": [],
    "FUSION_UTILITY_SCRIPTS_DIR": {
        "windows": "{PROGRAMDATA}/Blackmagic Design/Fusion/Scripts/Comp",
        "darwin": "/Library/Application Support/Blackmagic Design/Fusion/Scripts/Comp",
        "linux": "/opt/Fusion/Scripts/Comp"
    },
    "PYTHON36": {
        "windows": "{LOCALAPPDATA}/Programs/Python/Python36",
        "darwin": "~/Library/Python/3.6/bin",
        "linux": "/opt/Python/3.6/bin"
    },
    "PYTHONPATH": [
        "{PYTHON36}/Lib/site-packages",
        "{VIRTUAL_ENV}/Lib/site-packages",
        "{PYTHONPATH}"
    ],
    "PATH": [
        "{PYTHON36}",
        "{PYTHON36}/Scripts",
        "{PATH}"
    ],
    "OPENPYPE_LOG_NO_COLORS": "Yes"
}

---

But I feel like that should instead be something like this at its core:

{
    "FUSION_PYTHON3_HOME": {
        "windows": "{LOCALAPPDATA}/Programs/Python/Python36",
        "darwin": "~/Library/Python/3.6/bin",
        "linux": "/opt/Python/3.6/bin"
    }
}

Thoughts?

Or would you rather prefer like this:

{
    "PYTHON36": {
        "windows": "{LOCALAPPDATA}/Programs/Python/Python36",
        "darwin": "~/Library/Python/3.6/bin",
        "linux": "/opt/Python/3.6/bin"
    },
    "FUSION_PYTHON3_HOME": "{PYTHON36}",
}

And should maybe set OPENPYPE_LOG_NO_COLORS in FusionAddon.add_implementation_envs like is done for Maya?

[jakubjezek001]

{
    "FUSION_PYTHON3_HOME": {
        "windows": "{LOCALAPPDATA}/Programs/Python/Python36",
        "darwin": "~/Library/Python/3.6/bin",
        "linux": "/opt/Python/3.6/bin"
    }
}

This should be good enough. I believe if anyone wants to expand it it can be done with custom changes.

And should maybe set OPENPYPE_LOG_NO_COLORS in FusionAddon.add_implementation_envs like is done for Maya?

I am not sure on this one. @iLLiCiTiT or @antirotor is better for this question.

[iLLiCiTiT]

And should maybe set OPENPYPE_LOG_NO_COLORS in FusionAddon.add_implementation_envs like is done for Maya?

Yes. That's not "modifiable" env in settings, you just want turn it off to not show wierd characters in logs because Fusion can't handle it.

[jakubjezek001]

Also I believe FUSION_PYTHON3_HOME should be part of openpype/settings/defaults/system_settings/applications.json It is missing at the moment.

[BigRoy]

Also I believe FUSION_PYTHON3_HOME should be part of openpype/settings/defaults/system_settings/applications.json It is missing at the moment.

Yup, that's what I was referring too for the default setting. Will tweak the PR.

[BigRoy]

Have tweaked the addon to set OPENPYPE_LOG_NO_COLORS, tweaked the default fusion environment in applications defaults to match what is needed for current implementation to work, fixed the "Set Resolution" button in the OpenPype menu to do anything.

Currently there's no logic anywhere which sets the Comp's default aspect ratio, fps, etc. I feel like that would still be good to add. There are no real working callbacks for Fusion that I've been able to get to work consistently which would also be able to quickly run against the python code because it'd each run a new python process as far as I am aware. But, that might be best as a separate issue to solve.

Ready for review!

[BigRoy]

@jakubjezek001 Any chance you're able to look into this PR quickly? :) I'm working on another Fusion integration tweak which might be quite big on top of this PR and I'd love to PR it separate.

It would have the OpenPype menu context try and auto-match with the currently active comp so that if you were to have multiple comps open at the same time from different assets that the UI would be able to change along with when you click into another comp. It'd be based on a timer (running e.g. every 2.5 second - since it runs in a separate process it doesn't trigger any slowdowns in Fusion and runs in 0.0009 seconds or anyway).

Actually thinking about that now that could technically be dangerous during publishing if some of the logic there would rely on the context to remain the same during the publishing instead of the user potentially clicking into another comp as he starts the the publish. Maybe instead it should highlight the asset name at the top of the menu with a different color to notify it's not matching - and maybe add a button to "refresh" or "sync" it again. Sounds like a good reason to keep that a separate PR already.

[jakubjezek001]

Actually thinking about that now that could technically be dangerous during publishing if some of the logic there would rely on the context to remain the same during the publishing instead of the user potentially clicking into another comp as he starts the the publish. Maybe instead it should highlight the asset name at the top of the menu with a different color to notify it's not matching - and maybe add a button to "refresh" or "sync" it again. Sounds like a good reason to keep that a separate PR already.

I wonder if the context is collected only once at start of publishing and then it is not required anymore. Even Integrate is taking Context data from collected, right? @iLLiCiTiT

[iLLiCiTiT]

wonder if the context is collected only once at start of publishing and then it is not required anymore. Even Integrate is taking Context data from collected, right? @iLLiCiTiT

It is, but there is a lot of plugins that are still using legacy_io or os.environ directly and it's hard to identify if we can "just switch" them because I'm not sure when context is filled during farm publishing.

Definetely not issue for this PR :)

[BigRoy]

Definetely not issue for this PR :)

Yes - different issue, different PR.

@iLLiCiTiT any chance this PR could get your approval for a merge?