Loader - not showing all publishes

[clintond]

Hi Team

I’ve gotten the ‘publish’ part of the process mostly solved and have moved onto the ‘Load’ part.

There’s a few issues I’m encountering for which I’d appreciate some help.

1. Debug for Loader related code?
2. Loader not showing all published items.
3. Loader showing inconsistent item names.

ITEM 1.

I’m adding debug statements within Loader code but don’t know where these are displayed. Maya script editor, nope; SG Desktop console, nope; a sandstone wall somewhere deep inside an Amazonian cave, perhaps.

ITEM 2.

Before I go into this point, it is worth mentioning that I have generalised the publish workflow. That is, artists have control over what objects are published from their scene and what file format they are published with. Right now, I have the publishing for this workflow working well.

For this discussion, I’ve published out 6 items from my scene;
1x TABLE as 3x formats (obj, rs, abc)
1x SPHERE as 2x formats (abc, rs)
1x Maya Working Scene as 1x format (mb)

In Shotgun, I can see these entries and their associated field data:

However when viewed within the Loader, I only see one entry for each object (in this instance, TABLE/SPHERE):

How do I enable the remaining items?

ITEM 3.

Also when viewing the items in the Loader, I see come inconsistent names.

In this example I see two names;

name.version.extension
name.extension

Yet when viewing the data in SG, the names are consistently named;

name.version.extension

Overall the customisation of Loader seems half done when compared to the publisher, that allowed me to do quite a bit of workflow enhancements using the underlying framework. Loader feels far more baked in and untouchable by comparison, which is a shame as the publisher generates the file-soup, and Loader should filter out the goodness.

Thanks in advance.

clinton

[DavidMason]

Hi @clintond,

I believe that it is using the Published file type, name and version to group publishes in the loader. I see that you are making .obj, .rs and .abc as GEO published files, any reason why these are not separate published file types?

-David

[clintond]

Hi @DavidMason

Thanks for getting back to me.

I’ve been using ‘type’ as a way of categorizing the ‘thing’. Eg, a CAMERA, GEO, RIG. The format (abc, obj), is separate to this.

Below is an image showing the publish UI from a tracking scene. This type of generalised workflow is fully supported in our pipeline (an artist can publish any type of ‘thing’ at any STEP). In a pipeline where each publish can only really do one thing, it makes sense to use the ‘type’ field as descriptor for the ‘format’, but not for us.

In the image, the ‘type’ is CAMERA/GEO. If ‘type’ was the format, you can see how this wouldn’t make any sense.

So I’m happy with how I’ve set things up on the publishing side, I now just require control on the Loader side.

Thanks, clinton.

[clintond]

Hi Team

Are there any thoughts RE my questions posed in this thread?

As you know I’m happy with how I’m storing and generating the data and would now like to filter that data in a structured way on the Loader side.

Thanks for any insights.

clinton

[tannaz]

Hi Clinton –

In order to load a PublishedFile, the Loader needs to know what it actually means to load it – whether it’s to create a reference to it in the work file, import and fully bake it in, or something different.

This “what it means to load” is defined through loader actions, and loader actions are mapped to PublishedFile types. If a given PublishedFile doesn’t have a loader action associated with it, the Loader doesn’t know what to do with it, and it won’t show up in the UI. So, that field/entity has a specific use in Toolkit, and using it otherwise will cause problems.

You could create a custom field on PublishedFile to store the type that you use to organize things in the Publisher.

Hope that helps! Let us know if you have any other questions.

[clintond]

Hi Tannaz

Thanks for replying.

I’ve added custom actions to the Loader so my filetypes appear, and with the logic for handling GEO/SHADER/CAMERA etc. It was pretty easy to do while also supporting Maya and Houdini specific loader actions.

My issue is primarily related to the Loader UI, as it is a jumbled mess at present owing to the fact I have several publishes coming through with the same version, and possibly in the same file format. The UI assumes one ‘item’ of a certain format per version; not many ‘items’ of the same format per version.

It was possible to customise the Publisher workflow with nothing more than some hook/config mods, but it seems the Loader is far less customisable, which is the issue I’m facing.

Once I focus my attention back on this problem I’ll ask some specific questions as I can see I’ll be doing some low-level modifications to the Loader to support my workflow.

Thanks again, clinton.

[mmoshev]

Actually when everything is set correctly, the Loader collapses all versions of the same publish together. This was related to the templates and the file names, iirc. Don’t have the full details.

Even with that though, the UI becomes hard to navigate with many publishes. The filters do help, but it’d be nice to have more control over sorting, grouping and such. Right now finding something is challenging.

More Loader customization with hooks would be great!

[clintond]

After a little thought I’ve decided the shortest path to a workable solution is the preferred one.

So I’ve modified my publish TYPE to be the following:

TYPE + FORMAT

Which gives me something like:

CAMERA_ABC
CAMERA_MB
GEO_RS
GEO_OBJ
etc…

While not my preferred approach, it at least means the Loader works without any low-level modifications, and items are displayed as you would expect (only one entry per-item, per-version).

That’ll do for now!

clinton