Hey guys,
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.
Thank you!
Fabia
2 Likes
wow!
I didn’t know that I can do that in Houdini 
thanks for pointing out!
1 Like
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
3 Likes
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:
# keep original node create function
nuke_original_create_node = nuke.createNode
def attach_alkemy_write_node():
nuke.createNode = alkemy_write_node
def alkemy_write_node(node, knobs="", inpanel=True):
if node == "Write":
alkemy_write_node = nuke_original_create_node(node, knobs, inpanel)
# attach our custom tab
create_alkemy_writetab(alkemy_write_node)
return alkemy_write_node
else:
return nuke_original_create_node(node, knobs, inpanel)
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.
