Mario Marengo Posted March 16, 2005 Share Posted March 16, 2005 Hi all, I'm in the midst of having to resurrect (not by choice) an old job that was done waaaay before all the new character tools were developed. It makes use of point attributes (whose values are determined procedurally) which then get saved to a capture override file where each attribute name matches a null object (within a hierarchy of nulls), each containing a corresponding capture region (cregion) sop -- no bones needed or used in this scheme. The override file is created through a script, but the end result is simply to map a point attribute to a capture weight... nothing more esoteric than that. So here I am trying to "update" and hopefully simplify this mess via the new tools, but I can't seem to find a way to do it. I'm not up on all the new character stuff, so I'm hoping someone will say: "Oh yeah, just do this and this" To summarize: I need a way to map point attributes (whose names match capture region names) to capture weights (overriding the respective CaptureRegionSOP weights). Again, these weights are determined procedurally, so "painting" them is not an option. Lastly, there are no bones used anywhere in all this; just nulls with "cregion" SOPs. Thanks in advance for any help. Quote Link to comment Share on other sites More sharing options...
michael Posted March 16, 2005 Share Posted March 16, 2005 hmmm... I think the attribute transfer sop should do the trick... or the capture override mode.... I think as long as your geometry has the right attributes (the ones that the deform will need) you can shoehorn in the actual values any way you'd like... Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted March 16, 2005 Author Share Posted March 16, 2005 Hey Michael, Thanks for the ideas, but... hmmm...I think the attribute transfer sop should do the trick... First thing I tried (since it sounds exactly like what I'm after). Problem is that a capture region's weight is embedded in the pCaptData detail attribute, and so (AFAICT) can't be used as a target for the transfer... unless I'm missing something. or the capture override mode.... Tried that too, but no luck. From what I can see, this mode presents me with a spreadsheet of the current weights (essentially a spreadsheet view of pCaptData) which I can then modify (per point). No good since I'd have to manually enter values for 1000+ points... I think as long as your geometry has the right attributes (the ones that the deform will need) you can shoehorn in the actual values any way you'd like... Exactly. That's what I was thinking. But the question is how to convert these plain-vanilla attributes to a form that the deform SOP can understand -- i.e: how to stuff them into the pCaptData structure. But with all these new tools, surely there's got to be a way that I'm just not seeing... Quote Link to comment Share on other sites More sharing options...
michael Posted March 16, 2005 Share Posted March 16, 2005 Hey Michael,Thanks for the ideas, but... First thing I tried (since it sounds exactly like what I'm after). Problem is that a capture region's weight is embedded in the pCaptData detail attribute, and so (AFAICT) can't be used as a target for the transfer... unless I'm missing something. odd...this should work just fine....if you specify in the attribute transfer that you want to transfer detail attributes...then pCaptData hmm..maybe it's attribute COPY that will work...I think the transfer will only work if the destination geometry already has the attribute > then it can transfer the values... do you have an eg file at all that we can play with.... I think this should be a really easy task.... Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted March 16, 2005 Author Share Posted March 16, 2005 odd...this should work just fine....if you specify in the attribute transfer that you want to transfer detail attributes...then pCaptData Well... a plain detail attribute (that a user can create) can only be at most 4 floats long. The pCaptData attribute (which is just the data member of the pCapt* family) is a 2D array with NPointsXNRegions entries. And there's no way for me to create a NPoints-long detail attribute. IOW, I can't transfer from detail->detail. The attributes that need transferring are, by necessity, *point* attributes. Or at least that's how I interpret things.... which could be all wrong.... hmm..maybe it's attribute COPY that will work...I think the transfer will only work if the destination geometry already has the attribute > then it can transfer the values... OK. I'll try that, thanks. do you have an eg file at all that we can play with....I think this should be a really easy task.... Yup. I'll put together a sample hip asap... off to a meeting now, but I'll do it soon. Thanks again. Cheers! Quote Link to comment Share on other sites More sharing options...
michael Posted March 16, 2005 Share Posted March 16, 2005 here's what I was thinking... see attached file thekenny mentioned that there might be other factors to look into -skelroot path, stale regoins etc... but give this a try... attribTrans_4_mario.zip Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted March 16, 2005 Author Share Posted March 16, 2005 here's what I was thinking... Hey Michael. Thanks for the hip -- one hip file is worth 1000 posts I see what you were thinking, but that's not what I was after. Here's a simplified example of what I'm after. The "OldMethod" SOP is the result of the method I'm trying to "upgrade" using the new tools... if possible. Hope it makes sense. I've annotated it a bit. AttToWeight.zip Thanks for all your help! Quote Link to comment Share on other sites More sharing options...
michael Posted March 17, 2005 Share Posted March 17, 2005 damn sorry...got busy...I'll have a look at it tonight... Quote Link to comment Share on other sites More sharing options...
thekenny Posted March 17, 2005 Share Posted March 17, 2005 Mayhap I'm missing something far more intelligent than I am feeling at the moment. I have attached a file with the attribTransfer "working". I've locked the captureSOP you were using with the override file for ease of use. Basically if you can mimic this in your session you can get the attributes over to the geometry. Really the second CaptureSOP in the network is not necessary. If you old file can produce a valid capture than you should be cool. I'm not sure that the extra "C" attributes are intended to be used with, but I'm a bit tired at the moment. Really I'm surprised I'm using a computer at home after my day. Let me know. -k AttToWeight2.zip Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted March 17, 2005 Author Share Posted March 17, 2005 Hehe -- using computers after work is hereby prohibited! Though I truly *do* appreciate the after-hours effort you put in. Thank you! Mayhap I'm missing something far more intelligent than I am feeling at the moment. I have attached a file with the attribTransfer "working". Damn, you got me all excited when I read that! But no, you misinterpreted the point behind those two SOP chains. The one on the left (capture1,deform1,OldMethod) represents, as a unit, the "old method": i.e: solving the problem via an override file which gets created using tcl scripts, etc, etc. And the one on the right (capture2,mmmnope,deform2,NewMethod) is a non-functioning stand-in for a yet-to-be-discovered method to do *exactly* what the chain on the left does, except using the current attribute/capture tools which didn't exist back when this was done. Yes, I'm aware that there is a solution (it's the one on the left chain that you stole the attributes from, lol!). That's why you felt that those two capture/deform sops were redundant -- you thought they belonged to the same solution. But they don't. I tried to clarify that in my SOP notes, but I guess I didn't do a very good job of it. But my initial question, which still stands, was: Can we duplicate the functionality of the clunky old method by using our new, shining attribute/capture tools? (I'm starting to feel the answer is "no"). To put it as clearly as I can: 1. Delete the sops capture1, deform1, and OldMethod. 2. Using any tool available to you (within Houdini), duplicate exactly what it was doing, which was to override the capture attributes "C_Hold" and "C_Rings" with the point attributes of the same name (the ones you weren't sure what they were for). I hope that makes it a little clearer... it sounds more complicated than it really is, which is: make those point attributes *become* the capture weights. Cheers, and thanks again! Quote Link to comment Share on other sites More sharing options...
edward Posted March 17, 2005 Share Posted March 17, 2005 I've attached one possible solution. It's not necessarily less complicated but does away with the need of an external file. The method depends on using the Geometry CHOP/Channel SOP combination to manipulate the weights. So unless your old method predates them, the "new" method could have always been used. NB: Sorry, for the .hipnc file as I'm at home. So be careful that it doesn't contaminate your production files. AttToWeight1_edward.zip Quote Link to comment Share on other sites More sharing options...
sibarrick Posted March 17, 2005 Share Posted March 17, 2005 Cool solution, I didn't know you could use chops to deal with bone capture attributes. This should definately go onto the exchange forum. It's also got me thinking maybe I can use it for something similar too.... Quote Link to comment Share on other sites More sharing options...
thekenny Posted March 17, 2005 Share Posted March 17, 2005 To put it as clearly as I can:1. Delete the sops capture1, deform1, and OldMethod. 2. Using any tool available to you (within Houdini), duplicate exactly what it was doing, which was to override the capture attributes "C_Hold" and "C_Rings" with the point attributes of the same name (the ones you weren't sure what they were for). sigh, I was a afraid you were going to say that....I knew it couldn't be that easy...it was late and the baby was finally asleep... sigh. Maybe you could do it in SOPland if you "tricked" your attributes to be valid weight for different capture regions and then did a attribComposite to balance out the weights. Edward's method is Houdini-smart, meaning it will work and open new doors of houdini to many users, but isn't one of those things that "leaps" out at you:). If I have time I'll try the trick idea. I think you are stuck to use the perl/tcl method or actually do Ed's suggestion. Quote Link to comment Share on other sites More sharing options...
edward Posted March 17, 2005 Share Posted March 17, 2005 Perhaps someone else could make an OTL out of the CHOP setup. The use of Channel SOP/Geometry CHOP has come up before. eg. this thread: http://odforce.net/forum/index.php?showtopic=1883 Finally, this method used to be my excuse for not adding some independent support for external capture weight files. Because one could always use a File CHOP to bring in weights which are then stuffed into the pCapt attribute via the Channel SOP. Of course, now that the Capture SOP can do weight blending, it can be used to load/save the .ocapt files so I have a new excuse. Quote Link to comment Share on other sites More sharing options...
michael Posted March 17, 2005 Share Posted March 17, 2005 ooooffff... nice one ed.... Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted March 17, 2005 Author Share Posted March 17, 2005 Woohooo!!! Nice going Edward! Thank you, thank you, thank you!! That's great. And I think you're right: that this is a solution that could have been used back 5 years ago (when this "capture file" approach was done). Then again, I fully agree with thekenny in that it's not something that "leaps out at you" -- if for no other reason than that it depends *entirely* on the user's precise knowledge of how these weights are stored internally. After going through this little exploration though, a few thoughts come to mind, and I'm curious to hear what people here think... It seems to me that we have, at this point in time, no built-in tools to define capture weights *procedurally* (Ed's wonderful workaround not withstanding). We can paint them or capture them (all of which are very nice to have), but no way to define them based on some arbitrarily complex expression/relationship/whatever. I get the feeling that all the current weight-manipulation tools were born from the assumption that they'd only ever be needed in the context of rigging or character building. As a result, they seem to live in a separate world of their own (IK,bones,capture regions, etc.), which is hard to access from the "normal" side. And it's fairly obvious from this thread that the biggest hurdle to accessing them is the fact that they're not stored as standard attributes, and so none of those wonderful attribute tools can be used with them (directly). This cuts off a huge chunk of juicy functionality from weight manipulation side of things. We need a bridge! I'd like to propose a possible bridge as an RFE: 1. A simple modification of the Capture SOP: Add a toggle to the CaptureSOP, let's call it "Attribute Override" for now. When this toggle is on, any incoming point attributes whose name matches one of the Region names, overrides its values. This behaviour is not unlike geometry attributes overriding shader parameters, for example, and I'd say is fairly intuitive, no? This would at least give us a quick and easy "good for now" method of getting "in there" easily. 2. Provide an alternate path that removes the need for a Capture SOP: Why do we need a capture SOP? Why is the capture SOP the only gateway to controller-based deformations?... because it was created with bones (and rigging, etc) in mind, I know, but it doesn't *have* to be limited to that, does it? A generic solution would simply associate a controller object with a weight distribution. And whether that distribution came from using a capture sop (because you were using bones, say), or via some other yet-to-be-imagined method shouldn't matter in the least -- i.e: the "bone" thing is just a special case. So I propose a new SOP (let's say "AttributeDeform" for now) which let's you associate a [point|prim|det]::float attribute to an object. And needless to say, the controller object would not be required to contain a CaptureRegionSOP since the weight distribution is defined by the incoming attribute. Internally this would simply build a pCapt (or add to it) structure in exactly the same way that the CaptureSOP does, ready for the DeformSOP. The AttributeSOP would also need to be extended to handle deleting/renaming one of these "deform" attributes properly. What do y'all think? Quote Link to comment Share on other sites More sharing options...
michael Posted March 17, 2005 Share Posted March 17, 2005 damn...nicely put... I agree that a 'bridge' is needed (and advantageous) and it's in keeping with the whole Houdini way of thinking... arbitrary controler objects > attributes > deform... this would make the current capture[bones] and wireCapture special cases of a larger process. Quote Link to comment Share on other sites More sharing options...
thekenny Posted March 17, 2005 Share Posted March 17, 2005 oh, I can't wait till Ed reads that post. The attributes are laid out in a specific manner, and the Deform and the captureSOP work with them in that manner. It kills me every day that the wireDeformer/wireCapture don't work in the same manner. I think they would have to rewrite a lot of stuff to unify the current SOPs or make new ones. The easy route would be to make new ones that don't work with the other ones. But really that wouldn't be any good at all. Ed..? -k Quote Link to comment Share on other sites More sharing options...
sibarrick Posted March 17, 2005 Share Posted March 17, 2005 200% agreement from me. That was the whole reason behind writing all that flexor stuff. I wanted a procedural way to capture non character stuff. I got it working with skin aka character stuff, but use it for all sorts of other things. In reality it was just a great big workaround for not being able to procedurally tagged into all the deformation stuff. As Mario says at the end of the day you are just creating a bunch of attributes that tell the deform sop how to attach points to other bits of geometry, very useful for all sorts of cool stuff, and right up the Houdini street. Way more powerful than what you could do in any other package. Love to see this done For now though at least Ed's way gives me the possiblilty of a faster solution. Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted March 17, 2005 Author Share Posted March 17, 2005 arbitrary controler objects > attributes > deform...this would make the current capture[bones] and wireCapture special cases of a larger process. 16893[/snapback] Exactly! Generic vs. dedicated. I think they would have to rewrite a lot of stuff to unify the current SOPs or make new ones. The easy route would be to make new ones that don't work with the other ones. But really that wouldn't be any good at all. 16897[/snapback] Aye, ere's the rub... I'm pretty sure that none of us want anything that's already there to break. That's why I was thinking along the lines of some bridging tools -- a bit of glue. And it's really all to do with getting at that pCapt structure which doesn't play nice with the rest of things... so some glue should (I hope) be easy to implement... then again, maybe not... For now though at least Ed's way gives me the possiblilty of a faster solution. 16901[/snapback] Absolutely. None of what I mentioned was meant to detract from Edward's wonderful solution. In fact, I'm using it right now, and it rocks! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.