Bruce Lee
Hi! Peter,

I have an idea. Can you make an editor for a soup, just like a mash editor? Simple and powerful, it's easy to combine different nodes.
Thank you!
Quote 0 0
Bruce Lee
Maya now has more and more new features with its own editor. Their style is roughly the same. Such editors are simple and powerful, and artists like them very much. I really hope that the soup also has its own editor.

QQ截图20180402214140.png  QQ截图20180402214222.png  QQ截图20180402214310.png 
Quote 0 0
Something like that sounds useful. What kind of data did you have in mind to merge in the lists?

I was thinking that a kind of multi Group node would be interesting for streamlining the daisy chaining of group nodes for component lists. Similar to the list in say, Nuke's Roto node, where order and combine methods are quick to change. However it seems like the list could become cumbersome if all of the Group operations and their attributes were nested in each layer. You also often want to key the operation attributes and probably wouldn't want to limit that functionality. A combine component list node that takes a number of component lists and only deals with combine options in a list would be useful on its own tho.

A couple other places that I can imagine it being convenient to merge in ordered lists is equal length arrays and bounding objects.
Quote 0 0
It would be feasible from any node connecting POV. You could create new nodes through the UI and nest other nodes based on connections. Have the smartConnect pop up as you introduce more nodes and obviously have a smart select so that whtever node you have selected in the UI changes the attribute editor or highlights the node in the node editor window so that you can change attributes there. Perhaps only some controls could be exposed on the UI like Active, cant really think of anything else. You could remove nodes by deleting each item on the list or middle mouse drag off the UI, even middle mouse drag an item to disconnect and reconnect further down the list, cancel the move by esc off the smartConnect.
Quote 0 0
I think we need to make a differentiation between tools and general DG.

The tool UIs are more or less trivial to implement. SOuP is full of them - pretty much everything in the "tools" section is basically a GUI. Many nodes have GUIs too - like morph, blendShapesManager, etc, or comprehensive AE templates that serve the same purpose (collide, cocoon, etc). I don't think there is shortage of that in SOuP.
Now, i admit, i am technical enough not to need too much hand holding, so i am not the best judge when it comes to what is the best solution for the average Maya artist.
GUIs are less important to me personally. As a result, i tend not to put the utmost attention in them, unless pushed by external forces. There are couple of examples like that - Morph, blendShapesManager, SlidersManager, etc, but also, there are many other GUIs that can be for sure better.

When it comes down to GUI that addresses the general DG workflow. That's a whole different story.
Let's start from the fact that Maya, Houdini, Nuke, UE4 (blueprints visprog), Katana, and other node based applications don't have such GUIs. Basically their node editors are that.
Now, if we analyze the difference of their dependency or visprog graphs it becomes clear that Maya's DG is far more complex. Houdini, Nuke, UE4, Katana have nodes that have between 1 to 4 inputs and usually a single output, while Maya's nodes have *a lot* of inputs and outputs that make it hard for the untrained eye to grasp what is going on.
MASH is largely based on the MFnArrayAttrsData class which creates a key-value pair based map structure. Data is packed within a single object and passed through the graph via single connection. MASH nodes operate on it in a more or less stack-based manner. It is the nature of the underlying structure. This makes the system a better candidate for a stack-based UI. Now, don't get me wrong here. Fact is that Ian did an amazing job there and made it look all too easy is, while in reality it is not easy at all.

Back then, at the beginning of the SOuP project, i had to make a decision - do i go that route which is more similar to how Houdini packs its data, or go the Maya way. At the end i decided to go the Maya way, because the baseline MFnArrayAttrsData is limited by nature and it was clear that it will eventually become a problem that will require workarounds - basically conforming at least partially to the standard Maya ways of doing things.
Why i am saying this ?
Because it is actually really hard, i would say impossible, to express through a stack based GUI what is actually happening on a standard dependency graph. Again, there is a reason Maya does not come with a stack based interface after all these years. There is a reason why MAX and XSI which are stack based, don't have a dependency graph. They are kind of mutually exclusive.

For example, how you would express the next network in a stack based GUI ? a.png
I am seeing here at least 3 parallel chains which just cannot be expressed on a stack UI.
The number of permutations on a DG to achieve particular result is too high to reliably predict what the user want to do, to wrap it in a GUI.
This is the reason i am still considering how to approach the problem, in regards to SOuP at least.

At this point i am doing next couple of things:
- the commands inside the "SOuP nodes" menu are selection sensitive. Which means that if you have selected objects in the scene, the code will try to construct a network for you that does what one would expect from it most of the time. You can try with the cocoon node for example.
- i provide bunch of node-view templates that are designed to remove visual clutter in the NE and display only the relevant inputs and outputs. This used to work really well until a while ago when Maya developers introduced a bug that makes Maya dismiss the custom node-view templates, unless one points to the right location using envvar.
- smartConnect - simplify the connection workflow, by streamlining and cleaning up the view when making connections between nodes. Handling of multiple nodes at once. Works everywhere, but not just the NE view. Handles properly transform/shapes selections instead of requiring explicit shape-shape selection. And many more.
- consistent naming convention for attributes - inGeometry, outPositionPP, outNormalPP, etc.

With that said, i am not quite done with the subject. I have some concrete and some vague ideas about SOuP DG-related GUI, that i will try to implement at some point soon.
So if you have any suggestions, or examples that we want to look at - don't hesitate - bring them on.

Quote 1 0
Actually I did forget about the smartConnect which can work anywhere on the screen with any selection.
Quote 0 0
I think isn’t possible have a stack modifier applied to SOuP.
Instead I suggest to create some script to automate te most common SOuP network.
Quote 0 0
Agreed. This will be the scope of the initial work.
Quote 0 0