Hello Mike and everyone, I have done something similar in the past few month : ( shamelessplug on my blog<http://circecharacterworks.wordpress.com/2012/02/15/curve-studiesbending-limbs-effortlessly/>). Just a couple difference: I use strictly regular attributes ( nurbsCurve, pointArrayData, polygonal mesh ): I wanted to spent my time on write nodes and not understanding the more complex part of the API How about "decompiling" each matrix into a MPoint and packing it into a single pointArray data. Like TD Smith said, I use python to do my prototype then switch to C++ .
Now I have a splineMatrix node that compute useful coordinate information and can be used by deformer or maya instancer. This was really fun in the end when I was able to overcome all the difficult part( having a stable coordinate system from the start to the end of a curve, binding mesh independently from its topology etc ) CedricB, http://circecharacterworks.wordpress.com/ Le mercredi 2 mai 2012 19:45:37 UTC+2, notanymike a écrit : > > 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
