Exporting geo-grafted geometry

pcicconepciccone Posts: 660
edited December 1969 in Daz SDK Developer Discussion

Hi.
In general Reality (devel version) has no issues in exporting any geometry in the Studio scene but there is currently one issue with geo-grafted geometry.
For example, the female genitalia for Genesis 2 appears integrated in Studio but when exported by Reality it appears as being applied on top of Genesis 2's crotch.

I see that in Studio the genitalia is a parented figure but, obviously, Studio is handling in a special way. Is there some flag in the geometry that is used for this "merge"? Can you help me understand how the geometry should be exported in order to appear correctly?

Thanks in advance.

Comments

  • dtammdtamm Posts: 126
    edited December 1969

    As an edge case, if dzApp->getInterface()->getViewportMgr()->allowGraftDrawing() is false, them the app is in an geometry editing state and the grafts are not available.

    Otherwise you should be in a normal grafting state in which the following is known to work.

    
      DzFigure* figure = qobject_cast(node);
      if (figure && figure->isGraftFollowing())
      {
       if (figure->getFollowTarget() && figure->getFollowTarget()->isVisible() && figure->getFollowTarget()->isVisibileInRender())
        continue; // meaning skip this figure.  Its grafting geometry will be on its target figure.
      }
    
  • pcicconepciccone Posts: 660
    edited December 1969

    Thanks. I'll try that.

  • pcicconepciccone Posts: 660
    edited December 1969

    That worked like a charm.

    Thanks.

  • pcicconepciccone Posts: 660
    edited December 1969

    Actually I talked to soon.

    The above code works for some female genitalia but does not work at all for the male kind.
    Using M6 with the G2M genitalia, in that case a hole is rendered in place of the genitalia and the polygons in the crotch area have the wrong UV mapping.

    Obviously there is something else going on.

    Any help will be greatly appreciated.

  • dtammdtamm Posts: 126
    edited December 1969

    Perhaps the following might be relevant:

    // this rebuilds the cached geometry

    
       shape = object->getCurrentShape();
       if (shape)
       {
        object->update(*node, false);
        object->finalize(*node, false, true);
    
        DzFacetMesh* mesh = qobject_cast(object->getCachedGeom());
       }
    
    


    // this is how to iterate across the materials with respect to geo-grafts

    
       for(int i = 0; i < shape->getNumAssemblyMaterials(); i++)
       {
        DzMaterialFaceGroup* faceGroup = 0;
        if (facetMesh && facetMesh->getNumMaterialGroups() > i)
         faceGroup = facetMesh->getMaterialGroup(i);
        DzMaterial* material = shape->getAssemblyMaterial(i);
    
  • pcicconepciccone Posts: 660
    edited December 1969

    Thank you but Reality already follows that logic.
    The issue is that when a grafted object adds geometry the approach does not work. That is because the grafted figure is skipped and Reality does not recognize the grafted materials as belonging to the base figure. Obviously I'm missing some terminology here.

    It would be very useful to have an description of how the geo-grafting process works. Right now it is undocumented, and so it is hard to understand how this geometry should be exported. I see that the DzFigure class is largely undocumented. There are several methods that are involved with geo-grafting. This would be the right occasion to describe how the geo-grafting system modifies the geometry and what all those methods do.

    Thanks in advance.s

  • pcicconepciccone Posts: 660
    edited December 1969

    Here is another example of the struggle plugin developers go through.
    When adding a geo-grafted figure there is no obvious change in the material list of the base figure. For example, if we add the genitalia to M6, there is no change in the material list in the Surface tab. M6 keeps its original list of materials.

    On the other hand when Reality cycles through all the materials for M6 the "Genitalia" material is returned by Studio but that is not found in the list of materials previously associated with M6. So, there is need for some clarification here.

    Thank you.

  • pcicconepciccone Posts: 660
    edited December 1969

    So, it seems that the geo-grafting operation adds materials from the grafted figure to the main figure. That's what it seems after my tests.
    The problem is that there is no event of this happening. For example, the materialAdded() signal does not seem to be triggered.

    I tried working with the graftListChanged() signal and iterating through the materials to find the ones that have been aded. No materials are found to be added.
    Yes, when I export the figure there is a material in it that was not found before. Unfortunately, since that material is not in the Reality database the export then fails.

    Please provide information, I can't add support for geo-grafting without your help.

    Thank you.

  • pcicconepciccone Posts: 660
    edited December 1969

    Since I need to get this resolved I did more experimentation.

    I need to make a premise. Reality works by collecting material data for each object in the scene. It does not distinguish between figures and props. They all are just objects. Object have materials. If a material is not found in Reality it does get rendered so it's vital to keep a 1-to-1 correspondence between Studio and Reality.

    In my example here I'm using G2M and the male genitalia object. I call G2M the "main figure" and the genitalia the "grafted figure."

    I was able to receive notification of the addition of the geografted material added to the main figure.

    The issue is that the Studio SDK always fires the signals at the beginning of the chain of events, instead of at the end. This is very plugin-unfriendly as a plugin needs to start working on the objects added to the scene once they are defined. Firing the signal when an object is instantiated but is incomplete creates a terrible burden on the plugin writer who is forced to resort to all kinds of hacks to postpone the scanning of the object. It would be nice to have additional signals that fire at the end of the update chain. For example, objectAdded(), materialChanged() and so on.

    In the case of the grafting action, I added a slot to the signal graftListChanged() to capture the addition of new materials to the main figure. After adjusting it to star at the end of the chain I was able to add the "genitalia" material to the main figure. The genitalia object is also added, as it was from the beginning, to the Reality database, as a separate figure from G2M. This is consistent with how Reality works.

    So, now I have the genitalia figure and its two materials, Hip and Genitalia, in the Reality list of objects/materials.

    The addition makes the rendering of the main figure more or less OK. The additional polygons are rendered by Reality but the material is not correct. As we know the genitalia comes to the scene in neutral grey. Applying the right skin material changes the material in Studio. It also changes the Reality material associate with the Genitalia object, as expected, but Reality does not receive the notification of the change to the Genitalia material attached to the main figure.

    Exporting the scene to LuxRender results in the main figure with the grafted figure on, but the material is incorrect, it's neutral gray. Also, the are of the hip where the two figures connect is incorrect, the texture does not fit anymore. Here is a figure to show the effect. Please note, NSFW:

    https://dl.dropboxusercontent.com/u/3701566/grafting.png

    If I ignore the material added to the main figure and export the grafted figure I get a better result except that there is an obvious overlap of polygons in the area where the two figure connect.

    I need some clear guidance on how to handle the grafting process works so that I can export the polygons and materials correctly.

    Thanks in advance.

  • dtammdtamm Posts: 126
    edited December 1969

    It sure sounds like a DzShape::getMaterial vs DzShape::getAssemblyMaterial thing.

    Perhaps you should PM me how you are grabbing the materials and how you are getting the mesh and matching the material with each facegroup.

  • dtammdtamm Posts: 126
    edited November 2015

    A high level view of how grafting works, which I assume you have already figured out, but just to make sure
    a) Main Figure
    b) Graft Figure

    When "Graft Figure" is grafted onto "Main Figure", in a sense "Graft Figure" itself become an empty figure. In general, its geometry is no longer drawn.

    "Main Figure's"' geometry(DzObject::getCachedMesh) includes most of "Graft Figure's" polygons. "Main Figure" will also hide some of its own polygons. The materials used to draw "Main Figure's" geometry will be DzShape::getAssemblyMaterial respectively. In other words DzShape::getAssemblyMaterial(index) corresponds to DzFacetMesh::getMaterialGroup(index) when dealing with the DzFacetMesh that DzObject::getCachedMesh returns.

    To handle some of the polygons being hidden, we have to pay attention to the facet flags.

     

     DzFacet* facets = facetMesh-&gt;getFacetsPtr(); const unsigned char* facetFlags = facetMesh-&gt;getFacetFlagsPtr(); for(int f = 0; f &lt; faceGroup-&gt;count(); f++) {  int i = faceGroup-&gt;getIndex(f);  if (facetFlags[ i ] &amp; DZ_HIDDEN_FACE_BIT)   continue;  // Do something with this facet. }

     

    Post edited by Richard Haseltine on
  • pcicconepciccone Posts: 660
    edited December 1969

    dtamm said:
    It sure sounds like a DzShape::getMaterial vs DzShape::getAssemblyMaterial thing.
    I don't use getMaterial() at all.


    Perhaps you should PM me how you are grabbing the materials and how you are getting the mesh and matching the material with each facegroup.


    I will, thank you.
  • pcicconepciccone Posts: 660
    edited January 2015

    BTW, the test on flags was done already. In fact, if I hide the grafted figure in Studio the main figure will have a hole and Reality renders it correctly, with all the polys hidden.

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