How do I lose a tweak?


#1

Okay, my character has quite a few items on his input history. It’s getting to be a bit much. I’d like to lose some of the inputs to clean stuff up. The problem is, I’m almost done rigging him and he has a bunch of lattices, clusters, blendshapes, etc attached. Is there a way to incorporate a tweak into your polygon shape and then delete the history so it no long appears in your input list?

What I think I know:

  1. Tweaks are small changes to the polygon shape.
  2. If I merge two vertices on a rigged character I’ll get a tweak item on my input list.
  3. If I simply delete the Tweak item from my input list, the 2 vertices will un-merge, and return.
  4. Delete by type->history will leave the transform, and remove the Tweak input item.

…SO…what I want to do is, remove the tweak from my input list BUT I dont want the tweak to return to its previous state. I guess might call it selective Delete History.

I hope I’m explaining myself well enough. Is there a way to do this?


#2

if you go into the hyper graph, you can select the skin. then under GRAPH…choose GRAPH INPUT/OUTPUT CONNECTIONS this will show you all the nodes attaches to your skin. just look through the nodes for your tweak node, and delete it…then it should be gone from your history…(but save before you try this to be sure)

hope that helps,

sedric


#3

Sedric:

Yes, this will delete the Tweak node, but it will also cause you to lose the alteration/tweak to your shape. When you “Delete by type”->“History” a polygon, it actually incorporates the tweak into your beginning shape, then loses the tweak node. This is different then just deleting the node.

Unfortunately, I’ve rigged my character so I have 4 cluster nodes, 2 or 3 blendshapes nodes, 3 or 4 lattices nodes, one tweak node, and one polytransfer node, all coming into my character as inputs. What I’m looking for is a way to select one (or more) of these input nodes and then "Delete by type -> history JUST the selected inputs.

Right now, if I select my shape, and “Delete by type -> History” the shape I’ll lose all of the inputs, and have to start over rigging.

So does anyone know of a way to selectively incorporate your inputs nodes besides the ALL or NOTHING “Delete by type -> History”?


#4

hmmm…you may have to save your skin weightmaps, and unbind the skin with the “bake history” option checked…then add the weights back after…


#5

Interesting, whenever I manually delete tweak nodes I don’t lose the changes that were made.


#6

Yes! There is a way to do this, and it involves deleting connections, not nodes. Let me prepare a little illustration to explain this in detail, which I will post in a few minutes.

I’ll be right back…


#7

Ok, here we go…

The concepts here are not too complex, but I will explain it as detailed as possible so you can understand well what is going on.

What you should know is this: Whenever an action that has history is created, it copies the previous shape node and hides it, so that it serves as an input to the action node.

In this example, a poly sphere gets some vertices merged, and this is the result:

Notice the greyed out node called “polySurfaceShape1”. This is a copy of what the sphere looked like before merging some vertices. This untouched version is used as an input to the Merge input node “polyMergeVert1”, which then outputs its result to the shape node in use “pSphereShape1”. There is also a backward connection going on, but that is only for controlling the merging, has nothing to do with out discussion.

Now, to this merged sphere, I applied a nonlinear bend (this will simulate the rigging you may have done, I’m using only a bend to simplify the explanation).

Several more nodes are created. Ignore the ones to the right, they are only display and shading group nodes. In the center you will see the actual shape node “pSphereShape1”.

On the top left, you will see the same two nodes that we had before, the original untouched shape node, and the merge input node.

On the bottom left, you will see four nodes, which are created when the bend deformer is applied. “bend1” is the actual bend node, and the other three are auxiliares for it.

The real magic will happen with what you see between the merge node and the bend nodes. An intermediate shape node called “pSphereShape1Orig”. This is created to function as the input to the bend nodes.

Let’s take a look at how the important connections flow: Starting from the top left - “polySurfaceShape1” (the untouched sphere shape) is inputted into the merge node “polyMergeVert1” where the merging action is performed. The merged object is outputted to the magical “pSphereShape1Orig” shape node. So this shape node now has the form of a sphere with some vertices merged. This shape node - by some mystical form - is connected to the bend nodes. So what the “bend1” action node sees is a sphere with vertices merged, and it knows that it has to bend it a certain amount. After doing so, it outputs its result to the actual shape node “pSphereShape1”.

Many other connections are going on here as well, but these are the main ones we need to understand.

Now, to the point. How do we get rid of the merge input nodes WHILE keeping the merged vertices. If you remove the “merge node” as was suggested before, there will be nothing inputted to “pSphereShape1Orig”, and it will behave as a normal sphere (with all its vertices intact). BUT… if you remove the connection from the merge node to “pSphereShape1Orig”, then this “pSphereShape1Orig” will retain its “merged vertices” info, and pass that on to the bend nodes.

The end result: A sphere that has some vertices merged, has a bend deformer applied to it, BUT only has the input nodes for the bend… The merging has now been baked into the sphere - so to speak.

You can now safely remove “polyMergeVert1” and “polySurfaceShape1”, as they are not needed anymore.

In your case, what you will need to do, is to layout all the nodes and connections in an ordered manner, so that you can see exactly how information is flowing from one node to the next, and from this find out which connection(s) need to be removed. (You probably will have 10 times as many nodes as the example I posted, but same principles apply)

I truly hope this helps, let me know if you need help in any of this, I’d be glad to help :slight_smile:

[EDIT: Fixed the links to the images above.]


#8

Hmmm, there is a smilie built for this sort of answer to my question. Oh, here it is: :bowdown:

I will give it a shot. I’ve been staring at my input graph, trying to figure it out. I guess I always assumed even changes made in the hypergraph would still create a history. You’re answer suggests not.

Thank you very much for your detailed response.

-=STZ=-


#9

If you want, try to submit a screen capture of what your hypergraph nodes look like, and I can help you figure out where to place the cut. I know it can be really hard to figure out the flow on a complex setup, but it can be done, and I’d be happy to help.


#10

I’m stunned…

In all these years we’ve been told you can’t delete part of your history… And it is this simple…:argh:

Anyway, how come A/W haven’t prepared this? Just imagine right mouse clicking over the input node and then choose “disconnect” or “remove from history” or something. I’m not a MEL-guy, but wouldn’t it be possible to make some kind of general script to accomplish this? Just click on the input node and execute the script with a push of a button…


#11

This stuff isn’t terribly well-documented. It’s a shame there isn’t a “DAG” section in the docs to cover this sort of thing - it’s just time and practice that lets you learn this stuff, and just saying “F**k it” and diving into the hypergraph.

Graf Orlok: It’s true that you can’t just delete part of the history. While this method is fairly simple, and after a while playing with the hypergraph becomes quite intuitive, it’s not specific enough to be able to create a MEL-script to do this. Because of the large number of different connections going on for various different operations, scripting this sort of operation would only really work on a case-by-case basis (try checking out the graph for a fully rigged character!). Just get used to having the HG open while you work.

There are some esoteric - but very useful - nodes that don’t have a MEL interface, such as the infamous closestPointOnSurface node, that you have to link up thru the graph.


#12

…it’s not specific enough to be able to create a MEL-script to do this. Because of the large number of different connections going on for various different operations, scripting this sort of operation would only really work on a case-by-case basis…

I guessed so…:annoyed:

Well, just by knowing this things will be much easier. I’m quite familiar with the HG so this is just another step further into it. Just wonder why I haven’t thought about it before…


#13

awesome post luminus! thats great detail. i was having a similar problem with a character i have just finished rigging. i am texturing now, and every once in a while i have to alter the UV layout, i was wondering if you could have a look at this pis of my hypergraph, and see what i can do to get rid if those pesky “tweakUV” nodes …here it is:

http://www.planetquake.com/quakebreak/hyper_graph.jpg

thanks for your help!

sedric


#14

Sedric, your node setup is a bit more complex than the example I posted before, because now there are nodes “before” the stuff that needs to be taken away, so instead of just cutting, as I showed on the example above, there would also have to be some kind of manual reconnecting of nodes, or you would loose a lot of history. So let’s see what can be done here.

First of all, make a backup copy, in case something goes wrong - messing around with nodes directly is not always a failproof process.

I would start by deleting all the connections that go into our out of those three nodes. But BEFORE starting to delete, write down what the connections are, what output of what node is connected to what input of what node, and so, this will be needed later when reconnecting them. So after that, delete those connections, but do it in a certain order - delete first the one from “polyTweakUV3” to the shape node, then the one from “polyTweak UV2” to “polyTweakUV3”, then the one from “polyTweak1” to “polyTweakUV2”, and so on… going “backwards” in history. Do that until all the polyTweakUV nodes are completely disconnected and just floating around.

Then, reconnect the nodes you want to keep. This is why it was important to write down the connections. Here, you just have to find out on a case by case basis, what is connected to what, based on what the connections were before. Usually it will be a simple “.output” --> “.inMesh”, or something similar.

Now, you can delete the tweakUV nodes.

If all went ok, this should now have gotten rid of the tweakUV nodes, while keeping their effect - AND also keeping the other input nodes.

Let me know if it works :slight_smile:

[EDIT: Fixed the links to the images above.]


#15

That’s great info Luminis!

Where did you learn about this?

Also, is it possible to change the order of the way things are happening in History. For example, reverse the order of a skin cluster (obejct bound to joints) and a UV map - right now the binding takes place first and then the UV map which is causing problems with my blend shapes - Is it possible to have the UV map applied first then the binding using the method discribed above?

Thanks for any help


#16

Originally posted by Witczak

Also, is it possible to change the order of the way things are happening in History. For example, reverse the order of a skin cluster (obejct bound to joints) and a UV map - right now the binding takes place first and then the UV map which is causing problems with my blend shapes - Is it possible to have the UV map applied first then the binding using the method discribed above?

Witczak, there is already a way to do this within the Maya UI, although it is not very intuitive. Pull up your input list and Middle-Mouse-Button drag the input the the desired location in the list.

-=STZ=-


#17

Originally posted by Witczak
[B]That’s great info Luminis!

Where did you learn about this?[/B]

Just messing around with things and trying new stuff out when I get bored is the best way of learning.:thumbsup:

Originally posted by Witczak
[B]Also, is it possible to change the order of the way things are happening in History. For example, reverse the order of a skin cluster (obejct bound to joints) and a UV map - right now the binding takes place first and then the UV map which is causing problems with my blend shapes - Is it possible to have the UV map applied first then the binding using the method discribed above?

Thanks for any help [/B]

In theory, yes, it should be possible, but like I said on one of the previous posts, it is not a failproof method - especially in cases like this - where you have so distinct nodes such as UV mapping and binding that need to be manipulated.

If you want to try it out, then the way it would have to be done is basically the same way I showed for sedric’s layout (disconnect the parts to be manipulated so they are just floating around), but instead of reconnecting it in the same direction, just reconnect backwards the part that should go backwards on history. But as always, keep a backup copy in case something goes wrong, which is something that could always happen. I’m not too sure if the data types that these nodes output will work the same way when they are connected in the opposite direction (i.e. if there are reciprocal inputs/outputs for them). If you want some help, just post your node layout to figure out how to go at it.

Let me know if it works out… if it does work, even for reversing history, then maybe I’ll have to patent this method :deal: :slight_smile:

Now that I think of it, it’s nice how this thread is going - from a normal “remove last part of the history” it has evolved to a “remove inner parts of the history” and now “reverse history” - I wonder what’s next :).


#18

You can pretty much do anything you want with the history. There are well-defined limits (once you’ve got to know them) in place because of Maya’s architecture. There’s some things that simply won’t work, but once you get used to the way the DAG works the reasons become fairly obvious.

That said, even when you start to understand what’s going on thinking like Maya does can cause some serious headaches. Be sure to have an aspirin handy!:slight_smile:

As luminis already said, the best way to learn is just to dive in and start moving connections about!:wip:


#19

Luminis, thats incredible, i had also been messing around with the hypergraph trying to do something similar, but i was never able to do it properly, sometimes my mesh would dissapear, sometimes it would just get unbound, and the closest i ever got, i skipped a bunch of “steps” in the history, but not completely. i wanted to know if youd be willing to help me out with my model if i also posted my hypergraph view. thanks.


#20

Hey All

Lots of good info here
Im going to take a little different direction
Hope i can make this clear …I’m going to write a tutorial on this soon

look at the attached image if you select the xxxxxxOrig node and look at it in the AE under object display you will see that the intermediate object flag is on, this node holds the geo info before a skin or other deformation is applied

heres the cool part:
if you hide your attached geo and toggle off the intermediate flag on the xxxxxOrig node you can then work on this geo and move verts, split, extrude etc and this will be done before the deformation

you can then delete history on this node if you like and it will not affect your bind or skin weights

one thing: if you ended up adding verts they don’t get a weight applied in the skin node… to fix this pick the new verts and go into the component editor in smooth skin add weight to some joint this will burp the skin node and add the weighting
now you can go in and edit the weighting