Plugs and nodes

[wooold]

I need to retrieve a pointer to the MPxNode that holds a plug while processing the connectionMade function of the plug's destination node. How can I do this? In connectionMade I have the plug, so I can retrieve its name, but how do I get the node from the plug's name?

bye,
nICO

[rob-bateman]

MPlug myAttr = FindMyPlugSomehow();

MObject theNode = myAttr.node();

[wooold]

Thank you Rob, it's not exactly what I needed (I needed a MpxNode)... but I solved the problem.

I did this way:

MFnDagNode dagnode;
MPxNode node;

dagnode.setObject(plug.node());
node = dagnode.userNode();

(plug is the MPlug object)

nICO

[zulu17]

I have a problem very closely related to this.
After getting the MPxNode from dagnode.userNode(), it contains a few pointers to which I need access to.

Actually i have created a Custom node class derived from MPxLocator Node which contains a few pointers that I need access to , but i am not able to do that. Any advice??

I am not sure if I am explaining my problem properly , please do let me know if you need additional info

Zulu

[daniel-faust]

in the example above, change the following

CODE
//MPxNode node;
YourNode *pNode;

dagnode.setObject(plug.node());
//node = dagnode.userNode();
pNode = (YourNode *)dagnode.userNode();

so you're casting the mpxnode to your mpxnode-derived class, that gives you full access to the public members of your class.

But be sure to check if the typeId of the node which connects matches to the typeId of your node, otherwise you will have a bug if you're casting some other node into your class.

[zulu17]

Hey Daniel,

I have already tried that, but the problem is I do not have direct access to my MpxNode derived class since its loaded in the plugin.
This step I am trying to do in a separate file altogether after it loads the mll.
So thats where my problem arises.

!Zulu!

[daniel-faust]

I don't understand what you are saying. Try to explain it again in a different way.

If you're trying to say that you have one plug-in which implements a node which is defined in a class called MyMPxNodeDerivedClass, and you want another plug-in to have access to the derived members of that class, then you need to share the same header file that defines MyMPxNodeDerivedClass across both plug-ins at compile time so that the other plugin knows what that MyMPxNodeDerivedClass looks like.

[zulu17]

Ok here's the deal....

In my plugin I have the myderivedNode which has a few public members I need access to.

Now I have another exporter which at run time loads Maya , loads the plugin etc. Now in the exporter I need access to that class and hence the public memebers of that class.

Now without actually sharing the header files of the myderivedNode is there any other way I can have access to that class from the mll.

I hope this is clear

[daniel-faust]

Ideally your exporter should have access to the header file of the custom node. This is because such a header file lets the compiler know at which address offset the member variable/function is located in memory in relation to the beginning of the node's data in memory. The header also lets the compiler know what type of variable is at a given location offset, or how the function looks like (return value, parameters) which is at a given offset. That's why you need to include all those Maya headers (MString.h, ...) so that your compiler knows the offsets of the functions which are contained in that class.

Now, If you really don't want to let the exporter have access to the header file of the node, then there is another thing you can do, this is without using the MFnDependencyNode::userNode().

For each member variable/function of the node you want to share you need to add an additional attribute. This attribute will contain the address in memory of the member variable/function. So the exporter reads the value of the attribute and casts it to a pointer of the type of your member variable/function in the node. So you need to know what type the pointer is to or how the function that pointer represents is defined.

This is done in some nodes in Maya, for functions, an example:
clipLibrary
clipEval_Raw (cevr) function NULL outputinputconnectable
For Internal Use Only
Actual function being applied at this attribute

[zulu17]

Hey thanks Daniel,

I created another derived class of my derived node and gave access to this new class to the exporter. I think for the time being this method will work fine.
BTW the additional attribute idea seems to be good as well.

Zulu

[daniel-faust]

You'Re welcome. I just don't understand why you can't give access to the definition of the derived node directly instead of deriving from it and give the exporter access to the definition of that derived class.

If you only want to give access to a limited set of members of the derived node then it would be better to derive as follows:

~~~~~~~~~~~~~~~~~~~ shared.h ~~~~~~~~~~~~~~~~~~~
class CSharedDerivedMPx : public MPxNode {
int m_iSharedInt;
virtual void sharedFunction() = 0; // Need to implement this in CUnsharedDerivedMPx but exporter can use it.
}

~~~~~~~~~~~~~~~~~~~ unshared.h ~~~~~~~~~~~~~~~~~~~
#include shared.h

class CUnsharedDerivedMPx : public CSharedDerivedMPx {
virtual void sharedFunction();

int m_iUnsharedInt;
void unsharedFunction();
}

so the exporter only knows about the shared members and can use them, while the node has the shared members and some additional members.

The advantage is that you can do changes to the node without needing to recompile the exporter, as long as you don't change the CSharedDerivedMPx class, which only acts as an interface.

[rob-bateman]

QUOTE(Daniel_Faust @ 02/14/07, 09:43 AM) [snapback]259897[/snapback]
Ideally your exporter should have access to the header file of the custom node.

Ideally your exporter should NOT have access to the header file of the custom node. If you are in any doubt as to why that is a really bad thing to do, write an exporter for 3ds max and you will soon see why....

QUOTE
Now without actually sharing the header files of the myderivedNode is there any other way I can have access to that class from the mll.

yes. Add the data as attributes to the node. MFnDependencyNode::findPlug will then give you everything you need. Any other method will come back to bite you hard one day.

[daniel-faust]

QUOTE
Ideally your exporter should NOT have access to the header file of the custom node.

I completely agree, but it might be the case that zulu17 needs to do something which can't be done without getting internal access to the class. The ideal recommendation only refers to which header he is sharing (first or second derivation).

[joojaa]

I cant really think of a single data type he couldn't publish as a attribute? So why not do so.

[daniel-faust]

Assuming your MPxNode is a wrapper for an audio file, holding a couple of MB's of audio samples. Wouldn't it make more sense to provide a pointer to that data instead of using an array of floats to expose the data?

[joojaa]

So then why not point to a file?

[daniel-faust]

Have the node write out it's data into a file and let the exporter read the data back in?

Assuming the node holds hundreds of mb of samples, then the export process would require that data to be written to disc and then a couple of function calls later read back in by the exporter just to access the data.

What if the exporter converts the nodes data into mp3 and saves that into a file, why not let the exporter have direct access to the chunk of data in the node? But more importantly how could the exporter gain access to the data chunk in the file. I believe that probably by offering the pointer through an attribute, but of what type would this attribute have to be?

[joojaa]

Well see thing is it needs to be written down at some point anyway usually at export time anyway. besides because the music is so big its better to cache it on disk at all times anyway so not to eat all mem. (almost all sound paps do this you know so the 1000 megs is resident on disk anyway)

But why not jut couple the node with a mel command that the exporter uses to push the data out or directly to the engine style file (lets face it hes not likely to compile all the game data into one file ). Then the exporter does not need to know this anyway. The exporter does not need to have access to the internal data to get it pushed out right.

[daniel-faust]

QUOTE
Well see thing is it needs to be written down at some point anyway usually at export time

No, that's not always the case. Assuming the exporter only saves an mp3 version, and the node contains only uncompressed pcm data. If that pcm is generated on the fly by the node and kept only in memory, it would be better to give the exporter direct access to that pcm data, so that the exporter can encode it directly into mp3, aac, or whatever option has been chosen and save that encoded data to a file.

I don't quite understand your second paragraph.

A possibility would also be to wrap the node's pcm data into an MPxData class, or even better a pointer to the pcm data into an MPxData, but that sounds like a lot of overhead. The goal should be not to have a duplicate of the pcm data neither in memory nor on disc at any time.

[rob-bateman]

QUOTE(Daniel_Faust @ 02/15/07, 12:45 PM) [snapback]260075[/snapback]
What if the exporter converts the nodes data into mp3 and saves that into a file, why not let the exporter have direct access to the chunk of data in the node? But more importantly how could the exporter gain access to the data chunk in the file. I believe that probably by offering the pointer through an attribute, but of what type would this attribute have to be?

because raw data access to an mp3 would not help that problem. You'd first need to stream the data to disk before running an encoder over it. Sound API's such as DX and fmod do this by default anyway.

QUOTE
Assuming the exporter only saves an mp3 version, and the node contains only uncompressed pcm data. If that pcm is generated on the fly by the node and kept only in memory, it would be better to give the exporter direct access to that pcm data, so that the exporter can encode it directly into mp3, aac, or whatever option has been chosen and save that encoded data to a file.

again, it's not going to happen. The PCM data would have to be written to disk before the encoding takes place, unless you were nuts enough to try and write your own encoder, you would never be able to encode direct in memory. If like most people you used an encoder that is pre-built (ie, blade enc or whatever), then you will be feeding it a file on disk.

A node that generates and stores potentially unlimited PCM data is not a good design, and would actually go against maya's design philosophy. Particle emitters do not store info about when each particle was created, however the particle cache makes it appear that they do. I see no reason why the PCM data can't be generated into a cache file (*.wav) in exactly the same way that fluids, cloth, hair, particles, and dynamics do.

QUOTE
Assuming the node holds hundreds of mb of samples ...

then i'd assume you'd want to be streaming that data from disk and not have it resident in memory.