Skip to content
This repository has been archived by the owner on Sep 20, 2024. It is now read-only.

Fusion: Tweak Fusion integration #2769

Merged
merged 62 commits into from
Sep 21, 2022
Merged

Conversation

BigRoy
Copy link
Collaborator

@BigRoy BigRoy commented Feb 20, 2022

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.
  • Global In/Out will now be considered as handles for your publish for all areas outside of the Current Time Range.
  • 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 window.
  • Fix Set Resolution in OpenPype menu
  • Fix Set Frame Range in OpenPype menu

Additional Context

Testing notes:

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

@BigRoy BigRoy added type: enhancement Enhancements to existing functionality host: Fusion labels Feb 20, 2022
@BigRoy BigRoy self-assigned this Feb 20, 2022
@BigRoy
Copy link
Collaborator Author

BigRoy commented Feb 20, 2022

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.

@BigRoy BigRoy linked an issue Feb 20, 2022 that may be closed by this pull request
@antirotor
Copy link
Member

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
Copy link
Collaborator Author

BigRoy commented Feb 21, 2022

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
Copy link
Collaborator Author

BigRoy commented Feb 22, 2022

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

Aside of these issues:


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?

Copy link
Member

@jakubjezek001 jakubjezek001 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @BigRoy for the update! I was testing and at the moment found following problems:

  • 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

image

@BigRoy
Copy link
Collaborator Author

BigRoy commented Feb 24, 2022

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.

fusion_env

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

What's the issue? :)

@mkolar
Copy link
Member

mkolar commented Feb 24, 2022

Paths = {
Map = {
["OpenPype:"] = "$(OPENPYPE_FUSION)/deploy",
["Reactor:"] = "$(REACTOR)",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could not find it. Is there set somewhere in app environments?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, REACTOR is only there because it's used by almost everyone working with Fusion in a more than average capacity. The unfortunate side effect of masterprefs is that it "locks" the settings to those values. So a user/studio couldn't set custom path maps for their studio unless they were to change the .prefs file.

REACTOR would be an environment variable set by the studio as to where they have that installed (if they use it). If they don't it's mostly disregarded by fusion because the pathmapping doesn't resolve to anything.

You'd set it in Admin Settings, like FUSION16_PYTHON36_HOME as in my screenshot here.

@jakubjezek001
Copy link
Member

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.

image

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

@BigRoy
Copy link
Collaborator Author

BigRoy commented Feb 24, 2022

@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
Copy link
Member

mkolar commented Mar 3, 2022

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.

…on_v2

# Conflicts:
#	openpype/scripts/fusion_switch_shot.py
@BigRoy
Copy link
Collaborator Author

BigRoy commented Sep 19, 2022

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
Copy link
Collaborator Author

BigRoy commented Sep 20, 2022

@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.

Copy link
Member

@jakubjezek001 jakubjezek001 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works perfect! Thanks you ;)

@jakubjezek001
Copy link
Member

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
Copy link
Member

iLLiCiTiT commented Sep 21, 2022

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
Copy link
Collaborator Author

BigRoy commented Sep 21, 2022

Definetely not issue for this PR :)

Yes - different issue, different PR.

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
host: Fusion type: enhancement Enhancements to existing functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fusion: set framerange from menu button
5 participants