Importer/Asset Manager

[tokejepsen]

Instances are actually already capable of forming a hierarchy; that was actually the main intent of them being a list to begin with, to have other child instances.

Great, one problem sorted:)

It’s possible we could visualise that in the UI as a tree-view, I think it opens doors for interesting publishing problems as well.

Personally I don’t see a need for it in the publishing UI. The importing UI would feature this tree structure though.

[tokejepsen]

This is for reference for future development; https://vimeo.com/147780313

[tokejepsen]

Another for reference; http://rocketpipe.vfxmartin.com/

[marcus]

Nice, thanks for sharing!

[tokejepsen]

And https://support.shotgunsoftware.com/entries/95442527 of course:)

[tokejepsen]

Proof of Concept

GitHub - tokejepsen/pyblish-import

Usage

Needs GitHub - pyblish/pyblish-base: Pyblish base library - see https://github.com/pyblish/pyblish for details. and GitHub - pyqt/python-qt5: Unofficial PyQt5 via PyPI for Python 2.7 64-bit on Windows in PYTHONPATH.

Run app.py.

Comments

Don’t know what to call this, as its barely a proof-of-concept.

I’m interested in what people think of the initial mocking module, which represents what would be a plugin in Pyblish at some point. There are huge areas of development, like UI and getting Actions involved, but earlier comments the better:)

The idea is to attach actions to the instances shown in the UI, similarly to how plugins currently work within Pyblish.

I opted for QtWidgets to begin with because the current support version of Qt in python-qt5 doesn’t have a TreeView QML type; TreeView QML Type | Qt Quick Controls 1 5.15.9. Apparently that was added in Qt 5.5, but python-qt5 was build with 5.4. I might be completely wrong about this, @marcus?

[marcus]

Apparently that was added in Qt 5.5, but python-qt5 was build with 5.4. I might be completely wrong about this

No, you’re right. It’s time to upgrade soon, that treeview looks great.

Will have a go with this over the weekend, looks cool!

[marcus]

I had a go with this, here are my thoughts.

class InfiniteCollector(object):
    def process(self, parent):
        ...

1. It would be safe to inherit from pyblish.api.Plugin. Even though it doesn’t get you anywhere in this case, it could help bridge the gap between standard plug-ins and your importer app.

2. I’m not sure what to think of process taking an argument other than context or instance. This would make it unusable to the overall logic to process plug-ins in order and produce result dictionaries.

3. The view holds data. I get that it’s easier to start out with a QTreeWidget, but soon you’ll find it easy to get into some bad habits that end up biting you later on.

4. Calling process yourself is a bad idea. parent.plugin.process(parent.instance) If you can, try getting pyblish.util.publish() involved. It’ll handle triggering of plug-ins in the right order, populating the Context.

Other than that, maybe add a button do actually perform an import, and perhaps a filter to exclude things that couldn’t be imported would be a good next step.

[tokejepsen]

It would be safe to inherit from pyblish.api.Plugin. Even though it doesn’t get you anywhere in this case, it could help bridge the gap between standard plug-ins and your importer app.

Sure. The plan was to maybe make a new class type to inherit from, but maybe thats not necessary.

I’m not sure what to think of process taking an argument other than context or instance. This would make it unusable to the overall logic to process plug-ins in order and produce result dictionaries.

True, but the problem is that you need to append instances to the parent instance. This allows the UI to not know about the entire hierarchy before showing. Having to load the entire library of a project can easily become a lot to compute, and to wait for.

The view holds data. I get that it’s easier to start out with a QTreeWidget, but soon you’ll find it easy to get into some bad habits that end up biting you later on.

Maybe I can have a look at a separate model, but it would need to be build dynamicly anyways.

Calling process yourself is a bad idea. parent.plugin.process(parent.instance) If you can, try getting pyblish.util.publish() involved. It’ll handle triggering of plug-ins in the right order, populating the Context.

Again the idea was to not have to load the entire context to begin with, so it was necessary to call the process method every time the user expands an instance.

Other than that, maybe add a button do actually perform an import, and perhaps a filter to exclude things that couldn’t be imported would be a good next step.

Defo:) All good things to come. As for the button to import, I’d imagined that you attach actions to the instances, similar to how Pyblish works with its plugins. You would then right-click on an instance to gain access to available actions, where one of them could be to import.
I’m imagining that people would use this GUI for updating the existing scene as well, so one plugin for the GUI would be collecting references in the Maya scene that the user can choose to update.

I’ve also imagined that you can get more information about the instances, like for example when collecting the references in the Maya scene, you could see that an instance is out-of-date and there are newer versions available.

[tokejepsen]

True, but the problem is that you need to append instances to the parent instance. This allows the UI to not know about the entire hierarchy before showing. Having to load the entire library of a project can easily become a lot to compute, and to wait for.

I actually just realized that parent could easily be instance. So I’ll have a look at this:)

[bjorn_rydahl]

Hi,

its been a while since you had this discussion and I just wanted to follow up and see what direction you did take @tokejepsen. Did you manage to borrow any concepts from pyblish for your importer/asset manager and has it been useful?

Cheers

[tokejepsen]

Hey @bjorn_rydahl

Did you manage to borrow any concepts from pyblish for your importer/asset manager and has it been useful?

The proof-of-concept is as far as I’ve got with this for now. The mocking module shows as much of the Pyblish concepts as I could currently implement.

The next major issue to tackle will be to implement instance actions; https://github.com/pyblish/pyblish-base/issues/277

I also think that the api needs to be separated from the gui, so similar to pyblish-lite and pyblish-qml people would be able to develop their own GUIs.

Are you interested in pushing this further?

[bjorn_rydahl]

It is only investigation so far and I’m just trying to gather what concepts would make sense.

We will probably not use pyblish for it, but may borrow some concepts and use those together with our own actions. The main benefit for using pyblish is the community around it, which is not true for importing

Cheers

[marcus]

Yes, I would not bark up this tree. Whenever I see importing made in relation to Pyblish, I make a hissing sound and cross my index fingers.

[tokejepsen]

I agree:)

The more I think about this importer the less it actually really needs Pyblish. BUT I do like the concepts presented in Pyblish, ei. separating collecting data from the action of importing.