Using MObjects as pointers to other Objects

[daniel-faust]

Is it ok to use MObjects as pointers between Objects?

For instance, I have a Transform node "A" and another one "B", and want node "A" to have a fast access to node "B" transformation matrix.

Can I have a member variable in "A" similar to

MObject* otherObject; // pointer to another node

so that I can use Function sets on it from within the compute method of node "A"?

To be a little bit more precise, I'm not fully understanding the following sentence from the docs:

Important Tip

You should never keep a pointer to an MObject between "runs" of the plug-in.

Is a "run" of a MPxCommand... the same as a "run" of a Locators compute method? Or does it only apply to when I load, unload and then load the plugin again?

What is the deal with it? Is it like in "normal c coding" when you deal a lot with pointers and you should really know that the following line
calculator->Add( a, b );
should not try to operate on a deleted calculator because that would cause an exception.

Is a MObject valid during it's the entire lifetime is the scene (of course, only as long as the object exists in the scene), or does Maya internally cause seemingly random MObject invalidation because it moves the object referred to by the MObject to another (maybe a new one) MObject.

I mean, I am going to do this, to code with MObject pointers instead of plugs for reading data which needs fast access, and I'm going to keep track of my MObjects, I will "NULL the pointers" if an MObject like a transfrom is going to be deleted and I'll be checking for validity before using it.

The point is that I want to know if this is a common coding practice or if this approach is going to be problematic.

Thanks

[joojaa]

No! Infact ist not okay to use a mobject as a pointer to anything for a prolonged period of time. Because its pointer to sometthing you neither own or know what it is.

Essentialy ista ponter to something thats never ever gueranteed for you to own, in fact your guaranteed not to own it at all, so for instance if you point to a object thats has been deleted then your mobjecty would still exist but point to someting that does not exist. Like a normal c pointer exception is thrown.

Instead you should find and locate your nodes toroughh the dag, and keep track of them trough dag for future reference.

a run is one piece of excuted code, for each time its executed (a command i guaranteed to run every time its called so you shouldt store it form one call to the next, instead store the dagpath). For a node this costitutes a refresh etc etc..

And NO your not guaranteed to have acces to the pointer trough the entire scene.

[daniel-faust]

And if I don't use an
MObject *otherObject; // pointer to other node
but instead an
MObjectHandle otherObject?

What wourld be the purpose of those ObjectHandles if not the one of actina as pointers to other objects, even during different runs.

I know I don't own MObjects, but I can use Function Sets on them to operate with them. I also plan to use this only with Proxy Objects, objects which I derived from MPxTransform, so I know what they look like, it this is going to be of any use.

I don't know, I feel that there should be nothing bad with creating MPxTransforms which internally have MObjectHandles to other MPxTransforms as pointers to store a "reference" to these other MPxTransforms during it's entire lifetime.

Can one create a Function Set as a member variable of an object and use its setObject() once and use that Function Set during different runs?

So it's safe to create a couple of MDagPath variables in a node which then acts as a pointer to another node, is this dagpath always going to be valid, even if nodes get reparented?

Where do you have got this info from?

Is there any good Book on the Maya API?

Gosh, I'm sorry about this replay, I'm kind of confused now and it shurely shows.

Cheers

[joojaa]

Why do you not just connect the transform matrix to node A? thisway youll know when the matrix has changed and the node a can update on demand? Or not depending o what you need.

You can get into lot of trouble by designing nodes that defy maya logic.

for example nodes should not know anything about things that are not connected to them... It can cause massive headaches for the operators and yourself bacsue youve jsut broken maya standard flow.

MObject itself is a pointer!!! A a MObject is a void pointer so it goes without saying, you cant trust on it form one call to the next.

Use dag to track your objects instead, then re reference them on start of your run if its usefull.

Dagpath is not allways going to be valid, but you can hook up a callback to objects so that they inform you when the dagpath changes. BUt only ever do this for some internal cleanup, for node to node communication use connections, its more flexible form usage standpoint and alos its teh maya way, wich means operators will isntinctively know whats going on fi they look around.

However, if its a node of somekind, then the standard solution is to hook a message to imput of any calculating node (or the value you want to use), thisway maya will track it for you, and the user has a clear picture of whats going on if he ever looks under the hood. (i prefeer thsi approach).

The info is firsthand experience, and understanding of the concepts but its also explained pretty well in david goulds book complete maya programming page 447

[daniel-faust]

So, basically you're saying that even if the following code works, it should not be used?

////////////////////////////////////////////////////////////////////////////////////////////////
//
// CFingerTransform::connectionMade
//
////////////////////////////////////////////////////////////////////////////////////////////////

MStatus CFingerTransform::connectionMade( const MPlug & plug, const MPlug & otherPlug, bool asSrc )
{
if( otherPlug.partialName() == "fin" )
{
if( plug.partialName() == "fin" )
{
MFnDagNode otherNode( otherPlug.node() );
CKeyTransform* key = (CKeyTransform*)otherNode.userNode();
this->m_vpKeys.push_back( key );
}
}
return MS::kUnknownParameter;
}

////////////////////////////////////////////////////////////////////////////////////////////////
//
// CFingerTransform::connectionBroken
//
////////////////////////////////////////////////////////////////////////////////////////////////

MStatus CFingerTransform::connectionBroken( const MPlug & plug, const MPlug & otherPlug, bool asSrc )
{
MFnDagNode otherNode( otherPlug.node() );
CKeyTransform* key = (CKeyTransform*)otherNode.userNode();
for( int i = 0; i < m_vpKeys.size(); i++ )
{
if( key == m_vpKeys )
{
m_vpKeys.erase(m_vpKeys.begin()+i);
i--;
}
}
return MS::kUnknownParameter;
}

////////////////////////////////////////////////////////////////////////////////////////////////
//
// CFingerTransform::NotifyKeyLocators
//
////////////////////////////////////////////////////////////////////////////////////////////////

void CFingerTransform::NotifyKeyLocators()
{
int iMax = this->m_vpKeys.size();
for( int i = 0; i < iMax; i++ )
{
dlg->PrintLine("Checking node %s", this->m_vpKeys->name().asChar() );
this->m_vpKeys->CheckCollision();
}
}

BTW, are there some collision functions in the Maya API? Right now i'm linking against the coldet lib.

[joojaa]

Yes well a node should not have any extra logic about things are connected to it. So a node should never go around and asking fro data form other nodes internaly, but instead they should pipe the data from that other node trough a connection.

Thisway maya will know in wich order things should be exacuted for optimal performance, se if you ask for something in a node out of flow you may make maya do tha same thing 2 times! Or even give you the wrong aswer becasue the new data isnt evaluated as you expect (because maya evalueted your node first and failed to see the bg picture)

On the same line a node should never be that particular about what it is that it has been connected to. It is asumed that a node is allways connected as it should. Infact this behaivour allows you to use nodes in a more relaxed capacity, because you might invent many uses for the node with different connections. It is the operators job to connect properly (or some convinience command that builds this connection, but the user can still opt to use it in a differnt way).

I dont realy se why you cant just connect the relevant atributes from your target nodes to a input plug in your object?

Also your code would probably fail if some node connected to it gets renamed... didnt have much time to think about it realy, but thets my first impression.

[daniel-faust]

--> I dont realy se why you cant just connect the relevant atributes from your target nodes to a input plug in your object?

Because I don't quite understand how to do it.

Do I have to create an Attribute called "ChangeTo1ToTriggerCollisionDetectionFuntion" so that one node can request a calculation in another node.

I've got three nodes. Theese nodes communicate to existing nodes via plugs, just the way it should be. The operator can connect to them like he's used to, they call their validateAndSet function properly and do a clean work.

But the three nodes need to communicate between them.

Node Type-Head tracks if it collides with node Type-Stone. So, each time I move one of both nodes, Type-Head node must call CheckCollision to evauate and, if true, set a Plug to "True" (this here might be a problem since during Type-Stone's getMatrix(...) evaluation plugs get modified ).

This Type-Stone node can connect to up to hundreds of type-Head nodes, the one which calculates if the Type-Stone node collides with it.

So, this function get's called up to 9 times if posxyz, rotxyz, scalexyz change "at the same time".

During each of those calls, the CheckCollision function in Type-Head needs to know the transformationMatrix of Type-Stone node, so it's got to retreive it. If Type-Head has a pointer to Type-Stone, then the transformationMatrix is just as easily accessible as the local one, no data will have to flow.

Actually, passing the matrix through a Plug is not much of a bulk, but I don't know how to retreive the matrix effectively. I don't know how to make an Attribute out of the transformMatrix of a Node, so that Maya takes care of dumping the matrix over from Type-Stone to the Type-Head node, and I then can read the matrix and use it with the CheckCollision function. Maybe I'd also prefer this way, but I don't know how to do it and the issue with the pointer seems to have done it. Renaming or reparenting doesn't cause problems. Sometimes they seem not to load after recompilation until I restart Maya, and I can't do undos, but the latter has also been a problem before using those pointers.

[joojaa]

What exactly is the problem with connecting a matrix type otput form the transforms? Each transform node has a matrix attribute wich can be connected to any in matrix plug. (it is hidden by default tough, look at the node reference for a transform nodes, maya is kindenough to give you worlldmatrices along with local ones so that you dont need to compute them separately).

Sorry no maya in fornt of me right now.

But the reason why move tools dont have collision detection like its is that its a bit off a hustle to make this work realtime. I would asume alias is working on it tough as hair is a step that way.

[daniel-faust]

Ok, excellent answer. I guess the problem is getting a lot clearer for me now.

I can't figure out how to implement the following code:

MStatus CHeadTransform::validateAndSetValue( const MPlug& plug, const MDataHandle& handle, const MDGContext& context )
{
if ( plug == incomingTransformationMatrixFromStone )
{
MMatrix otherMatrix = handle.asMatrix(); // <--- Problem
if( otherMatrix != this->m_mOtherMatrix )
{
this->m_mOtherMatrix = otherMatrix;
CheckCollision();
}
}
return MPxTransform::validateAndSetValue( plug, handle, context );
}

there is no MDataHandle::asMatrix(). How am I supposed to get the incoming matrix?

_______________________________________

Ups, well... i found it.

Ok, now I got it. I was overloading CStoneTransform::getMatrix( ... ) so that I can do my CheckCollision() in there ( later on I decided that only the head should call a CheckCollision(). So, while in this CStoneTransform::getMatrix( ... ) I called a Plug called Collides in CHeadTransform to let the head know if it collides or not.

When I then was looking for a MPlug function which from the CStoneTransform::getMatrix( ... ) sent the matrix over to the Head's stonetohead plug, I could not find any MPlug::setValue( MMatrix & ) to send the matrix over.

You made me realize that there is no need for needing to use a MPlug::setValue( MMatrix & ) as well as overloading the stones getMatrix(...), since the head can connect directly to the matrix provided by Maya.

I guess this thread has served it's purpose.

Thanks a lot Janne!

[deane]

I can't figure out how to implement the following code:
...
MMatrix otherMatrix = handle.asMatrix(); // <--- Problem

The 'as()' methods only exist for the basic types plus strings and one or two others that Alias figured would be used frequently. For the others you must get the data as an MObject using MDataHandle::data(), attach the MObject to an appropriate MFnData functionset and then extract the actual data from that.

So for a matrix, your code would look something like this:

MObject matrixObj = handle.data();
MFnMatrixData matrixFn(matrixObj);
MMatrix otherMatrix = matrixFn.matrix();

Or, if you want the MTransformationMatrix, then that last line would be:

MTransformationMatrix otherMatrix = matrixFn.transformation();

[daniel-faust]

So, to set a Plug to any type I would do something like

MFnMatrixData matrixData();
matrixData.set( matrixToPassThroughPlug );

MPlug otherMatrixPlug( otherNodeThatHasTheMatrixAttribute, matrixAttribute );
otherMatrixPlug.setValue( matrixData );

And this would pass me the data to the

MStatus CHeadTransform::validateAndSetValue( const MPlug& plug, const MDataHandle& handle, const MDGContext& context )

which I could then retreive using your code? Or retrieve using the supplied handle.asMatrix() which I had overlooked in the docs and the intellisense dropdown.

I had not realized until now that those MFnData classes exist. I might have seen them, but not realized what they are there for.

Thanks for the answer, Dean.

[deane]

So, to set a Plug to any type I would do something like

MFnMatrixData matrixData();
matrixData.set( matrixToPassThroughPlug );

MPlug otherMatrixPlug( otherNodeThatHasTheMatrixAttribute, matrixAttribute );
otherMatrixPlug.setValue( matrixData );

Close. You need to create an MObject for the data and pass that to MPlug::setValue(), so...

MFnMatrixData matrixData();
MObject matrixDataObj = matrixData.create(matrixToPassThroughPlug);

MPlug otherMatrixPlug( otherNodeThatHasTheMatrixAttribute, matrixAttribute );
otherMatrixPlug.setValue( matrixDataObj );

Note that that is the code you would use outside of a compute() method. If it was a compute method which was setting the output value on one of its own plugs, then those last two lines would instead be:

dataBlock.outputHandle(thisNodeMatrixAttribute).set(matrixDataObj);

which I could then retreive using your code? Or retrieve using the supplied
handle.asMatrix() which I had overlooked in the docs and the intellisense dropdown.

Doh! Can you believe that I missed it, too? Just goes to show that I need to start getting to bed earlier.

Well, at least the technique will still be useful for other types of data, such as component lists (MFnComponentListData), lattices (MFnLatticeData), and so forth.