It was brought to our attention by a couple of our initial artist testers of OP in Nuke that they find the workflow of creating creators too out of the ordinary Nuke workflow and convoluted and that they’d rather just have to create a custom Write node on their DAG graph with the export/submit/publish options, skipping the need of using intermediate dialogs.
Is this something that’s been brought up to your attention before?
@BigRoy pointed me to this other issue on Houdini Houdini: Creators as OpenPype nodes · Issue #2721 · ynput/OpenPype · GitHub that seems to tackle the same problem. Perhaps we need to look at providing more host native workflows in some of the integrations, even though I personally see the benefit of providing a very similar UX across hosts for a lot of the artists that don’t necessarily need to know much about the host native workflows.
The biggest issue with this approach (as far as I remember) is that this can be done only by adding gizmos (prove me I’m wrong?), so the scene requires to have access to the gizmos once they’re created in. Which can easily cause that the scene is not usable outside of pipeline, which is PITA especially on farm, but also for archiving or remote users.
Since I created this topic my coworker developed a wrapper on top of Nuke’s vanilla Write node that adds a tab with some custom knobs that control the vanilla knobs and hijacks the publish pipeline of OP (a bit with a hammer but they are very happy with it now)
One of the custom knobs that we add to the Write node is the publish_instance JSON string with the dictionary of the instance with all the attributes that OP publisher expects to find the instances so they can then run a normal OP publish from these (We had to do some small tweaks so the collect plugins don’t only look for Group class nodes but also Write nodes, nothing major).
The great thing about this workflow is that our artists don’t need to learn a new workflow in order to work “in-pipe” and they have a lot of control over what passes they write.
We can also leverage version control on everything they write out and we aren’t limited by the version-less staging directory workflow of OP. I have recently also added support to submit existing frames to the farm to publish [DRAFT] Nuke: Remote existing frames by fabiaserra · Pull Request #5196 · ynput/OpenPype · GitHub so we can start a publish from any existing version in the farm without need of re-rendering.
Since this is only a thin layer on top of vanilla write nodes and only required on the local session, this is not a problem in the farm or for remote users.
On the contrary, we have introduced quite a bit of technical debt as there’s a good chunk of custom code and logic that should ideally live in OP’s codebase but production needs don’t always align… but I would love to hear your thoughts on how we could align better with OP’s roadmap and get something generic enough for everyone else
I think there is definitely space for a workflow like this in OP. Personally I find the logic and code too complex in the Nuke integration and I think it could be simpler like you have it here.
I would suggest a granular approach to this cause giving no access to the native write node might make things tricky. We could expose the creation of the write nodes through the settings. For example when:
make the publish node available through the menus.
using a hotkey shortcut where we could overwrite the default W hotkey.
create the publish node instead of write node with nuke callbacks (nuke.addOnCreate).
add publish metadata to the write node with nuke callbacks (nuke.addOnCreate).
yeah I agree, that was also my argument against this approach, I didn’t want to mess with the vanilla write and instead create a separate one that would get created by default with the normal hotkey so on the edge cases we wanted to use vanilla workflows it would be much easier but their argument was that they wanted to be able to just reuse existing scenes that didn’t have our new node (there’s many other ways to support that regardless through converters but as you know, sometimes you have to pick the fights…)
The current injection of our custom tab is happening with:
and on the menu.py Nuke startup we call the attach_alkemy_write_node to override the default createNode behavior, as well as some callbacks for updating the knobs when they change.
Hey guys just a thought, you can actually register scripts as nodes in nuke. You fool the artist thinking he’s creating a node but instead you invoke a script that create the actual group node programmatically the same way you use the creator panel.
I mean you can have a pop up come up when selecting from tab so you can actually input the subset name.
Or you can enforce “Main” and have it modifiable later.
Then you trigger the same logic from the creator panel in op.
So basically just adding some defs for different families in a py file that you add in NUKE_PATH, (or just extend the logic in op) which invokes creator logic in the bg. Add a menu entry, couple icons and you’re done. Menu works, tab works. It’s just a shorthand for the creator menu afterall.
The versioned thing is nice tho!
One thing I would like to change is the creation of cameras let’s say. I mean, I would like a separate node to export, not a tag on the same node. It gets visually lost in translation. Maybe group plus expression links inside replicating the input data? So it would feel similar to renders.
thanks for pointing out!
