[Closed] Instance TrackView controller to controller

   cons=#()
   fTv=trackViews.getTrackView "From"
   numSelInFrom=fTv.numSelTracks()
   for i = 1 to numSelInFrom do
   (
   append cons (fTv.getSelected i)
   )
   
   fTv2=trackViews.getTrackView "To" --do the same for the To TV
   numSelInTo=fTv2.numSelTracks()
   if numSelInTo <= numSelInFrom do --if less or the same number of controllers were selected
   (
    theIndex = #() --init. an array
    for i = 1 to numSelInTo do --loop through selection
    (
        theObj = fTv2.getSelected i --get the object of the indexed track
        append theIndex (fTv2.getIndex theObj) --get the index of the object and collect
    )
  
    for i = 1 to theIndex.count do --go through the collected indices
    (
        fTv2.selectTrackByIndex theIndex[i] true --select the current track only
      fTv2.assignController cons[i] --assign the i-th controller from source to target TV
    )
   ) 
   
    for i in theIndex do fTv2.selectTrackByIndex i false --restore the selection in To TV

I created a box and a teapot.
Opened a TV, named it From, selected all 3 rotation tracks of the box
Opened another TV, named it To, selected all 3 rotation tracks of the teapot
Executed the script – X, Y and Z rotation controllers were instanced, so rotating the box resulted in identical rotation of the teapot.

Obviously, there is no precaution in case the controller is the wrong class etc.
I wouldn’t really do that myself, so I see it as a hack…

Thanks Bobo, looks much like what I was doing but I wasn’t getting what I expected. I was in Max 7 so I don’t know if that was part of the issue. I will pick apart your code to see where it is different from mine and let you know if it works.

Why do you see this as a hack? I just want a better and faster way to do a copy paste of controllers then having to do it one at a time and without having to write all the code each time.

I’ll play and see what I can come up with for a decent work flow that also checks for classes.

Good to know that we are thinking down the same lines but I just haven’t had a chance to write such a tool. I have been wanting to write a sort of Maya like connection editor for instancing tracks and wiring them as well since I have never really liked the wire params dialog. I was going to use a treeView setup with two columns like you said. I figure this would be a fast and simple solution and I don’t have any intentions of giving it out as a production tool but instead just a tool for my self to speed up setups.

If I only had all the time in the world. Thanks again Bobo.

I finaly got back to this Bobo. This is still failing on this line

theObj = fTv2.getSelected i

the problem is I have a custom attribute in the To trackview. So getSelected isn’t returning an object but instead it returns undefined.

Do you see any work around for this?

sounds like an interesting idea paul.

here’s an idea in connection with that… in advanced maya rigs you usually use that type of connection in conjunction with utility nodes (it doesn’t contain any formulas like max wiring, so you use the compiled nodes to do that)

like you said instancing a controller in max basically has the same effect as making a connection using the connection editor in maya. now to have that same type of workflow in max all that’s really missing is utility nodes which i guess could be implemented quite easily.

i read on some thread that you pushed for the exposeTM helper in max7… couldn’t you push those same buttons to get us some utility nodes?

some basic compiled nodes like plusMinusAverage, multiplyDivide is all you need and i can imagine it being much faster than having scripts and expressions evaluate on every frame. at least in maya it is very fast as complex rigs use hundreds of these nodes.

also this type of stuff is much easier to script and maintain after the rig is created. changing some connections using a script is easier than going into and parsing a script or expression formula

of course these could be coded in c++ easily, but it would be awesome to have it as a part of the base package to make it a standard

I have spec’d such things with no luck. Also, you can’t instance a controller from the ExTm helper to another float value. This is because the controllers on the ExTm parameters are of a special class that only out put values and will not take inputs. I don’t think that they are createable with Max script so I would have to create the nodes with C++, as you pointed out they would be faster that way as well.

Max Script controllers have a big advantage since Max 8 over Maya’s expressions. In Max you can now store references to the nodes and tracks that you are using in the expression. Part of the reason that script controllers were slow before was they had to search the scene by name for the nodes. Mayas expressions still have to do this and they just have a hacky way to deal with name changes. For this reason it is taboo to use expressions in Maya for major production. Script controllers in Max are quite fast now so the need for the node system isn’t as nessesary. I would still like to have it as the one thing that I really like in Maya is the way the util nodes work with connections. I think that it can be done in Max as a plugin but I’m not sure about the connections, wires might have to be used but that is more then what is needed.

I see, too bad then. Too bad about the exposeTM, i haven’t tried instancing those controllers before.

Still it would be interesting to see this in max, i agree it’s a great feature of maya with many advantages. Another reason i suggested this is because i’m writing a simple version of maya’s dependency graph using kees’s helium plugin… well utility nodes would be the perfect addition for that tool.

I’d really like to test this in max so i’m thinking about talking to a coder over here and have him check it out, the obvious way to approach this would basically be another exposeTM -like helper, but one thing that’s bothering me about this is that you probably can’t create a node that is as lightweight as maya’s utility nodes this way. do you know if there can be scene nodes in max that don’t have all the baggage like transform properties (as you may know even particle flow nodes are complete scene objects, a delete operator for example also has the complete set of subanims any other object has)

this may not be much of an issue but you might need dozens or hundreds of these nodes when actually building a rig on them, so this kind of extra baggage would become something to worry about i think.

Hmm, I wonder if it could be done as a material? No bagage for the transforms. I’m not sure that the transforms of the ExTm is slowing anything down though. If it is on the end of a chain and nothing is parented to it and it isn’t animated I don’t think that it is calculated.

I think that this all has to be delt with in C++ for it to really be useful. I would love to see the graph that you are creating if you can share it. This is something that I have considered doing but I just don’t have time for.

a material, yeah that’s a good idea, and in line with how it works in maya as well!

i don’t think the exposeTM is slowing things down, but i think you need many more utility nodes for a tricked out rig than you need exposeTM’s. i have seen rigs in maya that use about a hundred for an ik/fk switch, so i just think it would be good if it’s as polished as you can make it.

My “Scene Graph” is part of the scripts pack i have on my site, it’s just a test for now and probably explodes when opened in most scenes, that said i have already used it for some rigging tests (you can’t open it on a complete rig yet, as there’s a bug in the plugin that makes it explode with too many nodes)