I must be missing some secret undocumented / hard to find sauce in my workflow, but I can not get the maya integration UI (such as loading / referencing publish files) to show any file published using sgtk.util.register_publish(). All it says is no files found.
To be clear they show up just fine and look indistinguishable from files published through the integration plugin (which do work) when viewed from either the website, or when queried using sg.find() from within maya, so what is it about the integration UI that is filtering out these files?
Is there a field that needs to be set? Some special flag or kwargs that need to be supplied when registering the file? I’m at a loss.
The workfiles and load apps need a bit of configuration to know what you need.
For example check the tk-multi-loader2 config. There is a mapping from publish type to action.
Thanks for the reply… I’m assuming you’re referring to line 125, Maya Scene: [reference, import]
I’m already saving the record with the published_file_type=“Maya Scene” as a kwarg for register_publish().
That column is visible on the webapp, and matches other records saved with the integration UI, and yet it still doesn’t show up under the Maya integration UI.
Yes, you have to instruct the loader app what type of files it is interested in. This is what I understand by “Maya integration UI”, though you might mean the work files app.
Do you have an overloaded toolkit configuration?
I have made a centralized setup of the tk, which is based on the sg default.
I’ve made a custom plugin for the multi-publish2 interface (which works in the UI), but I have not modified any other portion of the repo.
Files saved using the integration UI ( by which I mean using the main app menu shotgun > File Publish / File Save / File Open UI’s) can be seen in the webapp (sitename.shotgunstudio.com). They also show up when using the above UI’s when you want to load, or reference a previously saved publish back into maya.
However these same UI’s don’t find my files when they are registered using sgtk via python. They show up in the web app, the published_file_type column is the same to those saved from the integrations (all other columns appear correct too, such as entity and task). They can be found with sg.find()… but shotgun > File Open dialog will not find them.
Notice the file even shows up in the maya shotgun panel under the publish section inside of maya.
Yet it’s absent from the File Open dialog.
This happens on all tasks, regardless of name chosen or extension used (ma or mb)
Think we can close this one and chalk it up to my inexperience with the Shotgun integration.
I’ve found the files do show up under the shotgun > Load UI Which is not the same dialog as shotgun > File Open, nor is it always visible. Odd but okay, I’m sure I’ll find out in due time why this is even needs to be a separate UI. At lease I can now progress in establishing a workflow.
Oh I see your confusion now.
Yes, the workfiles app is for saving and opening “scenes”, while the load app is for loading any resource into the scene - could be geometry, images, etc. Most programs also allow importing a scene into the current scene, and thus the load app shows scenes in there too.
Both the workfiles and load app need some configuration, and the default might not always be what you need.
Now looking at the shotgun panel, what are your path templates for maya scenes? I see one file has an underscore in the name, while the other does not.
Shotgun needs files to be named in a specific way so they show up in work files.
Still, not sure why they do not appear.
The inconsistency is just me poking around to figure things out. I’ve done underscores, no underscores, ext and no ext. This was just one of the entries…
That said the main reason for figuring out the publish side of things was so I could implement my own publish setup based on our existing pipeline that offers more flexibility, and works with versionless files to make referencing far more effective downstream.
I’ve got a post about that too… but I think with this thread answered, I’ve got my plans for that in place.
Re: versionless publish: I personally would advise against it. We actually tried it - when a file is published, copy it to a “version 0 file”, but ultimately decided to scrap this. It goes against the concept of versioned files.
There are some risks in overwriting the file and makes it difficult to trace what happened. You can hack the publish plugin so it does not fail on clashing publishes. But I’d rather have versionless work files and versioned publishes.
Is it not an option to use the load+breakdown apps for updating?
As for the publishes appearing, you should compare all properties of a publish that appears and one that does not. Maybe it’s the status? Sounds to me like it might be paths and templates, though. Also check your configuration for workfiles in the corresponding environment, e.g. shot_step.
Well the Load and breakdown apps seem rather barebones, and come with the major caveat that you must initiate this update through some mechanism in a running maya session, whether that’s via script at best or far worse through manual efforts, I see it as a very likely point of failure and ultimately unnecessary.
We have been using a nested referencing workflow for many years, where a geo is ref’d into a rig, rig into a lookdev, rig into an anim, anim into a lighting scene (lookdev materials also into the lighting), etc…
Over that time the number of times this workflow has bitten us is so little and never truly dramatic, that I can’t even imagine how many hours it’s saved in not needing to update some downstream reference. Far more likely is that the user forgets to update a versioned ref to the latest, (like what just happened at a friends studio using ftrack, leading to all kinds of chaos and delays between departments simply due to a camera ref being out of date).
I’ve started replicating our existing publish system yesterday in shotgun, and it’s got it’s basic functionality already in place .
Our existing custom pipeline didn’t even have a backup / versioning of these published items, since to recreate them you just rerun the publish function from the working file, (sounds dangerous I know, but hasn’t been an issue).
Moving forward however I do plan on keeping versioned published backups, and implementing a symlink to the versionless file like NIM uses. I’m also hoping to leverage shotgun to keep notes on the history of that versionless file so rollback, relinking, and hardcoding to another version is possible, and all scenes using it downstream will be up to date without any further user intervention.
I’m glad you found a workflow that works for you. In fact my experience in this industry is relatively small, and in software versioning tends to be on the strict side.
So if you override the publish plugin, just make it publish to the same location (and maybe a backup one)?
Not sure why the files do not show up in workfiles, would need more information - your templates, folder schema, and app configuration.
.