Graphical User Interface Design #41
Comments
|
Think you might be saying this, but enabling/disabling selectors/validators/extractors. |
|
Yes, that's true, besides enabling/disabling Instances (e.g. already selected models, rigs etc) one should also be allowed to enable/disable plugins. Also, some plugins should be mandatory, as in they cannot be disabled because they is vital to the overall function of production.
|
|
guessing this would an appropriate place to start thinking about auto-fixes for validators? |
|
Sure, do you have any ideas? |
|
I think we should create a smart application that, when run, automatically detects all stuff in the scene and with selecting any stuff in the list we can access to all properties of that, both existing properties (to modify) and we can able to create new properties. And in it we can create sets and connect all stuffs that we want to each other.maybe it is possible to create a node-based view for that. I mean when we open the publish we don't need to open other windows of maya like attribute editor or channel control or ... Make sense? About GUI I prefer to have hidden windows that appear fast when we need them with animation.
|
|
was thinking something pretty similar to Guaard, as in:
We do need to implement auto-fix function, hence #43 |
Yeah, this is how I'm picturing it too. There shouldn't be a need for manual addition of attributes in Maya. That way, we can keep the workflow consistent across hosts.
Do you mean, that instead of closing the window, and re-created it, it should get hidden and shown for better performance? We could do that, but I wouldn't worry too much about performance yet.
+1 |
|
I like the idea of "Quality Guard", which looks really promising. I would like to separate the validators window and publish window. publish window something very simple and minimal options without having too much confusions to the user. Validators sometime preset for a show(or a department) that is user doesn't want to spend more time on turning on and off validators. thoughts? |
Shouldn't the user know about any errors the Validators throw? |
That is a good point, I also think that the main Publishing window should contain only bare minimum that an artist would use. Beyond setting things up, I think the only variable left is adding an optional comment about what you are about to publish. Anything else can be taken from the previous setup - like ranges and selected nodes - or the environment - like who publishes, and when. For the established workflow, there really shouldn't be much need to even set things up; I'm thinking about an animator importing rigs and getting to work. When he decides to publish, rigs could already be tagged as publishable and contain all their relevant configuration. At that point, the artists could merely hit "publish" and have everything else automated. Whether there should be two separate windows, or one window with a hidden or tabbed "configuration" area, I'm not sure. |
|
What I am saying , user doesn't want to set validators everytime while they publish, it should be optional. for example: the lead set some of the validators which is applicable to a department, it has to be saved and available to everyone who belongs to that department. The validators can be in separate tab in the publish GUI.
of course they have to. process are all the same, but the usage wise is different |
|
One more thing, the order in which plugins occur will also have to be visualised, along with their potential hierarchy. E.g. some validations may make less sense to run if a parent validation has already failed. Such as, checking for the point-count of a mesh, if the mesh is already missing. |
So we should look at how to chain Validators together? |
|
Possibly. At some point or another, an order will have to be specified. It would either have to be up to the artist setting things up, or the developer of the plugin, or some other, possibly automatic process. |
|
Even we can visualize all the background task happening while running the publish process, this way user will have clear idea about what is happening and where exactly failed rather looking at the script editor(most of them never looks at the script editor rather shoot a mail to pipeline department saying process has been failed.) Thoughts ? |
|
Summarising a conversation with @madoodia here:
In short, validation ensures correctness, extraction writes to disk and conform moves files around.
At the moment, which validators to apply to which instance is based on its "family". E.g. for a family of "model", all validations for family "model" are applied. The same is true for extractors and conforms.
That's how I imagine it, at least. A validation can fail, just like an extraction can too. Like if the network is down, or the disk is full. It's important to alert the user of this. The same would then also be true of conform.
Not necessarily. It's important to think of the order in which these steps occur. Which means that validation can't begin until selection has happened, extraction can't happen until validation has finished (successfully) and so forth.
For example, when extracting a model from your scene, it may be helpful to export it as an
We haven't dabbled too much in conform yet, but in a nutshell, a studio will most likely have a very specific location on disk at which to store assets. Once Publish finishes extraction, files will be available on disk, but most likely not in the idea location for that particular studio. Conform then is responsible for taking these files and moving them to their final destination. We can't know exactly where this location is beforehand, which is why we will have to make it extensible and configurable enough for others to implement their own conform. This is what is being worked on in Issue #9.
Plugins and families are matched at run-time and the only association between them are their names. Meaning, if there is a plugin for family "my custom family", then that plugin will get run against any instance with the same family.
You will have to implement it, using Python, following the abstract base-class for that particular plugin - Selector, Validator, Extractor or Conform @BigRoy is working on an implementation that differs slightly from how I've explained things here and, the way I see it, his vision is the direction we'll be heading, but I'm confident that the designs we can muster using our current implementation and understanding will apply equally well to any future designs. |
Plugins will typically be created by TDs or developers with programming experience, rather than by the artists themselves. This means plugins can only really cover higher-level concerns in productions, like "does this model have inverted normals?", as opposed to the finer-grained issues artists may have while working on a particular asset, such as "did I forget to skin any of my meshes?" or "does any of my controls have animation on them, that shouldn't be there?". This last part however is something that I'd like to change in the future and is something I think will be more easily customisable once we move into more granular plugins and nodes.
Typically, an artist would publish whenever his work is in a shareable state. E.g. when a first version of a rig is ready for use, the rig will be published by the rigger. The animator, using the rig, would in a similar fashion publish his animation using the same button - once his animation is in a shareable state.
This is where Conform comes in. Once extraction is done, there will be files on disk, typically located relative your current working file. # E.g.
/projects/spiderman/assets/Peter/rig/madoodia/maya/scenes/my_scene_file.ma
/projects/spiderman/assets/Peter/rig/madoodia/maya/published/20140821_084314/published.objConform plugins will act on this file, moving it to its final destination. Wherever that may be. It is up to the end-studio to define their own plugins for conform. These are excellent questions, @madoodia, and things I've mostly taken for granted. I'd encourage anyone to step forward with any other questions you may have. If your answers differ from mine, do feel free to step in and help out. Everything is up for discussion at this point. |
|
Excellent answers ( @mottosso ). :) |
|
Nice Sketches! I had a long chat with @mottosso yesterday about the overall workflow of Publish. We came to the conclusion that the way the families worked only really allowed programmers to define family types and thus the queue or flow of how it published. So I raised the idea of a node graph for how Publish would process it internally and how the user would set it up. Even though I'm pretty busy today the idea is to wrap up by the end of the day what we discussed on this Wiki - Flow Graph page. Here's how I envision the UI for editing the node graph: Note that this is a mockup based on UIs from Autodesk Maya/Eyeon Fusion. How does that influence the current workflow?We would still be able to 'tag' an objectSet with a family and then have a Publish automatically figure out how to process. But we would have to write our own proprietary tool for it. One that gets all families from the scene and figures out what graphScene should be used to process.
Though the concept of what families are internally will disappear, instead we would define strictly typed inputs/outputs for nodes to define whether they are interchangable. This would allow us to write a Validator that checks a list of strings (object names) for naming conventions that could work for multiple applications. So you'll end up with the same validator for Maya as for other software. What does this mean for your sketches?Basically they are still legit views of the data. Because of the way a node graph work (as long as it is not multithreaded) we can predefine the order of its evaluation. Thus list the required data in a normal list and show the processing in that order. I'm a big fan of the view your three sketches present, because it's data the Artist is interested in. Even though node graphs are cool, I would avoid having that view as the default 'processing' view. But it's a very nice method to design flows which is very nice for defining custom publishing situations (based on simple nodes!) |
Guessing we will have a discussion about this new direction somewhere, cause atm I can't envision what the Validators code would look like. |
|
Yes, let's pop up another issue about this I think and focus our GUI efforts on the current workflow for now. Is that ok, @BigRoy? |
Definitely! The idea is that we write it out and propose it as a new direction. It's basically still just a concept that we think could work out really well in the end. Currently my idea of validator code is something like: class MyValidator(validator):
def initNode(self):
# We'll add an attribute to the node upon its definition/initialization.
self.nodes = StringList(input=True)
def process(self):
# During the 'validation' we get the value from the attribute on this node.
nodes = self.nodes.get()
# Now we can do anything with the list of strings (objects) that we want.Note that the attributes are strictly typed to ensure we can only 'connect' inputs/outputs that contain the same type of data. This is similar to how you can only connect a vector to a vector in Maya (or many other DCCs). Anyway, i'll write out the idea and present it! Hopefully soon. :)
Yes, let's do that! |
|
Cool, thanks. :) And I'd also like to clarify, that though we spoke of some really cool stuff that both me and Roy thinks will be a good fit for Publish, no decisions are being made behind closed doors. Everything will always be discussed together, ideally in issues here on GitHub, and nothing will be decided upon without everyone having had their say. I'll be helping Roy illustrate this new concept, but we'll eventually have to convince the rest of you that this is a good idea and I fully expect you to have opinions about it, just like I do myself. And that's a good thing! |
|
I really like the idea of @BigRoy mentioned here. Node graph is very helpfull for configuring and setup a whole system, which later can easily extend to further level. Like he mention the selectors and validators and conform, if we have node graph it is very easy to switch to any type of selectors, validators, and even for setting export location and finally plugging to publish node. There is a similar project called coral app. |
|
@madoodia : your sketchecs looks nice to me, the view 3 is not that much clear to me, the validators are is kind of a exapand window from the clicked instance, or in the same UI? |
|
@ljkart That coral app video does seem to capture the essence of what I had in mind. Nevertheless I think the views that @madoodia laid out are extremely useful. Because as mentioned I would expect that to be presented to the Artist. It's important that the user quickly sees what is not being validated and exactly how/what will be extracted from the scene. As where the node graph would be really directed towards the one that is defining the structure of how something gets published.
And thanks @mottosso for clarifying that to others since that's definitely how I feel about it as well! |
|
Do you think that it would be possible to implement coral within the tool David Martinez - Technical Animator Email: [email protected] On Thu, Aug 21, 2014 at 11:04 AM, Roy Nieterau [email protected]
|
|
@davidmartinezanim Since the UI is in PyQt I think we can definitely dig it up as a reference, but copy-paste or built into it will probably be hard, because we'll also be defining our own rules for how the 'node graph' would behave and translates to other views. @madoodia about the views: view1 I like that you can check out / debug the Instances/Data Publish acquired from the scene/selectors. This is very useful for debugging why something might be showing or missing when extracting. Other than that I think this window is the tool that helps building the data into the scene, correct? Instead of actually running the Selectors/Validators/Extractors. view2 This could be the simplest of views showing only what Selection results into what Extraction. view3: This is pretty much quality guard, which I really like in design! If we can separate Selectors/Validators/Extractors by an icon or color of entry then we can immediately see at each step what will be done. That would really help. We might even be able to 'group' Validators so we show "MESH CHECKS" as one entry instead of 100s of separate small checks on meshes. |
|
Hey guys, Thanks for your attention. This is really a simple sketch, and it should be complete.
And we can think to all of these views as live that regularly update when having Publish open. I just draw circles instead of icons, because I don't know what we need now, we can add every icon (as button) we want to every row, both for instances (View 2) and validator rows (View 3) Make sense?
|
That's a good idea. +1 |
View 1This is a good start for the selector interface. I'd imagine selecting being its own GUI, much like this, but what do you guys think about having it nested as a tab? In practice, I'd imagine selecting to happen very rarely compared with actually publishing, and that it might be better kept entirely as a separate application all together. Other than that, there will possibly be a need to specify exactly which fields there are to edit. This could either be up to the artist, as it is currently when adding attributes manually, or the developer of the UI. It could possibly be defined within each family too; e.g. the Review family could come with defaults such as startFrame and endFrame, like in your sketch. View 2 and 3It looks like View 3 slides in from the right, which button triggers this effect? Also, I'd suggest having both instances and validators visible at the same time, so that when there is multiple instances, we would know, clearly, which one is currently running and which one is next. View 3The circles/icons you mention. What will they represent? Is it a progress bar? If so, I think I'd rather go with a standard, solid rectangle. Overall, I find the layout a bit crowded and could use a little more focus. Do you think you could mock up an alternative layout, with a little more room to breathe? If you can, grab a hold of Designing with the Mind in Mind and have a look at Chapter 3 - We Seek and Use Visual Structure for some inspiration. |
|
First Thanks to @mottosso for formatting my comment. View 1 View 2 View 3 |
|
Ah, so the V-icon (down-arrow) opens up View 3 panel. Ok, sounds like it could work. Does View 3 replace View 2, or does it make the window bigger? |
|
yes,(v) icon is a specific button for every instance,and not replacing,when we click (v) button we have instance attribute in view 2 and expand window with a sub window as roller window that contain validators of the instance is V-clicked |
|
Yeah, that makes sense. Do you think you could mock up a few alternatives? |
|
You mean mock-up from this sketches? |
|
I think this design is good, so let's leave it as-is for now. I'm thinking we could come up with a few more alternatives, with a similar amount of detail, so that we can get some perspective and have something to choose between. Others are free to contribute designs too. This is where it all starts, so post your best ideas and let's get crackin'. :) |
|
I try to creating idea in my mind. |
|
I now see the Class SelectObjectSet in pyblish_maya\plugins\select_object_set.py |
|
As you're about to start mocking up a GUI for Pyblish, let's gather what sort of information you'll need from the backend. In the end, running the GUI will produce the same results as running File -> Publish, which is coming from If the GUI is a single button, this would be that button. The flow of information might look something like this. _________ ____________________________
| | | |
No information --->| GUI |-------->| pyblish.main.publish_all() |
|_________| |____________________________|The GUI doesn't display anything but a button, and thus won't need to get any information from the host. Next, we want it to display available instances. That might look something like this. ____________________________ _________ ____________________________
| | | | | |
|list('instance', 'instance')|-->| GUI |---->| pyblish.main.publish_all() |
|____________________________| |_________| |____________________________|In this case GUI is getting a list of strings from the host. So, as you start developing, it isn't critical where this list is actually coming from. Instead, you can pass any list to you GUI and have it display it. I would recommend doing this at first as you can more quickly mock up fake functions that give your UI data, when you have a number of functions feeding information to your GUI, we can have a look at how Pyblish and Maya can provide that information for you. I know it sounds a little backwards, but here's an example. def get_instances():
return ['instance1', 'instance2', 'instance3']
class MyGui(QWidget):
def __init__(self, parent=None):
super(MyGui, self).__init__(parent)
layout = QVBoxLayout(self)
for instance in get_instances():
button = QPushButton(instance)
layout.addWidget(button)Once the UI displays these items, and has mouse-handling, and the right look, we can replace from pyblish.backend import get_instances
# def get_instances():
# return ['instance1', 'instance2', 'instance3']
class MyGui(QWidget):
def __init__(self, parent=None):
super(MyGui, self).__init__(parent)
layout = QVBoxLayout(self)
for instance in get_instances():
button = QPushButton(instance)
layout.addWidget(button)I'm confident that this will make development much faster for you, as you won't have to bother with Maya and can focus on the task at hand. There is plenty of work to do with the GUI besides communicating with Maya. Does that make sense? |
|
Once we're at a stage where the UI looks good with your mocked up functions, I would suggest we still keep away from Maya, and make plugins that work with pure Python, like listing directories, checking their names, and moving them from one location to another. Pyblish will be able to do those things to, and the process is exactly the same. It just won't have to do any interprocess-communication, making your lives a lot easier. And when that works, and we're all happy about how the GUI looks and feels, then we can start getting complicated. How does that sound? |
|
Yes, very good, i think so, we use abstract methods, and the functions should be implement in backend |
Exactly. :) And this is key - however you design the GUI, whatever information you need, we will make it possible. The trick is not making it possible, the trick is finding out what you need, and I think this is a good way of doing so. |
|
Excellent. |
|
Hi all,
Enable checkbox" and "autofix" is for the "start all" button. The first tab is the department (modeling, shading, rendering...). When we change the department, all "validators" changed dynamically. What do you think about this ? |
|
Hey @deex2, glad you could make it! I think we're on the same page regarding the UI. One primary difference however lies in the The way we're doing that is to instead delegate this responsibility to each instance within a scene. This is so that you can have different types of content within your scene at the same time and thus have different validators and export processes run upon each of them. For example, whenever you publish a model, you may also like to have a turntable published. The camera within the turntable instance could then come with its own validations and extraction options, in addition to the ones processing the model itself. The end result is a GUI with this option per instance being published - alternatively, having this option embedded into each instance within a scene, as it is probably not very common to change this setting once made for each type of asset. Do you have any thoughts about that? For reference, we've also been looking closely at Quality GuAard by Martin Orlowski. Are you familiar with that one? |
Yes this is true. Now i am in the "animation department". As you can see, we have the same family for meshes : modeling So, it is why i have a "Modeling" selection box (this is the department). It is like a "filter". But, the other solution is : in the "modeling department" : It makes sense or not ? Or perhaps i forget something to the global process (?).
Not this one. But we can see that we have some departments/filters on all screenshots (anim, rig, custom). |
I think I understand what you mean and I think the thing that makes Pyblish different is that it is asset-centric, as opposed to department-centric. As an example, if you were in the modeling department of your facility, you may possibly be dealing with creating models. A model is a model, regardless of which department it ends up in and Pyblish can treat it as such. Your example is interesting, about models behaving differently depending on which department you are in, but in these cases, it's possible that an animator isn't handling a model directly, but rather a rig that encapsulates this model. Due to an instance being a rig, it could perform the validation upon the model it encapsulates; in this case, ensuring that normals are smoothed. In practice, the rig could be part of an instance of family playblast. I suppose the key thing to take away from this is that physical nodes in Maya can be part of many instances, and that each instance has exactly one processing chain (family). As an example; in the case of publishing an animation, as a playblast, from multiple angles, each rig in the scene may be part of multiple objectSets, each containing a different camera, with identical families - playblast. As a final note, one thing to stress I think is that it's more important to make many things work in one way, than to make one thing work in many ways. Meaning that if we can find a way to get to the end-result you are looking for, but it isn't in the exact manner you hoped, I'd like to think that we can still consider that a success. I mention this because it is easy to think of ways a certain thing cannot be done with Pyblish as it is at the moment, but ideally it should be more difficult to think of any end result it cannot get to. And hopefully, that is what matters. I think at this stage, we could probably give the specific scenario you posted a go and see what works and what doesn't. Would you be interested in trying that out? I'd be happy to help you out. |
|
Hi folks, We've now got access to PyQt5 in Python 2.7 via PyPI. $ pip install python-qt5This solves one of two hurdles in getting PyQt5, including QML, working on our end-users machines. The other being providing ZeroMQ for Maya, as it's using a different version of Python than what is available via python.org. As a first version, it might have issues, but the few apps I've tried running with it works fine so far so it should hopefully not be anything big. Now get out there and develop with PyQt5! Woho!
|
|
Solving this as GUI progress is now happening here: |
@madoodia is getting to work on a GUI for Publish so I figure it would be a good idea to summarise what it should do.
In order of relevance:
If you can think of anything else, this is the place to put it. I'd imagine we upload mockups of the GUI we envision right here, so we can talk about them together. I've posted the few references we have over in the Wiki - right here - but we should of course strive to be different, to be better. :-) Let's go!
The text was updated successfully, but these errors were encountered: