• Hi Guest!

    We are extremely excited to announce the release of our first Beta1.1 and the first release of our Public AddonKit!
    To participate in the Beta, a subscription to the Entertainer or Creator Tier is required. For access to the Public AddonKit you must be a Creator tier member. Once subscribed, download instructions can be found here.

    Click here for information and guides regarding the VaM2 beta. Join our Discord server for more announcements and community discussion about VaM2.
  • Hi Guest!

    VaM2 Resource Categories have now been added to the Hub! For information on posting VaM2 resources and details about VaM2 related changes to our Community Forums, please see our official announcement here.
Skin Vertex Link

Plugins + Scripts Skin Vertex Link

Download [<1 MB]
Stopper pointed the direction, and you brought it to completion.
Reducing the performance impact this much… it’s truly impressive.
The real-world usability is also very well aligned with user convenience. Really amazing work.
 
Stopper pointed the direction, and you brought it to completion.
Reducing the performance impact this much… it’s truly impressive.
The real-world usability is also very well aligned with user convenience. Really amazing work.
thanks!
 
This is incredible, thank you!

I am having an issue though. It seems to get confused when there are multiple clothing items with this plugin added as a Stopper clothing plugin. I'm trying to use this to manage three piercings (from Qdaro's pack), but when I add the third plugin instance, the second clothing item's CUA disappears. Reload the preset from the second item's ClothingPluginManager, and then the third CUA disappears....

Ah, okay, it seems to be because of the way this plugin is naming the CUA atom it spawns. It looks like the name is dependent on the person atom ID and the plugin index, but since you can have a separate plugin manager for each clothing item, you can have multiple plugin instances with the same index in their respective plugin managers. My first clothing item doesn't collide with the other two because its SkinVertexLink is plugin#3, but the other two are fighting for the plugin#2 slot.

Edit: I was able to work around it by adding blank plugin slots to the manager until I got to a unique index, assigning a SkinVertexLink to the unique slot, and then deleting the empty slots and re-saving the preset.
Just in case it's helpful: I took a look at Stopper's CUAClothing plugin and fixed the naming collision issue in a local copy of SkinVertexLink:
C#:
// ...

public class SkinVertexLink : MVRScript
{
    // ...
  
  
    // TODO: this could probably use some cleanup; _dazMesh, _dazDynamic, and
    // _dazSkinWrap all end up producing the same Atom UID
    private DAZClothingItem _dazClothingItem;
    private DAZHairGroup _dazHairGroup;
    private DAZMesh _dazMesh;
    private DAZDynamic _dazDynamic;
    private DAZSkinWrap _dazSkinWrap;
  
    // ...
  
    public override void Init()
    {
        try
        {
            CollectParentItems();
          
            // ...
          
            // CUA Asset selection
            cuaAtomUid = _dazDynamic != null
                // Clothing plugin -- use clothing item name for unique naming per instance
                ? $"{containingAtom.name}#{_dazDynamic.name}#{name}"
                // Person Atom plugin -- use storeId for unique naming per instance
                : $"{containingAtom.name}#SkinVertexLink#{storeId}";
              
            // ...
        }
        // ...
    }
  
    private void CollectParentItems()
    {
        var parent = gameObject;
        while (containingAtom == null || parent != containingAtom.gameObject)
        {
            if (parent.transform.parent == null)
                break;

            if (_dazClothingItem == null)
                _dazClothingItem = parent.GetComponent<DAZClothingItem>();

            if (_dazHairGroup == null)
                _dazHairGroup = parent.GetComponent<DAZHairGroup>();

            if (_dazMesh == null)
                _dazMesh = parent.GetComponent<DAZMesh>();

            if (_dazDynamic == null)
                _dazDynamic = parent.GetComponent<DAZDynamic>();

            if (_dazSkinWrap == null)
                _dazSkinWrap = parent.GetComponent<DAZSkinWrap>();

            containingAtom = parent.GetComponent<Atom>();
            parent = parent.transform.parent.gameObject;
        }
    }
  
    // ...
}

Edit: shit, nevermind, I just tried reloading a scene I had saved previously and the restore behavior seems pretty broken. I'll keep hacking at it.
Edit 2: fixed. I did a "cleanup" pass wherein I accidentally deleted the if (_dazDynamic == null) branch lol. Probably needs more testing though.
 
Last edited:
Edit: shit, nevermind, I just tried reloading a scene I had saved previously and the restore behavior seems pretty broken. I'll keep hacking at it.
Edit 2: fixed. I did a "cleanup" pass wherein I accidentally deleted the if (_dazDynamic == null) branch lol. Probably needs more testing though.
nice, i'm thinking the robust way to fix it is to spawn CUA atoms with random unique ID numbers, just like how it's done in Puppeteer plugin for its controllers. but im not sure its going the be backwards compatible anymore due that change
 
hmm good find, i'll check it out
Hi Skynet
Did you manage to resolve the issue from post #20 where multiple instances of clothing (eg Qdaro's piercings) cause some to disappear as they end up with duplicate atom reference names?
ie if adding an additional item after these two, the first one will be overwritten with the next instance
1775412506585.png
 
Hi Skynet
Did you manage to resolve the issue from post #20 where multiple instances of clothing (eg Qdaro's piercings) cause some to disappear as they end up with duplicate atom reference names?
ie if adding an additional item after these two, the first one will be overwritten with the next instance
View attachment 580636
to be honest i completely forgot about this lol
 
Hi again Skynet :)

Found another anomaly, though it's more for folks to be aware of if they set up cua clothing items and then find they behave weirdly on a different model.

There's quite a few body morphs circulating out there that have more than 21556 verts.
I suspect most of them have been created using an exported mesh from Vam, rather than using Daz G2

Here's an example of Sneaky One's mia, where the verts are misaligned and it places objects in the wrong position.
I resolved it by cleaning up the morph to remove the additional vert deltas
1775935986196.png
 
Hi again Skynet :)

Found another anomaly, though it's more for folks to be aware of if they set up cua clothing items and then find they behave weirdly on a different model.

There's quite a few body morphs circulating out there that have more than 21556 verts.
I suspect most of them have been created using an exported mesh from Vam, rather than using Daz G2

Here's an example of Sneaky One's mia, where the verts are misaligned and it places objects in the wrong position.
I resolved it by cleaning up the morph to remove the additional vert deltas
View attachment 582234
well that's kinda odd, how can a morph have deltas of non existing vertices? 🤔
 
well that's kinda odd, how can a morph have deltas of non existing vertices? 🤔
Exporting from Vam includes the gens graft as part of the base mesh - it ends up being 24,928 verts

You can create a morph in Daz for this as long as you use that vam exported obj instead of Base Gen2 when using morph loader pro within Daz.
Essentially, it stems from this guide:
https://hub.virtamate.com/resources/vam-to-blender-to-vam.3759/

Vam appears to just ignore the additional vert deltas

No idea how the above has ended up at 33k though. All I can assume is someone has grafted something else on somewhere, and its tagged it to the end of the deltas

As a slight aside, Chokaphi's Vam to Daz tool parses a morph and strips out any deltas after 21,556 when it creates the .dsf morph file to use in Daz as those extra's cause issues.
 
Last edited:
Back
Top Bottom