Custom UI prototype

General
#41

Here Toke’s assigning a whole bunch of them for hiero exports.

#42

The instances_by_plugin takes it into account! https://github.com/pyblish/pyblish-base/blob/master/pyblish/logic.py#L209

I wonder how it would affect my UI. Just that the settings from those plugins should show up, or should an instance show up for selection if it does not have it as primary family?

E.g.

instance.data[‘family’] = ‘camera’
instance.data[‘families’] = [‘camera’, ‘bar’]

Should instance show up if you choose “Camera” as you publish action. What makes most sense here?

#43

I believe instance always must have family, so I’d take that for filtering and then probably use ‘subfamilies’ sort of thing to assign it to plugins.

So the collection might just assign camera family, when user then selects in the UI to export this instance as alembic you add camera.abc to the list, when he checks to export .ma too, you assign add camera.ma to the list.

ExtractCamAbc is then simply operating on instances with camera.abc family. and so on.

Of course you could probably generalize it more, by just adding abc family and any instance that has that attached will then get exported as alembic, regardles what it main family is, if it only operates on abc family.

#44

In regards to it showing when it doesn’t have ‘camera’ as it’s primary family, I wouldn’t go that route. Strange instance inception could pop up that way. I do have occasions where the same data from the scene shows as 2 instances (camera shows as camera and review), but for those I simply collect it twice with different settings, to avoid any mixups.

ending up with

Camera
    + shot_cam_01
    + helper_cam_01
Review
    + shot_cam_01
    - helper_cam_01
    - persp

User knows he’s exporting two cameras to a file (to be picked up by other departments), and review from shot_cam_01.

#45

Both are optional and combined at run-time.

family was first and remains present primarily due to backwards compatibility. As mentioned, it’s also used in pyblish-qml as the “primary” family, the one showing up visually. But I expect family to eventually disappear in favour if families.

If no family is assigned, either through family or families, then it is assigned one called "default".

#46

Aaah. I see now. Well dare I say it seems quite helpful to have it there. It makes nice differentiation :slight_smile:

#47

In what direction would you see pyblish-qml evolve in the near future? I assume as pyblish users will be using family until pyblish-qml does not pick it up - or is it already deprecated?

Conceptually I like having the primary one (family) from a usability point of view, but I understand that the concept of families fits better with data processing and simplifies the contract between instances and plugins.

#48

It isn’t deprecated, we just haven’t yet found a way to combine the simplicity of this one family with the added power of having multiple families.

One option may be to simply consider the 0-eth element “primary”, but I’m expecting something a little more intelligent to make itself known eventually. Such as treating families as “tags”, and draw them similar to how “labels” are drawn on GitHub issues.

It’s still open for discussion, and there’s no rush in finding the best/next step.

1 Like
#49

Missed a reply on this. I think that’s perfect. In that case, I’ll wipe the idea of building for MPC or The Mill from my mind and aim future comments towards a fluffy experience towards new or young studios, without a dedicated TD who just want the basics to get up and running quickly but not necessarily looking towards making a long-term investment into any given technology or workflow just yet.

I think this strict direction will be important later on once we get into more detail.

#50

@marcus it looks like you changed my video/screenshot upload in the original post. I cannot see the screenshot and the video link is broken for me.

#51

Oh, sorry about that.

I uploaded it to the forum server to avoid broken links in the future, but it appears the player it uses is browser-dependent and some browsers can’t play the format.

I’ve reverted it for now, but the screenshot seems to have gotten garbage collected. Could you upload the picture again? I’ll have a think about what to do about videos… How are you guys doing it at ftrack?

#52

Cool, I’ve uploaded the screenshot again.

We’re not so concerned with the broken links for things uploaded by the Community in our forums. As for forum hosting we’re now using a SaaS solution. We did host it ourselves previously but changed to save time.

#53

Ok, that makes it easy I suppose. I on the other hand am very concerned about it. :slight_smile:

#54

I had one question
I presume that with this tool, that once the type of publish has been chosen the following happens:

Collection of data
Custom UI displaying options and asking for user input. (in a way a type of collection, but based upon the previous step\pyblish collection)
Validation

Now at the point of validation, if something has gone wrong, and the user needs to make a fix, presumably before revalidating, you need to go back through collection and therefore back through the ui again. I saw some discussion further up about persistent data, were you planning to repopulate the UI with some of the data from last run through to save for example the user writing out descriptions and setting settings again?

#55

Interesting! We haven’t come this far yet and to be honest I haven’t thought about this problem before you brought it up. The workflow in pyblish (qml/light) would be Failed validation > Repair through an action > Collection again > Validation … and so on.

To me it sounds like we would have re reapply whatever settings are made to the newly collected instances.

#56

Yeah its a bit of a tough one. For me (as im doing a similar thing) I’ll probably store another dictionary incontext.data['ui'] which will hold my ui defined data and pass it to the collect.

something a bit like this:

previousUIData = self.currentPublishContext.data.get('ui',{}) if self.currentPublishContext else {}

self.currentPublishContext = pyblish.api.Context()
self.currentPublishContext.data['ui'] = previousUIData

instances = pyblish.util.collect(context=self.currentPublishContext,
                                         plugins=pluginsToUse)

But its then up to me to reuse this when I load my UI for the second+ time. I don’t know if that fits so well or is clear to people who want to customise your integration with there own UIs. Also Its possible that if you ui has settings that relate to perhaps a list off collected items, and those collected items are different the next time round, is the data still valid?

#57

Yeah, I don’t have a good solution to this atm. Perhaps someone else in the Community has some experience with this? Or is the best solution to persist the settings in the scene so that they are properly collected.

#58

Ok, so this will be a rant. Much personal opinion that I know is not entirely shared. It is what I believe based on my experience that you will need in order to build the most optimal and most maintainable pipeline long-term. I am not interested in short-term. Just long-term.

Here we go.

< rant >

Do not modify data during or after publishing

Triple check with yourself that each publish is (1) idempotent and that the published content is (2) immutable. Another way of putting it, make absolutely all changes to what you are about to publish before publishing it.

If you find that you need to make modifications in order to publish, then you are not yet ready to publish. This includes extruding that extra edge, assigning that extra shader or setting that extra attribute. It’s likely you are lacking other tools, unrelated to publishing, and are trying to do too much with publishing alone.

Publishing is about output.

Now, the fact that the GUI provides an option (through actions) to make modifications within the publishing GUI (but still not during publishing, thank god) is a great regret of mine that I fear is adding so much time and confusion about the role of publishing than the time it saves by enabling artists to make quick fixes. I believe that if I hadn’t given in to implementing this feature, you would all have already built a much better and maintainable alternative by now, but instead you’re stuck with this insufficient mechanism. Great short term, bad long term.

My recommendation is to build your understanding and pipeline around publishing through CVEI alone and think only of actions - and modifications during publishing overall - as a completely separate, extra bonus, cherry on top or ideally do not use it at all. You don’t need it. Great short term, bad long term.

< \rant >

#59

Thank you for the rant, I quite liked it :slight_smile:

This actually fits us quite good at the moment. We’ve already decided to not implement the actions interface in our first version of the tool. The smaller the api surface of pyblish-base, the better in my opinion. That said, I see the usefulness of it and we will probably implement it eventually.

#60

Even though I understand the standpoint @marcus presents, I’m very happy to hear this. After having used action\repair I can hardly imagine switching to system without it. It is a massive selling point of to us and saves tremendous amount of time in hectic production.

1 Like