[SOLVED]Getting DzBone associated geometry vertices

hphoenixhphoenix Posts: 1,335

I thought I had it, but turned out to only be a typical case.

Given a node (DzBone* bone), I can get it's skeleton via bone->getSkeleton(), from the skeleton, I can get the DzObject, then from the object I can get the DzShape, and from the shape I can get the DzVertexMesh, which I can get the DzFacetMesh from.  This all works just fine.

I was using DzFacetMesh::findFaceGroup(bone->getName()) to get the DzFaceGroup for the bone via its name.  This works with most standard figures (where the bone name and the FaceGroup name are the same.)  From the DzFaceGroup, I can pull the vertices into a DzTSortedArray<int> and then iterate through the array and copy the vertices into a DzTArray<DzVec3> to be handled elsewhere.

But, in other figures (hair, props, etc.) the FaceGroup name isn't necessarily the same as the bone name.

Because of that, the call to DzFacetMesh::findFaceGroup(bone->getName()) fails to find a matching FaceGroup, and I get nothing back.

 

So is there a consistent way to determine which FaceGroup is associated with a given bone in a figure?

 

Post edited by hphoenix on

Comments

  • hphoenixhphoenix Posts: 1,335

    Okay, I think I found how, after much searching.

    For a given DzNode *x I can call x->getSelectionMap() to get the DzSelectionMap* for that node.  Then I can use GetNumPairs() to determine if more than one face group maps to this node, and can then use getPairGroup(index) for each (if more than one from getNumPairs()) to determine the FaceGroup names associated with that particular DzBone node.

    Going to test tonight, will report back here if it works as hoped for!

     

  • hphoenixhphoenix Posts: 1,335

    Well, that was a complete bust.

    It appears that node->getSelectionMap() isn't working.  At least not as advertised.  I've tried it across a multitude of various types of nodes, and in EVERY case it returns NULL.

    Anyone else got any ideas?

     

  • rbtwhizrbtwhiz Posts: 2,181

    Given some comments you've made I'm not sure you'll appreciate that my response is in the form of a script, but I've posted one nonetheless to show how this works: Node FaceGroup Map.

    Why a script over C++? Well, because the APIs are basically the same, it's a bit less work (i.e., it takes less of the time I already don't have) to provide a working example, and it's self standing (i.e., there is no compiling, no linking, no preprocessor directives, etc. to worry about). That and it has been my experience that those who grok C++ are also likely to be able to translate the syntax of a script to C++, whereas that seems to be less so in the opposite scenario. Two birds, one stone.

    -Rob

  • hphoenixhphoenix Posts: 1,335
    edited March 2016
    rbtwhiz said:

    Given some comments you've made I'm not sure you'll appreciate that my response is in the form of a script, but I've posted one nonetheless to show how this works: Node FaceGroup Map.

    Why a script over C++? Well, because the APIs are basically the same, it's a bit less work (i.e., it takes less of the time I already don't have) to provide a working example, and it's self standing (i.e., there is no compiling, no linking, no preprocessor directives, etc. to worry about). That and it has been my experience that those who grok C++ are also likely to be able to translate the syntax of a script to C++, whereas that seems to be less so in the opposite scenario. Two birds, one stone.

    -Rob

    Rob, I really wasn't trying to be mean or disrespectful.  And in my later response in that thread, I tried to make that clear.  But I did want to make DAZ (not you specifically) understand that we need them to put more resources toward getting the documentation and SDK completed and up-to-date (which I know is unlikely as script/plugin writers are a small fraction of the users).  And I don't mind it being in a script form, as I know the scripting API is directly tied to the same plugin SDK methods.  As I said, I'm a software engineer myself, so I know how busy we stay....But it is quite frustrating when you need/want to get something done, but don't have accurate/complete documentation to do it with.

     

    So we have to use the selectionMap of the Skeleton of the selected Bone, then iterate through all the bones in the skeleton, using selectionMap.FindGroupForNode(boneInSkeleton) for each to get the FaceGroup.  But if we already have the node, do we have to iterate?  I'll do some tests tonight.  Seems like we should just be able to specify the bone node we selected, rather than having to loop through them.  I think my issue was I was using the selectionMap from the Bone nodes, not the skeleton.  Knowing that makes a big difference.  May want to add a blurb to the DzSelectionMap docs to indicate this.

    Wait....does the node have to be selected?  I.e., if I simply iterated through all the root nodes, find skeletons, and get facegroups for their bones using the above method, does each have to be selected first before GetSelectionMap() will return valid data?  Can I simply call node.select(true) beforehand?

    Thanks!

     

    Post edited by hphoenix on
  • rbtwhizrbtwhiz Posts: 2,181
    edited March 2016

    No, you do not need to iterate over all bones of a skeleton. No, the node doesn't need to be selected to be found in the map. I iterate in the sample just to show the requisite call being made against multiple nodes and to illustrate that there are (potentially) nodes that are not in the map; Genesis 3 illustrates this in spades. All you need to do is use the node (selected or otherwise) to get the skeleton, use the skeleton to get the map, use the map to get the name of the face group (if any) associated with the node.

    -Rob

    Post edited by rbtwhiz on
Sign In or Register to comment.