I've been playing around with the biharmonic bone capturing tech recently, and it's really cool what it can do… but I'm finding that the workflow I want to use with it is running into an issue that I don't really understand.

From what I can tell, the Bone Capture Lines SOP for biharmonic bone capturing doesn't use most of the capture region information that exists. I can change the capture region cap sizes all I want and it doesn't effect the biharmonic solution. Changing the height of the regions will, but only if I have “Use Bone Link” turned off. Additionally, as far as I've been able to tell, changing the capture region cap sizes doesn't change anything in the resulting geometry spreadsheet of the Bone Capture Biharmonic SOP or the Bone Capture Lines SOP.

And that's all great, because that means I can use the biharmonic solution as a base to start from and follow it up with capture nodes that do use the capture regions for polishing the skinning.

However, as soon as I change any bone capture regions in any way, the mesh will deform with the changes in the capture regions until I recalculate the biharmonic solution… but why?? When I compare the new solution to the previous solution in the geometry spreadsheet, the contents appear to be identical.

I hope this is a bug, but it's definitely possible that there's something fundamental here that I'm missing. I'm having trouble figuring out where to look for answers so I'm hoping someone here with deeper knowledge this topic can help me understand what's happening?

Thanks!

There's a lot of head scratching when I'm trying figuring out what's going on with bone capturing in H, so I can offer just some ideas, suggestions and observations, nothing “official”, all of which could be wrong/misinforming.


When you say “biharmonic solution” are you referring to the final capture weights of the object or the generated mesh of the Solid Embed? Assuming you're referring to the former (the latter is control with the parameters of the “Sizing” tab on the Solid Embed PPG - property/parameter page), from what I've observed from simple testing, is that indeed it doesn't affect the biharmonic solution but it does deform the mesh, in an undesired way ofc.

Editing bone regions after capturing in real-time (w/o recalculating “geo stash”), while also having a positive effect on the final weighting solution is possible only when you choose one of the other capture methods, beside “biharmonnic”.
The way you're supposed to mess around with the bones' capture region gizmos is to select the object and go “Edit Capture Regions” from the shelf, otherwise (selecting a bone directly and checking “Display Capture Region”) you'll deform the initial state of the mesh (thus behaving as if you chose “biharmonnic”). (describing it for anyone reading that might not know).

Now, as a personal side-note Edit Capture Regions and Edit Capture Weights are two nodes that stand for an workflow that is backwards, unintuitive and limiting. In this assessment, I don't even include the fact that you're going to work with them from SOP lvl only. IMO (which is waiting to be changed by some kind of argument) they shouldn't even exist as I don't see them bringing anything valuable to the table.

Edit Capture Regions is currently necessary because it seems to be a solution to a problem that shouldn't exist: why does changing the capture region size/shape of a bone deforms the initial state of the mesh instead of simply behaving as if Edit Capture Regions has been pressed? It's either because a limitation of some kind at the moment these tools were created or it's an workflow oversight or there's some benefit of having this behavior that I fail to see (would love to have it pointed out by someone if there's one). I'm betting on “limitation” since there's the possibility (and need) to recalculate the geo stash for byharmonic. For the other two methods I don't see it as a “limitation” since you don't have to recalculate anything. So no, not a bug.

Edit Capture Weights seems to be situated about the same as the “Regions” above - it give access to a Spreadsheet that should be accessible the moment a capture solution has been created for the object. Right now, accessing it from the shelf creates a captureoverride node at the object's SOP lvl. This is particularly troublesome for me because it's created after (below) any capturelayerpaint or capturemirror node and if I were to edit the weights of a point, I would go back to painting on values that are “not up to date”. Of course I have the display flag on Bone Deform and I will see the end result, but I don't like to fly blind. There's also the chance that if a manually move the captureoverride above/before capturelayerpaint and capturemirror every point weight would be “up to date” when painting, but working this way, especially when accustomed with a program w/o these complications that slow me down considerably, is something I refuse to do because I know it can be better. Besides, if I have a particular point or region that I have problems with, going above capturelayerpaint is not going to be very easy to manually enter values for each to get to where I want and we're back to having to put captureoverride below capturelayerpaint. In essence, I don't want to “leave” capturelayerpaint in order to numerically edit values for points' weights.

I hope I've addressed some of your points, added others to think about and since I have a few RFEs ready to be fired up, I'm more than happy to hear from anyone, some counter-arguments or explanations or h/e you want to formulate them to my observations, before I file said RFEs, just to make sure they're good RFEs not my solutions to nonexistent problems.

> When you say “biharmonic solution” are you referring to the final capture weights of the object

Exactly

> Editing bone regions after capturing in real-time (w/o recalculating “geo stash”), while also having a positive effect on the final weighting solution is possible only when you choose one of the other capture methods, beside “biharmonnic”.

Actually, this does not appear to be the case. Any stashed capture geo that I edit the capture region on will deform, regardless of which node did the capturing… which has actually led me closer to figuring out an answer to my question. Clearly the issue that I'm running into exists in the Deform node… Houdini appears to support two different types of region information: “Capture Regions” and “Deform/Animate Regions”. The former being used for weighting and the latter intended for deforming using similar region information. However, both values appear to change when using the tool so I can safely assume the deform region is calculated relative to the capture region, but for some reason it's not calculated as an offset but rather as an absolute comparison. If I edit the regions manually to change the Capture Region data on the bones separately from the Deform Regions, I can clearly see that the unwanted deformation only appears if I change the deform region data. So, what this tells me is that the deform node is calculating the new deform capture data relative to out of date capture region data. Looking at the Bone Deform SOP, it clearly states that it will cache the bone capture data when using Fast Deform, so this behavior actually does make sense… however, turning off Fast Deform does not fix the problem… which leads me to believe that there is a bug in the Bone Deform SOP's use of it's capture cache. Blammo! Now I can submit a bug report

As for everything else you're talking about… I think I might be able to help you if you were to rephrase some of your complaints as questions? My impression is that a lot of what is causing you trouble is a conflict of mental models between what you were used to with black-box-style software and the raw nature of Houdini.

Tristannn

McNistor
Editing bone regions after capturing in real-time (w/o recalculating “geo stash”), while also having a positive effect on the final weighting solution is possible only when you choose one of the other capture methods, beside “biharmonnic”.

Actually, this does not appear to be the case.

It's possible that I didn't understand what you mean or you did not understand me. Either way, I've attached two images with examples of biharmonic (1st trio) and proximity (2nd trio) behaviors when editing bone capture.
For biharmonic it's clear that changing a bone capture region will deform the mesh instead of changing the weights, which will of course have an impact of the final deformation, hence the slight change in point position after re-calculating.
In case of proximity, when I change a bone capture region, the affect on the final deform driven by the weights will be observed directly (in real-time).
This is what I was trying to describe. Isn't this what you had in mind?

What you're saying after that, might be true, I would have to analyze sentence by sentence with an example in front of me. Hopefully someone at SESI will understand it with less effort. Or you could roll-up your sleeves and show some image examples, because as you already know, it's hard sometimes to get exactly what the other is saying about technical issues and the saying “an image is a thousand words” never rang truer. Up to you.

Tristannn
As for everything else you're talking about… I think I might be able to help you if you were to rephrase some of your complaints as questions? My impression is that a lot of what is causing you trouble is a conflict of mental models between what you were used to with black-box-style software and the raw nature of Houdini.

I'm not sure there's a need for psychoanalyzing the reasons for why I think what I think, nor do I think I need to put question marks at the end of the descriptions of the issues or requests for improvements in order for someone to poke holes in them if they see any. I'm not pissed, don't get me wrong, I'm not sure however if I can be any clearer than I already tried to. Anyway, here's another attempt which is also framed as a question:
how can I select a point, open a spreadsheet to input numbers to edit its weights while in “paint mode” (paint layer capture) and continue painting with a spreadsheet open, ready to receive values to be edited from a selected point or multitude of points?
I don't think you can currently, hence my request with the addendum in the form of “open to explanations for why this is not a good idea or the current workflow makes more sense”.

The way I see it, in this area, Houdini has the black-box approach. “Two different types of region information” and the apparent bamboozlement surrounding it, which I share, might be another clue.

edited for minor grammar mishaps

Tristannn
From what I can tell, the Bone Capture Lines SOP for biharmonic bone capturing doesn't use most of the capture region information that exists. I can change the capture region cap sizes all I want and it doesn't effect the biharmonic solution. Changing the height of the regions will, but only if I have “Use Bone Link” turned off. Additionally, as far as I've been able to tell, changing the capture region cap sizes doesn't change anything in the resulting geometry spreadsheet of the Bone Capture Biharmonic SOP or the Bone Capture Lines SOP.

For historic reasons, Houdini started with only the Bone Capture method which used the capture regions for weighting AND deforming. In this method, the points are weighted using distances of the point within a bone's region. Then the complete state of the capture pose, the capture region transforms and its shape values are stored into the geometry itself by the Bone Capture SOP. Then at animation time, the Bone Deform SOP takes the deform region transforms and its cap values to deform the geometry (relative to the information stored within). You get no deformation when both sets of transform/cap values match. When they differ, then the deform region information is used to deform the skin relative to the capture region information.

Then when we added the Bone Capture Proxity SOP method. In this case, the shape of the capture region doesn't get used for computing weights since the purpose of the method is to use spatial distance to weight the points from the center line segment of the capture regions. However, it still records the capture region transforms and cap values into the geometry. So if you change the deform region information, it still deforms as in the original Bone Capture method. The Bone Deform SOP does not behave any differently nor know which weighting method was used.

Similarly, for the bone Bone Capture Biharmonic SOP method. For this, weights are computed over a tetrahedral mesh using the mesh edges for distances. Again, the Bone Deform SOP is orthogonal to this. The capture region is baked into geometry and deformation occurs identically as in the original Bone Capture method.

I hope this explains the current behaviour in Houdini 16.5. For the next upcoming major release, we've basically removed using the region cap values for deformation. Old scene files will still load and deform the same way but newly created setups will use the newly rewritten Bone Deform SOP that sports a simplified parameter interface. Deforming using the region cap values were using a very inefficient code path that was not multithreaded and produced questionable quality results. Another problem with using the cap values is that round-tripping out to FBX and back was impossible since FBX (nor any of the other DCC packages, game engines) supported this deformation method.

edward
I hope this explains the current behaviour in Houdini 16.5. For the next upcoming major release, we've basically removed using the region cap values for deformation. Old scene files will still load and deform the same way but newly created setups will use the newly rewritten Bone Deform SOP that sports a simplified parameter interface. Deforming using the region cap values were using a very inefficient code path that was not multithreaded and produced questionable quality results. Another problem with using the cap values is that round-tripping out to FBX and back was impossible since FBX (nor any of the other DCC packages, game engines) supported this deformation method.

hallelujah!

> I'm not sure there's a need for psychoanalyzing the reasons for why I think what I think

Sorry, didn't mean to come off like that… I was speaking from a UX Design perspective, not a psychoanalyzation perspective.


> how can I select a point, open a spreadsheet to input numbers to edit its weights while in “paint mode” (paint layer capture) and continue painting with a spreadsheet open, ready to receive values to be edited from a selected point or multitude of points?

I'm not exactly sure how you select a point in paint mode since a key trait of paint mode is that you have have a brush on your cursor, but I think you could accomplish this pretty easily by just putting a capture paint node and a capture override node down with the paint node feeding into the override. You can then open the spreadsheet on the override and have it open while you have the paint node selected and you're painting in the viewport. At any time that you wanted to edit a value in the spreadsheet, you can just click the spreadsheet window that you opened and do whatever you want without leaving paint mode.

Thanks for the info Edward! Looking forward to H17!

@Tristann, I'm sure you didn't mean to come off like anything… bad, but we tend to use all sorts of tricks, involuntarily, when communicating to one another, due to our evolu… ah screw this we're on a 3d graphics forum.

Regarding your suggestion - it doesn't work. Have you tried it? It doesn't work on my side - Spreadsheet poofs out of existence like a genie when I go back at SOP lvl / paint node.

Ok, just re-tested this - problem is not the Spreadsheet disappearing but the inability to select the to be edited points.

The window doesn't disappear for me, I've attached a movie of me doing it.

I am confused what you mean by “go back at SOP lvl” because I'm not sure when you'd be leaving SOP level?

Yes, but you don't know what points you're editing there, do you? One could enable display point # in the viewport, searching for them in the Spreadsheet and then editing their values which are going to be overrides for the actual values in the paint node above (an issue I've described above). I tried with a complex model (creature) and as it's often the case, these tests on primitives doesn't pan out exactly the same in terms of practical efficacy.

> problem is not the Spreadsheet disappearing but the inability to select the to be edited points.

I think I see what you're saying, the override node's spreadsheet doesn't appear to have any way to scope the points that get shown. This seems like a bug to me. There's probably some work around that could be built involving an HDA that isolates the points by deleting all the others and merging the weights back into the original mesh… but yeah, it seems like Capture Override is bugged. Even assigning a group to it won't keep it from listing every single point in a mesh.

It's not a bug, it's the official workflow, which involves having the mesh selected at scene level and calling the Edit Capture Weights from the shelf. Then you'll be able to select points and edit their weights in the Spreadsheet. But no paint weights allowed in this mode obviously. Now, SESI is aware of this and they'll fix it (if they didn't already in H17), but even if this will get sorted out I'm still concerned about having to edit weights numerically in a node that's an override to my paint node. Please re-read the post/s above where I've explained this and see if you're intuiting the same bad implications as I do. I tried these options (override above or below) and I feel like I'm “flying blind” and get unexpected results. It still could be me. I hope it's me…

And to not prolong this any longer than I think it's necessary: wouldn't be “natural” to have the possibility to edit points numerically (via a Spreadsheet or whatever) when in paint node without the need to lay down an override? Theoretically, an override is useful for bypassing existing something, not for editing something. Anyway, this is probably more of an aesthetic view on things than a pragmatical one and as such I don't expect everyone to share it.

You can call it a bug or not, it's at the very least a UX flaw.

It looks to me like their shelf tool is bugged too. I typically avoid shelf tools so I didn't try using it until just now. It appears to have just kicked me out of SOP into OBJ and given me an error. I believe the intended action that is supposed to occur when you hit that button is something more like what happens if you hit tab in the viewport and pick the override node after you've selected points. This adds a new override node with the points described in the group field. I would then expect that the spreadsheet from this node allowed me to ignore all the points that are not described in the group.

It looks like the documentation for the capture override node talks about some fancy bone handle dragging stuff too, but I don't see any bone handles appearing.

so… there's at least one bug with regards to the override node, or two depending if you include crippling UX flaws to be bugs. And the shelf tool seems completely useless.

> I'm still concerned about having to edit weights numerically in a node that's an override to my paint node.

The way I'm sure SESI sees this working is that you select points with the select tool, pick the shelf tool that you want to use on those points, either painting or spreadsheet editing, until you're ready to pick new points and you switch back to the select tool and repeat. What this means is that in the node editor, you will have a long strung-together back-and-forth list of override and layer paint nodes… a new one being created nearly every time you switch points or tools. In this scenario, your concern is accounted for because each tool switch will be on top of your last… however that also means the spreadsheet will not stick around. This is probably pretty easily fixed in the shelf tool by SESI adding something like a shift+click or ctrl+click action to the tool that would automatically open the spreadsheet when you want to use the tool.

Well, with your permission, I don't want us to insist on the shelf tool issue because as I said, whatever problems it has, bugs or workflow limitations, SESI are aware of them. (BTW, it's supposed to kick you out of SOP, but the error is not OK)

I guess the way SESI sees this working will see in H17 or a future version, but until then we should talk about how we see this working. I'm doing my part.
So, regarding the “long strung-together back-and-forth list of override and layer paint nodes” I'm not sure is such a good idea. It could technically work, but the amount of nodes created for a full character would be huge and I don't think anyone wants to have that. Putting them all under a subnet seems to throw out warnings about regions paths, although everything seems to function OK on the simple example I worked on (see attached).

To me a much more elegant solution would be the ability to access a spreadsheet when in paint capture mode and to be able select points. Much more straightforward, artistic friendly without detracting from the technical versatility.

Whichever way SESI will solve this will be fine, as long as the current problem with these tools working only when accessed via the shelf, and more importantly the captureoverride and capturelayerpaint current issue.

I'll try to illustrate this issue again, just in case it wasn't very clear for anyone, which could very well be the case since it's much harder to grasp ideas by parsing text than to analyze images and scene files, for most of us anyway.

First of all, these nodes are placed above the Bone Deform node in the order they are created, probably to no one's surprise. But the order they are placed matters a lot. Let's look at the attached scene file with a simple head and three bones - head and two neck bones. I want to assign all points of the head to the head bone and as such I I'll perform a lasso select in a sideview., call the captureoverride->spreadsheet->set all points to headbone = 1 (and press “Normalize” since there seems to be no auto normalize option - another subject for another time).(img)

Now, if the captureoverride node is before capturelayerpaint, I'll have no issue smoothing out the neck area which now has a harsh ridge from assigning those points to the head bone alone.
But, if captureoverride is after capturelayerpaint I cannot smooth out the neck area since whatever painting I'm doing it'll be overridden the next node below.

If I keep the former setup (captureoverride before capturelayerpaint) I can add another captureoverride after capturelayerpaint and keep alternating these - we're now in the workflow you've described. As I said, workable, but it sucks - it's very time consuming and it could come with complications after collapsing them in a subnet. Didn't test the capturemirror to see how well it would fare with this workflow.
I would collapse all these because I wouldn't want to deal with hundreds of nodes in an area where I build deformations by combining Wiredeforms with Bone Deforms which could use mixed linear/dual-q painted zones, blend-shapes, lots of stuff going on here.

So I remain at the initial assessment, that it would be better to have Spreadsheet point editing at capturelayerpaint level. captureoverride could still be around, nobody says it has to be removed (even though I did state that I find it pointless in an env. which has “spreadsheet at paint”), and if someone prefers the “alternating workflow”, it's there to use it.\

p.s. Attached the .hip file with the head for anyone's convenience should you want to play with it.

I just wanted to post an update on the original topic that I started this thread about… I talked to support and discovered that by placing a Capture Correct SOP before the deform SOP, all my issues are resolved.

@McNistor I'm moving on from skinning now but I just noticed something that you might help you. There's a dropdown in the top row of Houdini that allows you to pick different viewport quick menus. If you switch it to Rigging, it appears like the equivalent shelf features you've been trying to use might actually be working when you access them through this quick menu.