Thanks for the details. I had seen that video before, actually. I thought I might as well share the code since the concept and implementation isn't really mine to begin with -if it helps anyone wanting to help me with this: https://docs.google.com/open?id=0B9cZ0O2OYVsSWC1lLU92dzdxMnc The code is relatively fast on low-poly geometry, and I suppose the data can be shared or at least copied using a MPxCommand perhaps? I might also consider going another route for skinning, such as implementing a zsphere-like procedural geometry node -which also uses joints- as a method of FFD. It's a more original idea, I think, but I don't know where to get the math or programming knowledge for such a project...
On Wednesday, May 2, 2012 9:18:56 AM UTC-7, T. D. Smith wrote: > > > > 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
