Maya mesh modifier node with init component transform issue

Coding
1

Hi,

Great forum, lots of respect.

This is some stupid problem i am having with being new to the maya api. Something to do with poly mesh caching and tweaks, maybe.

I have a simple-as node (OpenMayaMPx.MPxNode derived) that takes a mesh in, copies it, does some modifications to CPVs, and spits out the mesh. No special business, this is the skeleton (also file is attached as an example node of this, and setup in he header to quickly see what im on about, if you’d be kind enough to look):


def compute(self, plug, data):
    if plug == self.outMesh:
        
        inputMesh_dHandle = data.inputValue(self.inMesh)
        outMesh_dHandle = data.outputValue(self.outMesh)
        
        if directCopy:
            outMesh_dHandle.copy(inputMesh_dHandle)
            outMesh_mFn = OpenMaya.MFnMesh(inputMesh_dHandle.asMesh())
            
            # do CPV stuff
            # outMesh_mFn.setVertexColors(colours, vertsToSet)
            
            #outMesh_mFn.updateSurface()
            data.setClean(plug)
            
        else:
            
            inputMesh_obj = inputMesh_dHandle.asMesh()
            
            newDataCreator = OpenMaya.MFnMeshData()
            outMesh_obj = newDataCreator.create()
            outMesh_mFn = OpenMaya.MFnMesh(outMesh_obj)
            outMesh_mFn.copy(inputMesh_obj, outMesh_obj)
            
            # do CPV stuff
            # outMesh_mFn.setVertexColors(colours, vertsToSet)
            
            outMesh_dHandle.setMObject(outMesh_obj)
            
            #outMesh_mFn.updateSurface()
            data.setClean(plug)

… and it appears to work well (there is some not so nice viewport flickering, but other default maya ops working on CPV do the same thing), but for one thing - if you do a transform on an input mesh component, it allows one budge and then also selects the corresponding component on the output mesh, freezes further dragging interaction, and then drops them after mouse off. Subsequent modifications to the input poly dont have this problem. If you simply just select any component on the output mesh (just select, nothing else, no transform) before you do a tweak on the input, then the behavior is normal for that first tweak. This happens regardless of whether the input mesh or the output mesh had history or not, or tweaks, before sticking my node between them. Is this something to do with cachedMesh or tweaks, or similar, but i cant bloody see what to do. That you can ‘prevent’ this ‘problem’ by simply select an output mesh comp before hand makes me suspicious about the cache/tweaks though, as it surprising that a GUI style thing does this when no mesh mod has occurred (?) by simple selection? There other phenomena I could further add, but this is probably diagnostic enough for you folk, and ill try to reduce the noise.

Margh! Retard. I’ve read the api doc notes, but I’m not so sure i need to be doing any extra style things like the polyModifier examples. Save me.

Thanks,
C.

2

Of course, once you write it up, other things become clear. I do need to write a command for inserting the node in to the dg, handling the extra polyMesh features. Confirmed this fro myself simply by running through the same node insertion process as i do with my node, but using the polyColorMod node instead - to get the same resultant behavior as my node. Kinda makes sense, as you dont want a node to be faffing around with other nodes, it shouldnt know anything about the others, and by me modifying a downstream node to get the desired result (doing the ‘pre-tweak component selection’), obviously means i cant get what i want by changing the guts of my node - i need to write the node insertion cmd/script.

Pardon the noise. Feel free to further enlighten me though!

C.

3

Sorry to be spamming away, I’m wondering now whether people commonly do use polyModifier/Cmd based implementations to manage insertion of their poly operation nodes in to the dg?

… there seems to be very little discussion about it on the web, which seems mildly (/bigly) concerning to me? - on github there is like only 3 or 4 projects that seem to use it (pyMel, Byrons/Sebastian’s older stuff, and NetAllied MayaDataModel), same deal using google code search, on forums, references are ~ 2 here including this thread, 10 on cgtalk, 20 on creativecrash/HEnd3d and.

Part of the picture feels like its missing from the box. I dont want to wast time on a bent model, even if it does appear to be sanctioned by autodesk/alias.

Thanks.

4

I wrote my first DG node not too long ago, and I did use a polyModifier-based implementation. It worked out well for me, since I could spend most of my time working on the node itself and not worrying about modifying the DG. I don’t know whether it is “recommended” to use polyModifier. Maybe there are some disadvantages that I just haven’t run into yet. But my node works, which is what I really care about.

That being said, I did find two bugs in the polyModier code. One of them was pretty easy to fix. The other one I was only able to fix partially, because my understanding of cached tweaks is still a little shaky.

Whether or not you decide to use polyModifier, it is definitely worth looking at. Both the comments and the code itself are really helpful to learn how to insert your node into the DG.

5

Thanks for your notes.

I did end up going down the polyModifier derived root, at least for a test (and sorted the MSciriptUtil mal calls out too [assume thats what you were referring to?], didnt test for the tweak nodes case yet). Reading through the entire code was informative. But, lo, the problem persisted (the init tweak ‘double seln’ drop thing)… I think I’ve found a low level poly dg data flow issue (you get it even w/o node insertions). I hope to look at it again later today and write it up for the beta dev forum, I’ll post back here too.

’ best,
C.

6

Yeah, the MScriptUtil call was the bug I was referring to.

As for the rest of it, I’m not really sure I understand what you are trying to do. At first I thought you were doing the standard create-a-node-to-modify-an-existing-mesh. But rereading your post, it sounds like you want to end up with two meshes after the operation? The original one, and then another one that starts out as a copy of the original one but then gets modified?