PDA

View Full Version : Creating arbitrary moveable controls?


StephG
11-29-2006, 12:54 AM
I'd like to create a control window with controls that can move inside a box, instead of standard slider controls. That is, a single control that can be moved in both x and y directions.

I could swear I've seen this done, rather than using geometry in windows, but then maybe I'm wrong. Damned if I can find any reference to this being done anywhere.

If it can be done, can someone please point me in the right direction?

Thanks.

Winner
11-29-2006, 03:50 AM
pretty sure theres no way to do that with maya's native UI controls. not sure how you`d do something like that without a custom plugin. Theres no control type i know that supports any kind of `realtime manipulation` other than the standard window resizing, sliders, scrollLayout sliders etc. nothing x and y as far as i know.

grantimus
11-29-2006, 06:58 AM
I'm with winner on this one. This kind of thing would be extremely difficult to do, and probably wouldn't be worth the effort involved.

Building UIs in Maya is a lot like HTML, in that there is no command that lets you place a UI control at a specific set of x,y coordinates. So what you'd have to do is resize and/or reorder all the UI controls around the one you want to be moving based off of the position of the mouse. I'm not saying it would be impossible, but it would be VERY VERY difficult.

divanovic
11-29-2006, 07:54 AM
hi, I think I know what U mean, cause I've seen those things on facial rig controls several times. Looked like 3x3 matrix of boxes, and a point controller in each of them, moving inside the boundaries... something like on the attached pic.
shot was taken from wajdan farhan scripting reel, presented here not so long ago. But, it's far from using native Maya controls :)

So, I guess U'd need to ask this on some specialized rigger forums, or such, dunno.
hope it helps.

:edit: I wish I had one of these too, looks like animator's dreams come true :)
Cheers

StephG
11-29-2006, 03:55 PM
That last one looks like it's using geometry in the scene (based on the manipulator).

It's too bad "drag callback" doesn't appear to give realtime feedback :(

I suppose I can build a dynamic interface with geometry same as a window, in some far off section of a scene, and have the controls delete themselves when the window is closed through a scriptJob.

Thanks for the input everyone. Maybe if something can be done with the API, it'll have to wait for the next project I work on.

SlayTheBeast
11-29-2006, 04:41 PM
always create a flash UI and embed it into maya's web browser....would actually be very flexible and easy to create/edit.

:D

tony

sparaig
11-30-2006, 07:01 AM
I'd like to create a control window with controls that can move inside a box, instead of standard slider controls. That is, a single control that can be moved in both x and y directions.

I could swear I've seen this done, rather than using geometry in windows, but then maybe I'm wrong. Damned if I can find any reference to this being done anywhere.

If it can be done, can someone please point me in the right direction?

Thanks.

Wouldn't it be possible to create a custom geometry control that only shows in a tearoff panel?

StephG
11-30-2006, 04:29 PM
Yeah. But geometry has it's own sets of problems, which is what I wanted to avoid if I could. It's still the primary contingency plan. And I nearly have a workable geometry system.

There are going to be a lot of characters in the scenes, each with a different morphology: some with flat human faces, others with snouts and muzzles.

Each character is referenced in, and has it's own channels for facial animation.

Each character is positioned in the scene by their top node. Each character only has one top node, so each character can't have it's own geometry for a facial control. It's a pain to have to construct a camera to find each character's top transforms and wherever that control happens to be transformed to (well out of the scene).

The geometry solution is to have several interfaces to deal with the variable morphology. But making them interactive without any direct connection to the channels that control the facial transforms (because the channels have to hold the keys), is pretty much impossible. You have to have some connection for something like updating a control with setAttr interactively is possible.

However, with control windows and sliders like floatSlider or better yet attrFieldSliderGrp, that isn't a problem. floatSliders you can use a drag command that updates the channels with something like setAttr.

I'm pretty confident that since there's a way to make both horizontal and vertical sliders, that there's a way to make one that does both. If it has to be done in the API, it would be nice to know what the underlying code is for a slider or where to locate it.

grantimus
11-30-2006, 04:40 PM
always create a flash UI and embed it into maya's web browser....would actually be very flexible and easy to create/edit.

:D

tony

Not if you're using Maya 8. Yeah you could still use your systems default browser, but then you have to deal with a separate window, won't have as much screen space, etc. Might not be the most ideal solution depending on the version of Maya being used.

sparaig
11-30-2006, 04:47 PM
Yeah. But geometry has it's own sets of problems, which is what I wanted to avoid if I could. It's still the primary contingency plan. And I nearly have a workable geometry system.

There are going to be a lot of characters in the scenes, each with a different morphology: some with flat human faces, others with snouts and muzzles.

Each character is referenced in, and has it's own channels for facial animation.

Each character is positioned in the scene by their top node. Each character only has one top node, so each character can't have it's own geometry for a facial control. It's a pain to have to construct a camera to find each character's top transforms and wherever that control happens to be transformed to (well out of the scene).

The geometry solution is to have several interfaces to deal with the variable morphology. But making them interactive without any direct connection to the channels that control the facial transforms (because the channels have to hold the keys), is pretty much impossible. You have to have some connection for something like updating a control with setAttr interactively is possible.

However, with control windows and sliders like floatSlider or better yet attrFieldSliderGrp, that isn't a problem. floatSliders you can use a drag command that updates the channels with something like setAttr.

I'm pretty confident that since there's a way to make both horizontal and vertical sliders, that there's a way to make one that does both. If it has to be done in the API, it would be nice to know what the underlying code is for a slider or where to locate it.


You misunderstood what I meant. You create a new modelPanel with an associated camera with a nurbs plane with 10 subdivisions u and v. Then you create another, smaller nurbs plane that fits inside the first. You make it so only the two nurbs planes are visible in your custom model panel and geometry-constrain the smaller to the larger. Then create a script job to monitor the tx and ty of the smaller plane. Use the scriptjob's callback to control your characters' attributes based on the tx/ty of the smaller plane. If you want to get fancy, you make the constraining plane invisible and have a visible plane provide the boundries and reference grid.

It's not that hard to do. I'm nearly there. Need to record the creation steps into a script file and I'll post later after I tidy it up.

(Anyone need a freelance beginning MEL scriptor with 20 (33 counting high school FORTRAN) years programming experience?)

SlayTheBeast
11-30-2006, 04:59 PM
they removed maya's web browser in version 8? Why would they do that?

grantimus
11-30-2006, 05:57 PM
they removed maya's web browser in version 8? Why would they do that?

Hell if I know. All I know is I'm still rewritting tools becasue of this. It's ok though, I like rewritting stuff that shouldn't have to be rewritten. Why do the work once, when you can do it twice? THANK YOU AUTODESK!

Maybe in Maya 9 they can take out the hypershade........

cpan
11-30-2006, 06:18 PM
Hell if I know. All I know is I'm still rewritting tools becasue of this. It's ok though, I like rewritting stuff that shouldn't have to be rewritten. Why do the work once, when you can do it twice? THANK YOU AUTODESK!

make as much sound as you can... maybe these fools will get the pre maya8 integrated webBrowser panel back... :|

http://discussion.autodesk.com/adskcsp/thread.jspa?messageID=5373971

sparaig
11-30-2006, 10:15 PM
Here's a sample solution. It creates a model editor and some sample float fields (not hooked up yet). I can't figure out (yet?) how to automatically select the slider plane whenever the window gets the focus, so I left the slider pane selectable manually. It probably should go in its own layer, even so. Everything is 5000 units away form the origin, so there isn't too much chance of accidentally selecting it. The final step would be a script job to track the xy translation of the slider plane...

Hope this helps.

L.



// mini script by Lawson English 2006. Public domain, yada yada...
// Create a window with a model editor that implements a 2D slider control

string $window;
if(`window -exists myTest2DSliderWindow`)
deleteUI -window myTest2DSliderWindow;
$window = `window -title "myTestFrameWindow" -w 200 -h 275 myTest2DSliderWindow` ;
string $form = `formLayout`;
string $editor = `modelEditor`;

// sample fields to put current location of slider in

string $floatField1 = ` floatFieldGrp -numberOfFields 1
-label "X"
-value1 0.0`;
string $floatField2 = ` floatFieldGrp -numberOfFields 1
-label "Y"
-value1 0.0 `;



// Set up the window layout attachments.
//
formLayout -edit
//-attachForm $column "top" 0
//-attachForm $column "left" 0
//-attachNone $column "bottom"
//-attachNone $column "right"
-attachForm $editor "top" 0
-attachForm $editor "left" 0
-attachForm $editor "bottom" 50
-attachForm $editor "right" 0

-attachControl $floatField1 "top" 1 $editor
-attachForm $floatField1 "left" 0
-attachNone $floatField1 "bottom"
-attachNone $floatField1 "right"

-attachControl $floatField2 "top" 1 $editor
-attachControl $floatField2 "left" 1 $floatField1
-attachNone $floatField2 "bottom"
-attachNone $floatField2 "right"

$form;

// Create a camera for the editor.
//
string $camera[] = `camera -centerOfInterest 15
-position 0 0 5015
-rotation 0 0 0
-worldUp 0 0 0`;

// Attach the camera to the model editor.
//
modelEditor -edit -camera $camera[0] $editor;

// Put an slider and grid in the scene.
//
string $controlPane[] = `nurbsPlane -p 0 0 5000 -ax 0 0 1 -w 10 -lr 1 -d 3 -u 9 -v 9 -ch 1` ;
modelEditor -edit -vs true $editor; // add to view

string $sliderPane[] = `nurbsPlane -p 0 0 5000 -ax 0 0 1 -w .5 -lr 1 -d 3 -u 1 -v 1 -ch 1 ` ;
modelEditor -edit -as $editor; // add to view

// without xform call, the durned thing doesn't show the manipulator in the editor

xform -ws -rp 0 0 5000 $sliderPane[0] ;


// make it active (who knows if needed?)

modelEditor -edit -av $editor;
modelEditor -edit -lockMainConnection $editor; // all we ever show in this editor


select -r $controlPane[0] ;
select -tgl $sliderPane[0] ;

geometryConstraint -weight 1;


$layer = "sliderLayer";
createDisplayLayer -noRecurse -empty -name $layer;
editDisplayLayerMembers $layer $controlPane[0];



setAttr ($layer + ".displayType") 2; //reference layer


select -r $sliderPane[0] ;
setToolTo $gMove;

showWindow $window;

StephG
12-01-2006, 01:12 AM
Pretty similar to my current "working" approach. I've got a split panel with an option menu for the character names (it'll have to be a scroll list, because there are over 100 characters). It loads the models for the controls based on which character is selected from a file, and deletes the control panel when the window is closed (based scriptJob -uid), as well as deleting the expressions that are created when the window is opened or the character is changed. And I set mine at -10000 in x.

The main issue remaining is getting the data from the controls to the channels which are being controlled in realtime, without connecting directly to those controls (which channels and which controls are determined by the highlighted character in the optionMenu or TSL). Right now, the expressions have to tie in to the main transforms (like scaleX, in which it would be something like:
channelContainer.scalex = (channelDriver.tx/channelDriver.tx);

Basically the scaleX value remains 1, but there is a direct connection to that which makes the intended control being driven respond in real time to movement of the control called channelDriver.

The problem with this approach, is that there are only so many "live" transform channels like "scaleX" and there could be dozens of added attribute channels driven within the tranform node "channelContainer". Maya's inherent optimization of expressions containing commands like "setAttr `getAttr channelContainer.jawSide2Side channelDriver.tx` ;" means it'll do nothing when you move the control, without that direct connection using the "=" sign (which immediately locks the channel out and doesn't allow it to be keyframed without a "blend" node).

All an unnecessary headache, which using sliders as I mentioned a few posts above, don't seem to have. I'm sure I'll figure it out, but I've got the feeling that scriptJobs will be involved.

sparaig
12-01-2006, 01:32 AM
Pretty similar to my current "working" approach. I've got a split panel with an option menu for the character names (it'll have to be a scroll list, because there are over 100 characters). It loads the models for the controls based on which character is selected from a file, and deletes the control panel when the window is closed (based scriptJob -uid), as well as deleting the expressions that are created when the window is opened or the character is changed. And I set mine at -10000 in x.

[...]

All an unnecessary headache, which using sliders as I mentioned a few posts above, don't seem to have. I'm sure I'll figure it out, but I've got the feeling that scriptJobs will be involved.


I've found sliders to have their own problems. Like finding the durned thing if it is nested. I gave up trying to parse the slider's path and just passed the full slider name in the callback.

Seems to me that a scriptjob that triggers on the movement of your *control* wouldn't take that much time...

...come to think of it, scriptJob -runOnce false -attributeChange mySliderPane.ty callBack could be hooked to an invisible/out-of-sight slider, could it not? The SLIDER could be llinked to your 100+ attributes... or would that still cause the problem?

sparaig
12-01-2006, 02:02 AM
I've found sliders to have their own problems. Like finding the durned thing if it is nested. I gave up trying to parse the slider's path and just passed the full slider name in the callback.

Seems to me that a scriptjob that triggers on the movement of your *control* wouldn't take that much time...

...come to think of it, scriptJob -runOnce false -attributeChange mySliderPane.ty callBack could be hooked to an invisible/out-of-sight slider, could it not? The SLIDER could be llinked to your 100+ attributes... or would that still cause the problem?

connectControl on all the different attributes would SEEM to be the solution. Use the scriptJob to modify the slider value and all the attributes update asap without blocking, as far as I can tell from the documentation. The only tricky part would be to coordinate the 2D slider with the value of the regular slider if that inavertently changed, but it seems like you could use connectControl on the tx/ty values of the 2D slider if you did it right...

sparaig
12-01-2006, 02:53 PM
connectControl on all the different attributes would SEEM to be the solution. Use the scriptJob to modify the slider value and all the attributes update asap without blocking, as far as I can tell from the documentation. The only tricky part would be to coordinate the 2D slider with the value of the regular slider if that inavertently changed, but it seems like you could use connectControl on the tx/ty values of the 2D slider if you did it right...

Doh. Why not just use setDrivenKey based on the movement of the 2D controlSlider?


The only reason to use a script job would be to provide YOU with feedback. You should be able to link the xy translation of the slider to any ole attribute you want, and I suspect that that is what connectControl actually does in some sense: it connects the slider translation to the specified attribute perhaps with a scaling factor thrown in, but it might be possible to do the same thing with very little work. The only issue I can see is that there is some sloppiness in how geometryConstraint handles translations (which is how I kept the slider in the boundries), but that may not matter or you may be using some other solution anyway, and if it does matter, you can compensate at some point, I would think.

sparaig
12-01-2006, 02:59 PM
Doh. Why not just use setDrivenKey based on the movement of the 2D controlSlider?


The only reason to use a script job would be to provide YOU with feedback.

Doh again. Use connectControl to hook the 2D slider pane translation to your feedback fields...


No scriptjobs or anything else needed.

sparaig
12-01-2006, 03:16 PM
Doh again. Use connectControl to hook the 2D slider pane translation to your feedback fields...


No scriptjobs or anything else needed.


yep.



connectControl -i 2 $floatField1 ($sliderPane[0]+".tx");
connectControl -i 2 $floatField2 ($sliderPane[0]+".ty");


just before showWindow in my previous script provides full feedback. You could create your own custom control global variable array that lists all such controls and have your own myConnectControl procedure to do the setDrivenKey.

This is SOOOOO straightfoward that I am almost certain that that is how all standard controls are implemented in Maya anyway. They just have a special viewport setup with special objects and cameras that can't be accessed in user-mode scripting and the whole layout/panel/window thing just gives a limited but straightfoward interface without exposing all the dirty details to the scripter.


3D controls, UV controls over contours,... the sky is the limit. No need to use Flash for creative custom controls in the browser. Maya is way more powerful.

StephG
12-01-2006, 04:22 PM
connectControl on all the different attributes would SEEM to be the solution. Use the scriptJob to modify the slider value and all the attributes update asap without blocking, as far as I can tell from the documentation. The only tricky part would be to coordinate the 2D slider with the value of the regular slider if that inavertently changed, but it seems like you could use connectControl on the tx/ty values of the 2D slider if you did it right...

A very interesting suggestion. It would be handy if I could drive an attrFieldGrp control that drives the attributes non-destructively, but if not, this is definitely a very good leg up on the problem and gets around the "direct connection in an expression problem".

Thank you very much. BTW, I like your whole "train of thought" series of posts ;)

I'll hopefully get to testing this out later today. I see a whole new range of possibilities now. Thanks again.

sparaig
12-01-2006, 08:40 PM
A very interesting suggestion. It would be handy if I could drive an attrFieldGrp control that drives the attributes non-destructively, but if not, this is definitely a very good leg up on the problem and gets around the "direct connection in an expression problem".

Thank you very much. BTW, I like your whole "train of thought" series of posts ;)

I'll hopefully get to testing this out later today. I see a whole new range of possibilities now. Thanks again.

If you do a connectControl on your attibute field (I did it in my example on on the float fields and it works just fine), you basically have a realtime control with 2-way linking between the field and slider-translation: enter specific values into the fields and control the slider position automatically. Any futher connectControl calls on the field will only be 1-wayaccording to the documentation, but this should NOT be a problem in most cases. Afterall, you only get 2-way connections with the first attribute specified anyway.


I'm wondering if this is what they do in-house at Alias (AutoDesk): prototype their controls using a similar setup and then implementing them in C for extra speed. With a modern workstation, I doubt if you see much gain from implementing a new control type in C, but perhaps there's issues with large numbers of controls that we don't notice with simple tests.

I can see the potential for creating a very complex character rig using this kind of thing that doesn't require you to worry about interfering with your scene. A walk cycle rig that constrains the joints to follow certain curves could be devised that would be more intuitive than your normal foward/IK strategy. You could make it as complicated as y ou want without cluttering up the scene. No doubt myriad other things are doable with this strategy.

sparaig
12-03-2006, 06:09 AM
I implemented a generic version of this and put the code in a separate thread. It implements a 2D slider that follows any arbitrary nurbs surface that is selected when the script is executed, or a simple nurbs plane if no surface is selected. You use connectAttr to hook the tx, ty and tz of the slider to whatever attributes you want controlled. For some reason connectControl didn't seem to work on a second set of attributes.

StephG
12-04-2006, 06:15 PM
I'm trying to test the various suggestions for my purposes. The main problem is that there can be no direct connection between the attributes being controlled and the geometry sliders. No connectAttr, no expressions with faceControlChannel.mouthUpDown = faceControlSlider.ty, no nodes. If I could allow any sort of direct connection it wouldn't be a challenge ;)

Even worse, I'm still confined to working in 6.5 (don't think I mentioned this) but we might update up to 7.

Sparaig, I didn't want you to think I was ignoring your suggestions. I just couldn't get to them over the weekend. I'm trying to squeeze my tests inbetween some re-rigs I gotta deal with today. Hopefully late today or sometime tomorrow I can report success ;)

Thanks again to everyone who is contributing to this thread.

StephG
12-05-2006, 07:27 PM
Well, that didn't work.

Here's what didn't work:

I create a geometry based control, with the ability to translate in x and y. I do a connectControl to the attributes from that to a floatFieldGrp (and later a floatFieldSliderGrp). It's set to trigger the following proc with a change command:

if (`objExists AnimCTL_A`)delete AnimCTL_A;
if (`objExists AnimCTLContainer`)delete AnimCTLContainer;
if (`objExists pCube1`)delete pCube1;
spaceLocator -n AnimCTL_A;
createNode transform -n AnimCTLContainer;
parent AnimCTL_A AnimCTLContainer;
move -a -4 0 0 AnimCTLContainer;
polyCube -w 2 -h 2 -d 2 -sx 1 -sy 1 -sz 1 -ax 0 1 0 -tx 1 -ch 0;
global proc testUI()
{
if (`window -ex testUI`)deleteUI testUI;
if (`windowPref -ex testUI`)windowPref -r testUI;
window -wh 400 400 testUI;
columnLayout;

floatSliderGrp -f 1 -l "animCTLAtx" -min -1 -max 1 -dc "setAttrs" -cc "setAttrs" txAFG;
floatSliderGrp -f 1 -l "animCTLAty" -min -1 -max 1 -dc "setAttrs" -cc "setAttrs" tyAFG;
connectControl txAFG AnimCTL_A.tx;

showWindow testUI;
}
global proc setAttrs()
{
setAttr pCube1.tx `getAttr AnimCTL_A.tx`;
setAttr pCube1.ty `getAttr AnimCTL_A.ty`;
}
testUI;
//$job1 = `scriptJob -kws -ac AnimCTL_A.tx setAttrs`;/*This is the attribute change scriptJob*/


I also tried with a drag command.

Here's what happens. You change the attribute or drag the slider in the window with the FFG or FFSG controls, and pCube1 moves as you'd expect. But move AnimCTL_A, and the attributes in the window update beatifully, but mockingly, as nothing happens. The changes have to occur in the UI window for the change command or drag command to be actuated. So much for that smart idea.

I've tried using an "attribute change" scriptJob, but that only updates after you're done moving the object. I'm not familiar with a scriptJob technique that will update the object while it's being moved.

The next thing I'm thinking of trying is some sort of blend node technique, where the blend node is deleted when the interface is changed to another character or the the model panel interface is closed.

Right now I'm still finding the only way to get it to work is by hooking up the translate attributes of AnimCTL_A to some real transform attribute of the attribute container that drives the face shapes. Since that container may contain 30+ attributes, it's hard to find enough real transform attributes (scale, translate, rotate, various axes, etc) to actuate all the attribute container attributes. It seems to be the only way Maya will respect real time movement of the controls using a setAttr based script. This is bumming me out ;)

goleafsgo
12-05-2006, 07:40 PM
This thread has gone on for a bit and I'm finding it hard to follow what you are now trying to accomplish now :)

Either of you guys care to explain what it is you are trying to do? You are trying to use geometry in a floating 3d viewport to act like a UI control?

StephG
12-05-2006, 08:33 PM
This thread has gone on for a bit and I'm finding it hard to follow what you are now trying to accomplish now :)

Either of you guys care to explain what it is you are trying to do? You are trying to use geometry in a floating 3d viewport to act like a UI control?

Yes, because Maya doesn't have any native control slider that has side to side and up down simultaneously.

But there's a catch. The control cannot have any direct connection (either through connectAttr, utility nodes or expressions) to the attributes it is driving on another object. The keyframes must only go on those attributes, not on the control itself.

With just attribute sliders in a UI (the kind made with attrSliderGrp for example), one running translateX and one running translateY, you can control a global proc with the drag command that will set an object attribute in real time as you move the slider without affecting the object's animation channels (a direct connection would complicate the connections).

The idea is to have the same exact control panel for a large number of characters, with say a pulldown menu to select which character it is affecting. So the same exact control might be used for a hundred different characters, and that geometry will never be saved with the character or scene.

Does that make any sense?

goleafsgo
12-06-2006, 01:13 PM
that has side to side and up down simultaneously.
Ok, it makes sense...so the horizontal and vertical sliding is still the main requirement. It had looked like you guys were moving more towards a more general way of creating manipulators using arbitrary geometry instead of this specifically.

StephG
12-06-2006, 04:35 PM
From my own personal viewpoint, I think doing everything with horizontal sliders is fine. But for facial controls where a set of shape targets and joint controlled topological movements have a definite up/down/left/right component, it is more intuitive to some folk to have the 4 way control.

There are people doing arbitrary geometry out there, but in the end you wind up with the same problems.

If you wanted an arbitrary appearing control, you could still accomplish that if only there were a 4 way slider available for the homegrown UIs that aren't based on geometry. You could embed it in front of an image, for example.

I'm going to put Jscript and Java interface building on my list of things to learn. Even though it seems the most recent version of Maya wouldn't be able to use that.

I guess right now I'm both complaining and looking for a better way to do things at the same time ;)

sparaig
12-06-2006, 05:25 PM
From my own personal viewpoint, I think doing everything with horizontal sliders is fine. But for facial controls where a set of shape targets and joint controlled topological movements have a definite up/down/left/right component, it is more intuitive to some folk to have the 4 way control.

There are people doing arbitrary geometry out there, but in the end you wind up with the same problems.

If you wanted an arbitrary appearing control, you could still accomplish that if only there were a 4 way slider available for the homegrown UIs that aren't based on geometry. You could embed it in front of an image, for example.

I'm going to put Jscript and Java interface building on my list of things to learn. Even though it seems the most recent version of Maya wouldn't be able to use that.

I guess right now I'm both complaining and looking for a better way to do things at the same time ;)


If you could solve the problem for the 2D slider on a plane, you would have it solved for any arbitrary 2D geometry, I would think, and probably any arbitrary 3D geometry as well.


Any idea why conectControl only works ONCE? The documentation suggests you can conect any number of attributes to a control using it, so my idea of connectControl from the fields/slider to the 2D slider followed by other calls to connectControl SHOULD work, but doesn't.

Wah.

And where is feedback from the Maya development team on this issue? This thread has more readers and contributors than any other recent thread in the MEL forum but it is completely ignored....

goleafsgo
12-06-2006, 06:03 PM
And where is feedback from the Maya development team on this issue? This thread has more readers and contributors than any other recent thread in the MEL forum but it is completely ignored....
I am a Maya developer. And yes, I will look into your connectControl issues.

If I can come up with some kind of workaround then I'll post it here. If there is a bug in there somewhere I'll log it.

sparaig
12-06-2006, 09:17 PM
I am a Maya developer. And yes, I will look into your connectControl issues.

If I can come up with some kind of workaround then I'll post it here. If there is a bug in there somewhere I'll log it.

Thanks for responding and sorry to be snippy.

CGTalk Moderation
12-06-2006, 09:17 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.