On Tuesday, May 1, 2012 10:58:27 PM UTC-4, notanymike wrote: > > I skimmed through it -if MPxData isn't a good way to go, isn't it more > unsafe to have an array of MMatrix plugs being constantly changed? > > I'm basing my spline math from this paper: > http://www.gpstraces.com/sven/main/publications/skel.paper.lowres.pdf > and my skinning method from this one: > http://www.alecjacobson.com/weblog/?p=2104#comments > > Thanks for bringing those papers to my attention- I'm a bit embarrassed that I hadn't seen the second one- I guess it is pretty recent though. I spent a lot of time working on a spline-based deformation method last year. We've had to suspend work on it for the last six months or so in order to get some other products out the door, but we hope to resume work on it pretty soon. There's an early demo of it on Youtube: http://www.youtube.com/watch?v=rzUhRrqA97w . You might find it interesting if you're working spline-based deformation.
We did wind up using MpxData nodes to pass around certain information about the deformation. But we cheated pretty heavily, IIRC. It has been a long time since I looked at that bit of code, and it was traumatic enough to write that I've blocked the memory a bit, but taking a quick look at it it looks like what we did was basically store all of the data we cared about in module-level dicts and then passed around just enough data to let other objects key into them. This is clearly not "The Right Thing" (tm), but it vastly simplified the code. There is a downside to it though- it means that only our code has access to those bits of data. Since they aren't accessible through any plugs in the scene graph a rigger can't make use of them. So we only used this technique to pass around data that is basically internal to the way our algorithm works. For data that might be important to a rigger or a scripter (for instance the rotational frames at joints, etc.,) we bit the bullet and used array attributes, often fairly complicated compound array attributes. These have some real downsides, and require a fair bit of boilerplate to deal with. I wound up writing a little DSL in Python for this project that lets you specify attributes on derived nodes using a declarative syntax, and does all of the setup for you when the nodes are registered- we had to rework the design of our nodes quite a few times and I'm not sure we would have kept our sanity without it. Another thing I should mention is that to get this working at interactive speeds we had to write a lot of it in C. Our algorithm is pretty expensive, so we knew from the outset that we were going to have to do this at least for the tight inner stuff. But one thing we discovered is that instantiating objects in CPython is expensive enough that even rewriting the tight inner stuff got us no gain in speed because converting the results from C into Python was very, very expensive. In the end we wound up having to play a lot of games involving snaffling the pointers out of swig objects and passing them into some C++ functions that we used to actually set values on the output blocks, etc. Basically, if you want to write things like this in Python to get the algorithms right and then gradually replace with C/C++ you're probably going to have to do stuff like that if you want things to work interactively with reasonable data sets. You'll note that in the demo I linked to the frame rate is pretty low considering the amount of geometry involved- we were still working out the details of passing things around to avoid instantiation of objects in Python at the time. I think that writing in Python first to get the details worked out was definitely a win for us, but it might have been easier to just rewrite ground-up in C++ for the fnal implementation. I mention all of this because you're asking about using MpxData nodes for efficiency- I don't know the details of what you're doing, but I think it's possible you might have bigger problems than that with efficiency. Sorry for the length of this message. I hope some of it at least is useful to you. Best T -- view archives: http://groups.google.com/group/python_inside_maya change your subscription settings: http://groups.google.com/group/python_inside_maya/subscribe
