Custom UI prototype

I think I agree with what you are saying. I have implemented actions within my GUI but at the moment all they do is launch the tool you need to make the fix rather than fix it for you, The whole CVEI process has to happen again anyway if it fails at validation, because a change to the scene means collecting the data again.
And the custom UI for the publish type is really just an extension of collection, I don’t plan to allow the user to modify anything in the scene through it, merely add a screen shot, description and tick some boxes that affect the publish such as whether it should be sent for review or not.

However what if your publish is selection based? Would you say that’s not immutable? For example one of my publish types might be asset generation from selection.

Good question! Selecting is modifying data; in this case the internal state of your Maya scene. Since you select before you publish, I think that is all good and dandy.

Only side note there is that ensuring the same selection upon next publish is prone to human error. You’d need to ensure the exact same selection (probably even in order for some extractors?) was applied for subsequent publishes to be idempotent in a sense. And to perform that exactly similar publish the selection (that original state) should be applied identically and if that’s part of your publishing setup I would not call it an immutable workflow.

(And it disallows batch publishing, e.g. updating output content, from a scene).

Hey @mattiaslagergren, just checking in. How are things going with the UI?

We’ve now completed the first prototype of it and will start the implementation into Nuke and Maya. This will give us insights on how a full workflow may feel once the tool is done.

Once we have something working we will share more information with the community and invite people to beta test it. I will announce on the forum (both here and ftrack’s) when ready! :slight_smile:

1 Like

*Trumpets playing!*

That’s great! Looking forward to seeing more. :slight_smile:

1 Like

Me wants to play! :smiley: That’s great news. Looking forward to playing around with it.

Hi my pyblish friends!

I know that I’ve been quiet for some time now but we’ve still been busy with this at ftrack. Today is a big day since I’m happy to announce the very first version / technical preview of the tool. It is immediately available for testing. You can read about it here:
http://forum.ftrack.com/index.php?/topic/720-new-publish-tools/

As you will see we ended up with a slightly different implementation than first planned. Instead of putting the options directly on the pyblish plugins we have an asset plugin that defines the options. The options are then readable from the pyblish plugin.

Being a technical preview it does come with some limitations:

  • Validations are not fully supported(?!) - I know this is odd, pyblish being pyblish. But it is something that we will address soon as it is already planned for!
  • Cannot enable/disable plugins or view them before publishing. This will also be addressed in upcoming versions.

All in all - we now have a technical preview for you and others to try out. Please contact me here, in the ftrack forum or other by other channels if you want to discuss something!

Thanks for the update @mattiaslagergren, woho!

Would it be possible to get a glimpse in the form of a screenshot or video? Will attempt to give it a try soon, does it require an ftrack account?

Yes, I just posted them on the ftrack forum thread but here they are for reference:

Select what to publish

Options dialog when publishing geometries

Thanks, that’s some great work!

Possible double register

I noticed in your collector plug-in you call register_plugin at the end, and then in your register_common_plugins you call register_plugin_path.

You might be attempting to register them twice; once via the path, and then again within the plug-in itself. You could either:

  1. Remove the call to register_plugin or
  2. Remove the call to register_plugin_path and manually import the plug-ins so as to call register_plugin implicitly.

This might also apply to the plug-ins under asset/. I saw the latest commit message “Re-factor how assets are registered”, is this related?

Contract

Apart from that, it would be really cool to see a more formal “contract” one could read - kind of like a tutorial - to read about how meshes - and assets of other families - are intended to be created and on what basis they are collected during publish.

I made an example of how I personally envision something like that in the pyblish-starter documentation here:

The contract for each family (or AssetType in ftrack-speak) should answer questions like “how does the user know he is meant to place his publishable meshes at the root of the scene?” At the moment, that question only seems answerable by browsing the code, but maybe there’s something else somewhere?

Congratulations, great work and very happy to see a first version!!

Great input, thank you!

Thanks, this is also what I’ve been suspecting! The commit message is somewhat related but more towards registering the assets by placing them in the resource/ folder and putting that on the FTRACK_EVENT_PLUGIN_PATH - that does however effect how the pyblish plugins are loaded. Anyhow, thanks I will look into this.

This does a make a lot of sense and my goal is to improve the documentation both on the ftrack related side, but also explaining more about pyblish and how we intend it to be used. At the moment you have read code and try to understand, which won’t do it in the long run.

Thanks a lot, we are happy with it and eager to get some feedback both on the technical side and the from the user perspective :slight_smile:

If I can get hold of an ftrack demo account, I’d be happy to give it a spin myself.

I will contact you by email!

Hi Mattias,

I’m trying this out now, and are encountering some problems along the way I thought I’d highlight.

  1. I did not understand I needed ftrack Connect, I’d put a hint on the page about it.

  2. The “Edit on BitBucket” button on your Installation page gives me a 404 Not Found.

  3. If it didn’t, I would have had a look at the instruction:
    "The directory can be found from Connect menu > Open plugin directory."
    Where is this Connect menu? I looked in the ftrack_connect_package.exe application, but couldn’t find any menus. Then I looked in Maya, but found only a menu named ftrack. I then googled “ftrack plug-in directory” and got to this page with an image showing a right-click of the SysTray icon, and there it was.

  4. The instruction git clone git@bitbucket.org:ftrack/ftrack-connect-maya-publish.git results in a Permission Denied

  5. With Python 2.7 and pip 8 and 9, pip install fails due to PySide; the public release on PyPI assumes you have Visual Studio 2010 on your path and refuses to install otherwise. I get mine from here and have also struggled with making it a dependency for projects.

For the install instructions, I’ve had good luck with this format.

$ cd C:\Program Files\ftrack-connect-package
$ git clone https://bitbucket.org/ftrack/ftrack-connect-maya-publish.git
$ cd ftrack-connect-maya-publish
$ git checkout 0.2.0
$ pip install --target=dependencies --verbose --upgrade --process-dependency-links .
$ rm -r dependencies/ftrack_connect_maya_publish*
$ rm -r dependencies/ftrack_connect_maya_publish-VERSION-py2.7.egg-info

I count at least 10+ dependencies being installed via pip, and in the setup.py there is only one reference, a dependency link back to ftrack-connect-pipeline.

Amongst the items being installed are Sphinx, Babel and MarkupSafe, one of them listed as a build_sphinx_required and I’m unsure of why this is included here and the latter being an indirect dependency of Sphinx, making the whole process take a good 5 minutes.

The showstopper here is PySide. I do have it installed already, but since dependencies are installed via --target it has no effect. And I can’t install it without Visual Studio 2010 which I won’t be installing (due to past bad experiences with it and Wacom drivers, of all things).

2 hours in with no success, I’ll have to stop.

Hi Marcus, thank you for trying this out and highlighting the issues for us.

  1. I will make this information clear on the installation page.
  2. Thank for letting me know!
  3. I will make sure to clarify this step.
  4. Ah, my bad - I will switch the https approach.
  5. This is a tricky one as we only have this “development setup” way at the moment. PySide is required to allow you to build the resource file. Soon we will come up with a better and more easy installation that does not require you to go through all these painful steps.

2 hours in with no success, I’ll have to stop.

I’m sorry to hear this - let me know if I can help you get any further.

Is there no way I can try this as a non-developer? As a “download this file and run it”?

With Pyblish, we sidestep these issues by bundling the few dependencies there are. It enables you to simply put the directory on your PYTHONPATH and call it a day.

Let me know when I can try it, and I’ll take another look.

I’ve finally had time to continue with this and built two zip packages for Nuke and Maya:

Here is a new screenshot with updated designs:

Looks great, will give this a try!

@mattiaslagergren

Hey.

So I’ve tried installing this and it’s appearing in maya, however I can’t get the window to actually show. It might very well be due to some differences with our internal pyblish environment, because I’m getting this error:

 Error: AttributeError: file K:\.core\dev\ftrack\ftrack-plugins\ftrack_connect_maya\dependencies\ftrack_connect_maya_publish\shared_pyblish_plugins\extract_alembic.py line 13: 'module' object has no attribute 'Subset' # 

Are you using customised pyblish.api by any chance?