Repair

[mottosso]

Add missing feature, to trigger a plug-in's repair functionality.

[mottosso]

Implementing in 0.2.8

[mottosso]

Standing questions

There are a few things left to consider in terms of user experience when it comes to repairing; it all comes down to how specific one can/should get.

When to show the button?

At the moment, the repair button isn't shown until there's been an error. An alternative is to have it visible always, for plug-ins that have implemented any repairs.

Spontaneously, I'd think that exposing the repair buttons would make life easier in some cases where the user already knows what is wrong and is just looking for a one-off repair. On the other hand, it may also cause users to run repair on already valid plug-ins in which case your implementation of the repair is responsible for not breaking what already worked.

Who is repairing who?

The other thing is, should plug-ins have the repair-button, or instances? Which makes more sense?

On one hand, it would make sense to repair a broken instance, but which plug-in would actually be performing the repair in cases where multiple plug-ins can perform a repair? On the other hand it also makes sense to repair a single plug-in, but then how do you control which instances you are repairing?

[mottosso]

Known issues

The current commit have a few limitations.

• The plug-in will update itself to reflect whether the repair finished successfully, but instances will not. There's some fairly involved logic in doing that, mainly keeping track of whether or not it had errors from other plug-ins than the one you just repaired, in which case it should still show "Red" even though the repair finished successfully.
• You can only repair plug-ins, which will try and repair all instances, even those that were already valid.
• Repairing a plug-in will effectively cause all supported instance to be repaired; including those that did not fail validation.

[mottosso]

Repairing a plug-in will effectively cause all supported instance to be repaired; including those that did not fail validation.

Fixed in the latest commit.

[mottosso]

Basic implementation available in 0.2.8

[tokejepsen]

Maybe I should have separate issue for this (?), but a "repair all" button would be great.
That combine with a reset of the interface, so the user can hit "repair all" and then "publish". On that same note I was thinking about an order of repairing, example being saving the scene last.

[mottosso]

Would it make sense to repair them in the order they are normally run?

[ghost]

I'd say it does

[mottosso]

Just a note about repairing in general, and I realise this is highly debatable, overlaps into studio policy and might even be a tad controversial, but I think it's an important consideration to keep in mind as a developer, especially when looking at the longer-term productivity of your team as a whole and is something we should discuss before spending more time developing it.

"Should there be a repair?"

Let's look at the advantages.

1. When something simple happens such as forgetting to save your scene, repairing shaves around 3 seconds of an artist time spent publishing.

Now let's look at the disadvantages.

1. When a repair breaks a scene, seconds, minutes possibly hours and days are added to an artists time spent publishing.
2. When a complex or otherwise invisible repair happens, seconds, minutes possibly hours or days are added to an artists time spent debugging his own scene after having it be modified by Pyblish.
3. The ability to repair invites laziness and paying less attention, causing a larger and larger dependency on the ability to repair and thus becoming more and more prone to cons (1) and (2). (I.e. a vicious circle)

Repairing is meant to increase productivity by allowing simple things to be automated, but the more I think about it the more I'm starting to think that it does quite the opposite, especially when looking longer term, and longer term is what matters.

What other benefits and disadvantages can you see? Does it really save more time than it costs?

To be blunt, I'm considering removing the feature all together and instead work towards educating users about how they can produce better assets (and become better artists), with documentation, learning resources and graphical statistics.

[tokejepsen]

What other benefits and disadvantages can you see? Does it really save more time than it costs?

• Detach the users from messing with the system, and doing other things that might break the system.
• Educating people is all great, but when artists are being switched out this education gets lost.
• The time saved is not only for the duration of the repair function, but making sure the validators get corrected properly. Obviously this one of the overall benefits of Pyblish, but repairing correctly truely helps fixing things and fast.

To be blunt, I'm considering removing the feature all together and instead work towards educating users about how they can produce better assets (and become better artists), with documentation, learning resources and graphical statistics.

I would strongly disagree with this choice. Having to not explain to people what exactly what to do and also replying on them is big time suck for smaller studios where a dedicated pipeline developer position is non-existent.

[mottosso]

Thanks for your input @tokejepsen, don't worry, nothing is being removed without everyone being on-board.

Detach the users from messing with the system, and doing other things that might break the system.

Could you provide an example of this? Not sure I understand.

Do you mean there is something that an artists needs to do to their data before publishing, that they shouldn't be trusted in doing? What could that be? Any are you sure Pyblish is the right man for that job?

Educating people is all great, but when artists are being switched out this education gets lost.

Education can go both long- and short-term. Consider the save-scene repair (sorry to keep picking on this one plug-in), by instead clearly letting the artist know that a scene must be saved before it can be published, he will already have learned more about how to work in the current pipeline.

I think for anything more complex, no tool can make a better decision than a human.

Having to not explain to people what exactly what to do and also replying on them is big time suck

How about documenting what each validator is looking for, and providing detailed information about how to correct it in each exception?

This is exactly the kind of problem that this is meant to solve. An artist should be able to find everything he needs about any particular plug-in/validation right there in the interface and exception messages.

If the messages/documentation isn't clear enough, then we should have a chat about how to make it more clear.

See here

• Plug-in Documentation
• Log Messages
• Exception Messages

In short, the three responsibilities are:

• Documentation provides an overview of what a plug-in is doing/looking for
• Logging messages provides a papertrail of what it has done
• Exception messages provides users with exact information about how to fix their problem

Each layer in combination is meant to provide each user with all the necessary information.

The time saved is not only for the duration of the repair function, but making sure the validators get corrected properly.

Is this related to the first quote? It sounds like there are things expected of an artist that the artist cannot be trusted with doing, in which case Pyblish might not be the best fit, but rather a dedicated set-up/initialisation tool.

The need for an initialisation stage has come up more and more frequently lately, I think it may be time to properly dive into what that is, and what it can do. It would be a mistake to rely on Pyblish for this, as it can only go so far and there won't be any support for it at all.

Let me know your thoughts on this, and perhaps I can put something together about where Initialisation starts, and Publishing begins.

[tokejepsen]

Could you provide an example of this? Not sure I understand.

So the specific action I'm thinking of, is when versioning up write nodes in Nuke, the directory doesn't get created. This only gets flagged when sending off to the render-farm, which fails the job.
Having artists making directories can get messy.

I guess this could be related to initialising the work file, but makes sense to validate and repair for convenience.

I think this is about workflow speedups, so clicking a button is much faster than making a directory. Artists just want things to work, they don't care about how its working.

[mottosso]

Would it perhaps make sense to perform the versioning up in an extractor or conform?

[tokejepsen]

Would it perhaps make sense to perform the versioning up in an extractor or conform?

I can't see why that would make it better. You would end up with a work file that always has version 1 as output, and maybe some weird version control system for extract/conform.

[BigRoy]

Sorry for joining a bit late.

@tokejepsen I think @mottosso is referring to the fact that you could write an extractor/conform that saves it there, if so you could write it in a way that it does ensure the directory is there?

Overall I'm on the boat with @tokejepsen, the speed and ease of use should be first priority when doing things like validations and publishing. Saving an unsaved scene is something that can quickly be done by an artist, but there are more complex examples out there.

Validation: No multiple UV sets

Checking for multiple UV sets. Simply, Alembic that ships with Maya doesn't support multiple UV sets (not sure about 2015+) so it takes 'map1' instead of the currently active one. Of course there may be other choices for any validation outside of such a strict technical boundary (eg. artistic, even though validations would be harder?).
I would opt for having a "Select/Highlight" button that shows me what meshes have multiple UV sets, plus a button that would repair it that would ease removing all redundant uv sets.
For an artist this is a hassle to deal with, unless you have a script. ;) Without these tools you need to read from the failed Validator which nodes might be messed up (could be plenty!), find them in the scene, then for each single one you need to copy the current uv set into map1 (if it isn't yet) and remove each other uv set individually.

Yes, the UV set solution that the repair button offers is not guaranteed to be the solution how the users wants it to be for 100% of the cases, therefore I wouldn't have auto-repair or something like that set to True. But the fact that in 99% of the cases it's a 1.000x speed-up is what makes it a best-case scenario. Of course the user should still know what it's actually doing to some extent, but isn't that the case with most tools?

Auto-repair

The only thing I'm a bit against is having an auto-repair on by default. As you state, at least allow the user to know what is wrong with his scene. And if he knows what repair will do and it helps him in that scenario then let him do it!

About the long term statement

Don't forget that many bigger projects involve freelancers that might not know anything of your pipeline. They are as much in the picture for long term goals as anyone else in the team. The fact that Pyblish validates and tells you what is wrong is amazing and very important! But if you get a freelancer on board that needs to do a single character in a day or two how much time would you like to have him spend knowing all the ins- and outs of your validations plus getting to his own solution for each of them instead of doing what he was asked for: making a kickass model.

To be blunt, the freelancer wouldn't care if his output is saved to format X or Y. He might not even know what format Y actually is (might even be proprietary or in-house!) As long as he can work in his own workflow (model in his most efficient way (quality + speed) because that's why you hire him) he'll be most useful.

Also if something is pipeline related that needs to be fixed then most often you won't be or want to be teaching them to make folder X, folder Y, database-entry X, rename to XY, etcetera all manually. Instead you would tell them to go and press that pipeline button that brings up a menu of buttons and press button saying "Save scene". It's still a button, just elsewhere? And did it really help/improve the artist?

[mottosso]

I think we're after the same thing - to increase productivity and lessen the time to finish for any artist.

Some of the things you mention, such as creating folders and removing sets from hundreds of objects is something better handled by a machine, that is true.

Perhaps my motivation for suggesting it's removal could be made clearer by painting a picture of my experiences with repair.

Motivation

To me, repair has been a 50-50. The buttons were dangerous to me and before I dared clicking any of them I had learned from being burnt in the past to better save my scene. As time went by, I found myself understanding the intentions of the repair and made it part of my workflow.

This was a repair tool that did not tell you what it did, nor did the validations, other than it's name - such as ValidateNamespaces. So figuring out what was actually required to pass this test by witnessing the havoc created by it's repair took both time and frustration away from what could instead have been spent on making great output.

See, we're both striving towards the same goal, and I can certainly see how having a repair could speed things up, this was (hopefully) the intentions of the tool from my experiences as well, but at the end of the day it told me "I don't trust you to understand, and even though I know nothing of your current scene I know best how to fix your problem". This made me feel helpless, the opposite of empowered.

Clarity

Also if something is pipeline related that needs to be fixed then most often you won't be or want to be teaching them to make folder X, folder Y, database-entry X, rename to XY, etcetera all manually.

And

To be blunt, the freelancer wouldn't care if his output is saved to format X or Y.

I don't think you're saying that this should be up to a repair button, but rather built-in to your extractor that actually performs the export to the given format, and places the files where they belong, is that right?

As a rule of thumb, would it be safe to say that repairing should always be optional?

Summary

There are three equally important problems brought up here, but only one of which I believe is suited for Pyblish.

1. Repairing in ways that could never fail - saving a scene
2. Performing complex repairs
3. Performing pipeline duty as a repair

The intent of repair was always about (1), if you find yourself doing (2) you run the risk of reliving my experiences, and my initial points about why repair should be removed. For (3), be careful, and remember if it isn't optional then it might not be as much about repairing and might probably be better off as a mandatory plug-in.

It's still a button, just elsewhere?

Just a small note about this; yes, it is my intent to separate between what is about publishing from anything that is not. My goal is for Pyblish to do as little as possible as good as possible, and delegate any other responsibility to separate tools.

[tokejepsen]

My goal is for Pyblish to do as little as possible as good as possible, and delegate any other responsibility to separate tools.

I was thinking that when we are validating a work file, it really doesn't make sense to me to have to jump to another tool to repair. You say there is a problem with the scene via the validator, and you offer a solution that is quick and easy. Anything else would hinder the artist doing what he is supposed to do, which is burn through shots.

On the other side, I do agree that the current implementation of repair might be too easy for the artist. They never leave the overview and therefore don't know about what the problems are they are fixing.
Some sort of confirmation button with formatted documentation for the artist to easy read what the problems are could be a solution. At the end of the day, some people, like us, would like to know what is happening behind the scenes, others just want to get on with the work at hand.

[mottosso]

At the end of the day, some people, like us, would like to know what is happening behind the scenes, others just want to get on with the work at hand.

I'm with you on that, this is why repair exists today, quick fixes and "get on with it" solutions.

The reason for this discussion however is not about the immediate gain of repairing, but the longer lasting ones. At the end of a project, does this equation end up on the plus side?

time saved repairing - time lost debugging repair = ?

[BigRoy]

As a rule of thumb, would it be safe to say that repairing should always be optional?

Yes. Since the user either runs it or not. I would not automatically run it. ;)

For (3), be careful, and remember if it isn't optional then it might not be as much about repairing and might probably be better off as a mandatory plug-in.

Correct. Clicking the button is optional, you should still be able to fix any problem in a manual way. A solution is only provided for sake of simplicity and speed.

That's also what I meant with Actions. If we could easily implement different functions per plug-in that pop up the Repair functionality can be built on top of it. But also make it easy to add a 'highlight/select' functionality next to it. Visually it's just buttons next to each other performing an Action. We're only assisting the artist, not forcing.

It's not there because they have to press it.

On the other side, I do agree that the current implementation of repair might be too easy for the artist. They never leave the overview and therefore don't know about what the problems are they are fixing.
Some sort of confirmation button with formatted documentation for the artist to easy read what the problems are could be a solution. At the end of the day, some people, like us, would like to know what is happening behind the scenes, others just want to get on with the work at hand.

Yes, exactly. Though the repair should be usable as easily as pressing the button it's equally important to ensure the artists get a grasp of what is happening.

[tokejepsen]

I would also pose the question of whether its worth artists/supervisors to know all the solutions to pipeline related problems, when they could be focusing on other important stuff?

We know that software changes, and the pipeline solutions we have right now probably won't last the next year. Having a whole team that knows the ins and outs of software and pipeline would be great, but I don't think that is a realistic goal simply because some people just don't want to know.

Think this discussion could go on for a long time, as I think this boils down to personal opinion and past experiences.

[mottosso]

I would also pose the question of whether its worth artists/supervisors to know all the solutions to pipeline related problems, when they could be focusing on other important stuff?

Hold on a second, are you saying that you expect supervisors to publish an artists work, and also repair it if validation fails?

Think this discussion could go on for a long time, as I think this boils down to personal opinion and past experiences.

It could, but I think it's a healthy discussion to have, both now and for the record. No feature should exist without strong reason.

[tokejepsen]

Hold on a second, are you saying that you expect supervisors to publish an artists work, and also repair it if validation fails?

No, but here supervisors do work as well. And they are expected to be the people to go to when there is a problem.

[mottosso]

I see, I'm sorry, but that just seems to make repairing even more dangerous.

How long would it take for a supervisor to debug a repair he didn't understand? How much of everyone else's time will be lost diving into his work?

time saved repairing - (time lost debugging * number of people involved) = ?

Sounds like a dangerous game to me and another reason why publishing and working should be kept very separate. :S

[tokejepsen]

Sounds like a dangerous game to me and another reason why publishing and working should be kept very separate.

Don't know what else to say than I don't see that what the problem is. If you test your repair methods thoroughly I really don't see what the danger is. I would be very hesitant with doing complex repair, that could be destructive, but simple repairs that people can easily forget in the heat of production can only be an improvement.

[mottosso]

Here's what I'm proposing.

1. Pyblish remains non-destructive. It will have no ability to affect the state of the current scene. It can validate and serialise.
2. All that you do with repair today in the future is delegated to other parts of the pipeline/other tools.

The simple fixes may be necessary, complex fixes may be too, I'm not opposed to that, but I don't believe Pyblish is the platform for it. As you've already got assets associated with families, and a discovery mechanism to discover plug-ins, building such a tool using the Pyblish framework might be the fastest way forward and should be relatively straight forward, allowing you to get the same encapsulation and reuse as you have today, but the responsibility lies with you and the development of Pyblish can remain focused on publishing.

Again, it's only a proposal, nothing is being removed unless everyone is on-board.

[tokejepsen]

One more thing, which is far less important but worth mentioning is the PR of the repair button. It looks good when presenting to new users and potential developers. Fixing your scene, quick and easy looks very good on a demo.

[BigRoy]

@mottosso I understand your idea and really like you're backing the plans you have in your minds as strongly as you are, thanks. I'm still with @tokejepsen though.

How long would it take for a supervisor to debug a repair he didn't understand? How much of every one else's time will be lost diving into his work?

Don't forget the time that might have been gained by not needing to grab the attention of a supervisor. Yes, things that do some nasty behind the scenes stuff should be avoided, but that's still up to the individuals to use it. Even if the repair might be dangerous I would add it in there. Maybe giving them a big warning sign when they run it to make sure they know what's happening. But the ability to provide solutions that have worked in the majority of cases is important. Just like how you like that artists learn it's the same with solutions. Use what's learned to your and everyone else's advantage. You don't want everyone to learn the same thing which results in everyone needing to learn everything.

As with @tokejepsen's arguments I also agree it's a fundamental element for the validation + publishing process. We had taken similar steps before where during publishing the users gets a pop-up message stating what is wrong with the scene and ask whether he wanted to either deal with it himself or dare to automatically repair it.

Getting the right data from your scene can be a lot harder than 'just exporting' and you might need to do changes to the scene that can't be undone. (Maybe import a reference to alter a setting so extraction can be done correctly). So to be non-destructive in some cases saving a scene is required, then load it back up. Though re-loading a scene should be kept to a minimum! Saving a scene and loading it directly doesn't mean Maya will not change anything, even that is non-destructive.

Also I think it's a good habit to learn to save before doing any repairs, even if you're doing it manually.

[tokejepsen]

Also I think it's a good habit to learn to save before doing any repairs, even if you're doing it manually.

Maybe the solution would be to have simple "rollback" feature. It saves the current state of the scene before repairing. If something goes horrificly wrong, the user rolls back. Just a quick thought though.

[mottosso]

But the ability to provide solutions that have worked in the majority of cases is important.

Again, programmatically making alterations to your scene can be useful depending on the studio, the question I'm raising is whether it's related to publishing.

Getting the right data from your scene can be a lot harder than 'just exporting' and you might need to do changes to the scene that can't be undone.

This is unrelated to repairing.

Maybe the solution would be to have simple "rollback" feature.

It's a good idea, and one that would have a strong impact on productivity and lessen the amount of time spent in total during production.

The thing is, every minute spent implementing a rollback feature is time lost creating a stronger publishing software.

In fact, just listening to your needs in this thread makes it very clear to me that programmatically altering your work is perhaps equally important to the publishing itself. What I am suggesting is that we give it the attention it deserves, rather than stick it into the Pyblish GUI.

Pyblish Repair

We could go as far as creating Pyblish Repair, with a dedicated GUI for making changes to your scenes, with proper rollback and whatever other feature we come up with.

If could end up right next to File > Publish as File > Repair.

Pyblish Repair could be an excellent spot for arbitrary scripts, e.g. @BigRoy's Actions. By making a clear distinction between Pyblish and Pyblish Repair we:

1. Separate development, meaning others (you) could work on what matters to you
2. Separate responsibility, for both developers and artists
3. Developers could roam free, make destructive changes
4. Artists know what to expect

Thoughts?

[BigRoy]

Maybe the solution would be to have simple "rollback" feature.

As @mottosso also states implementing rollback or undoing functionality will become quite the hassle! It's a lot of work, especially to do it right. (Even saving -> loading in Maya doesn't always return the exact same scene. The same thing with undoing, it's not always the same as 'not having done the action at all')

We could go as far as creating Pyblish Repair, with a dedicated GUI for making changes to your scenes, with proper rollback and whatever other feature we come up with.

I think the key of this discussion is to not have it seperated since the convenience is in it being close. Even if it would redirect you to another UI where you have to press a button it's an inconvenience for the user. The pop-up I mentioned to choose "manual" or "auto" fix was actually implemented based on annoyances of the users that received a pop-up "There's an error in the scene. Fix this and that. Possible automatic method is 'here'."

Getting the right data from your scene can be a lot harder than 'just exporting' and you might need to do changes to the scene that can't be undone.

This is unrelated to repairing.

Yes, but not unrelated to the functionality of Pyblish. Being non-destructive sometimes even is impossible (or extremely complex) during an Extraction.

[mottosso]

Yes, but not unrelated to the functionality of Pyblish. Being non-destructive sometimes even is impossible (or extremely complex) during an Extraction.

I'm with you, I just meant this isn't the place to have that discussion.

I think the key of this discussion is to not have it seperated since the convenience is in it being close.

It sounds like you and Toke are referring to two, equally important, aspects of conveinence.

1. An artist/supervisor shouldn't need to know details of how to repair.
2. Repairing a failed validator should be fast.

Pyblish Repair applies well to (1) and I bet (2) wouldn't cost more time than it saved, especially given a Pyblish Repair GUI could provide more feedback and more features than the Pyblish GUI would be able to.

[mottosso]

Here's some more ideas on Pyblish Repair.

For access to Pyblish Repair, an icon could be provided via Pyblish QML. Alternatively/additionally, a menu-item similar to the current "Publish".

Features

1. Provide an option to repair failed plug-ins from last publish
2. Provide an option to repair any plug-in, not just failed ones.
3. Provide arbitrary actions to be applied to any plug-in
4. Provide an option to roll-back any action

Could Pyblish Repair be a potential way forward? What disadvantages do you see? What advantages can you imagine?

[tokejepsen]

Could Pyblish Repair be a potential way forward? What disadvantages do you see? What advantages can you imagine?

Obviously what @BigRoy said about the closeness/convenience of having one tool/button compared to two. But I wouldn't mind it so much, as long as Pyblish Repair is straight forward, ei. Repair All button.

I can see why you want to separate the two tools, and I think its a good idea.
Apart from the mentioned features maybe more rapid development due to less dependencies with Pyblish QML.

[BigRoy]

Sorry if I misunderstand. But if the solution is to keep 'repair' close to the plug-ins won't separating it be the wrong way forward? It would make things much more complex implementation-wise plus debug-wise?

Now you're trying to make it separate but implement it in such a way that it's available inside Pyblish. ;)

[mottosso]

Here are two more suggestions.

1. Add a solutions attribute to each plug-in, containing the absolute path to a callable with optional docstring explaining what it does. The callable could appear as form of a drop-down/right-click menu upon any plug-in failing. This would include repair, but also any arbitrary callable, but would not facilitate much further development in this direction; meaning no reports or custom behaviour or responses from a triggered solution, clearly partitioning it's role from publishing, becoming an "add-on" at best.
2. Develop a separate context-sensitive toolbox that uses the same selectors to identify assets, but presents the user with an arbitrary selection of callables that operate on the discovered instances. This way, you get the benefits of context-sensitivity (i.e. families) along with the ability to develop any scripts you want, without "derailing" Pyblish.

Solutions example

class ValidateInstance(...):
    solutions = ["mymodule.repair", "myothermodule.select_in_viewport"]

At which point, the callable may contain.

def repair(instance):
    """optional docstring as documentation"""
    do_something(instance)

The (optional) arguments being dependency injected. such that it can operate on any combination of context/instance or none at all.

[mottosso]

In short, I think we've established in this thread that the ability to have arbitrary scripts get deployed under the right circumstances (e.g. project, asset, artist) and having them executable under the appropriate time (e.g. failing validation) is a useful one.

So useful and important in fact that I think it deserves it's own development and dedicated attention (which is it getting in a plentiful of studios already). The bottom line is that automation is useful everywhere, and I think it would be a mistake to try and get Pyblish to perform it all and better to keep it's reach as narrow and focused as possible, and allow surrounding tools to compensate for what it is missing.

Having said that, and as mentioned above, the Pyblish framework is still useful in developing these tools. The discovery mechanism and methodology of identifying Instances during Selection is well suited for deployment and execution of these tools which is something we can have a look at building, thus still benefiting from the development of the publishing part of Pyblish.

Thoughts?

[tokejepsen]

Here are two more suggestions.

To be honest I don't really mind any of these solutions. The main thing for me is that the users have easy access to repair from the publish UI. I wouldn't want them to have to quit/close the publishing UI to open another tool.

[tokejepsen]

Has this not been superseeded by Actions?

[mottosso]

Yes, it certainly has!