Why is the loader app not showing my Alembic publishes

Pipeline Integrations
1

Hi,

I have a similar issue, I would like the Loader to list my alembic caches, but I put them in another place than the default set up, and the Loader doesn’t to pick them up. Maybe I forgot to update a path used to say to the Loader where to look for the listing ?

Does that make sense ?

Thanks !

Cheers !

Edit by @philip.scadding
I’ve broken this out from this topic into a new one, as although it was regarding the loader, the point of discussion was different.

2 Likes
2

Are the caches published into shotgun?
Can you give us more info?

1 Like
3

Yes they are, I can see the alembics on the website.

So basically, I added alembic export for the shot, which is not here by default. I create one alembic per asset in the shot (characters and props). I don’t put them in the Publish folder that Shotgun creates by default though, I put them in alembic/{Shot} folder I create with the schema.

Let me know if you need other informations :slight_smile:

1 Like
4

If the caches are published according to the templates.yml settings then maybe the loader hook needs to be adjusted to show alembic caches in the shot tab :thinking:

1 Like
5

The thing is that the Hook is getting the path from this command:

 path = self.get_publish_path(sg_publish_data).decode("utf-8")

Where the self inherits from HookBaseClass, but I don’t know how to adjust this path, and where it is stored.

1 Like
6

Hi everyone

So the tk-multi-loader2 app does not make use of templates to valid the paths, unlike the tk-multi-workfiles2 app.

Instead it simply looks for PublishedFile entities that are linked to the relevant entity selected in UI, and that the PublishedFileType of the published files matches the ones configured in the loader settings.

The get_publish_path method comes from the base Hook class. Which when given a PublishedFile entity dictionary, it will return a path appropriate to the operating system.

So if the alembic file is not showing up, then it’s most likely that one of the following is true:

  • It doesn’t have a path for your operating system
  • The loader is not configured with actions for that PublishedFileType
  • The selected entity in the UI is not properly associated with that PublishedFile entity.
  • There are additional filters being applied, either via the publish_filters setting, or via the filter_publishes_hook

Best
Phil

3 Likes
7

I see, it is probably the wrong type, in the publish plugin I made my item type is “Alembic” but it should be “Alembic Cache” for the Loader to be able to list it.

Thanks a lot, I’ll have a try with that :slight_smile:

Cheers !

3 Likes
8

Rather than start a new thread, I thought I’d post here,
Where you say " * The selected entity in the UI is not properly associated with that PublishedFile entity.", what does this mean specifically? Is it that the publishedFile entity field points to the selected entity? How about associations using different fields? Is that possible?

1 Like
9

I’ve hooked up a custom “filter_publishes” hook which is where I imagine I can override the default setup, but I’ve no access to the currently selected entity in the dialog. I have the app instance, but no dialog instance. Is that right? or am I missing something?

Also, I can see in the logs that when I select the custom entity item in the tree, it’s using the following filters to find publishedFiles :
Filters: [['entity', 'is', {'type': 'CustomEntity02', 'id': 499}], ['sg_status_list', 'is_not', None]]

I want to change the “entity” field reference here to a custom field.

Thanks again.
p.

10

That is correct, and after quick look at the code, I think it is hardcoded that way, so associations to entities on other fields would not be considered.

Looking at the code I also don’t think that is possible to extract. It sounds like your use case is not something that was probably considered when this was written. If you were passed some PublishedFiles then I suppose you could try and figure out the context from their entity field, but it sounds like in your case there wouldn’t be a PublishedFile linked in the traditional way.

I think it is fair to say that the loader expects publishes to be linked in the normal way and isn’t flexible in its approach.

11

Thanks Phil,
I think this might be a worthy feature-request :slight_smile:
Cheers
p