|
|
|
Tell us what you think of the site.
|
Autodesk Media & Entertainment User Community
|
Autodesk® 3ds Max®
|
|
Autodesk® Maya®
|
|
Autodesk® Softimage®
|
|
Autodesk® MotionBuilder®
|
|
Autodesk® Mudbox™
|
|
Autodesk® ImageModeler™
|
|
Autodesk® Sketchbook® Pro
|
|
Autodesk® Smoke on Mac®
|
| attributeAffects & setDependentsDirty behavior in 2012
|
|
|
Hopefully someone has gotten into this already --
I’m working on a custom deformer, the same code has worked from maya 2008-2011. The way the node is evaluated seems to change in 2012.
Here’s the basic setup:
polyMesh --> deformer --> polyMesh2 , deformer.outputGeometry[0] --> polyMesh2.inMesh
The problem is that polyMesh2.inMesh is not being marked dirty and is not updated when outputGeometry[0] is updated. Previously, it was enough to use attributeAffects on outputGeometry[0] in the plugin, and the downstream graph would update. That seems to no longer be true in 2012.
So I tried to roll my own setDependentsDirty to define the affects relationships, that didn’t work either (it works in the sense that I have the same problem, in the same way).
It’s against the rules to get the downstream (destination plug for outputGeometry) and set it dirty in a plug-in right? Or is that the right way to get around this?
Thanks!
|
|
|
|
|
I think you should do this, (polymesh.worldMesh[0] or polymesh.outmesh )-> destinationMesh.inMesh.
Author: Shylon
|
| Replied: 21 July 2011 06:24 PM
|
|
|
|
|
Thanks for the reply—Unfortunately, as I mentioned, the deformer in question has been in use in versions 2008-2011; I’m more concerned with finding out why it suddenly stops working (or finding an in-place work around). Maybe dirty propagation has been ‘optimized’ in 2012 causing this to break- *shrug*
|
|
|
|
|
|
|
Unfortunately I have not Maya 2012, see in what is new section of help maybe it will help you.
Author: Shylon
|
| Replied: 23 July 2011 12:21 AM
|
|
|
|
|
And also look for MPxNode::setDependentsDirty() section of 2012 help, this may help you. I think you should do your own code for test.
|
|
|
bemused0 21 July 2011 01:23 PM
Hopefully someone has gotten into this already --
So I tried to roll my own setDependentsDirty to define the affects relationships, that didn’t work either (it works in the sense that I have the same problem, in the same way).
^ As I mentioned before, I did try to get my own setDependentsDirty() to fill in the gaps where attributeAffects didn’t seem to be working. My initial implementation just dirtied the output plug.
That was the problem—I was only dirtying the parent plug, not iterating the children, so now:
<--snippet from setDependentsDirty - just like the affectsNode.cpp example-->
MPlug outArrayPlug( thisNode, outputGeom );
affectedPlugs.append( outArrayPlug );
unsigned int i,n = outArrayPlug.numElements();
for( i = 0; i < n; i++ ){
MPlug elemPlug = outArrayPlug.elementByPhysicalIndex(i);
affectedPlugs.append(elemPlug);
}
So now the question is: Did Autodesk optimise attributeAffects, was it previously dirtying the child plugs for free and is no longer?
Either way, this works for me :)
|
|
|
|
|
|
