Plugins + Scripts Skin Vertex Link

[Skynet]

Skynet updated Skin Vertex Link with a new update entry:

update v5

-- Minor fix:
- Visuals should render through the body without requiring post magic plugin

Read the rest of this update entry...

 

[bqbq]

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.

 

[Skynet]

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!

 

[faaipdeoiad]

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:

// ...

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.

 

[Skynet]

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

 

[MrGiggly]

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

 

[Skynet]

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

 

[MrGiggly]

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

 

[Skynet]

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?

 

[MrGiggly]

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.

 

[Foost]

This was bugging me for ages. Quite often while editing my scenes with this plugin enabled, the performance went all the way to hell. Got me a while to figure it out. The plugin handles global keyboard shortcuts even while its UI is not enabled. And all instances of the plugin do it. And one of the bindings is Shift+T. So typing anywhere ends up triggering the mouse selection mode sooner or later. With multiple piercings on the girl that drops VAM to unusable framerate.

Shift+T as a binging is not really a good idea. But in general, I don't see much point why it would even process the keybinds while the plugin's settings UI is not open? Or alternatively, why the selection/visualization should be enabled if the UI is not on. Btw you can check if the plugin's UI is on by UITransform.gameObject.activeInHierarchy on the script object.

 

[Skynet]

This was bugging me for ages. Quite often while editing my scenes with this plugin enabled, the performance went all the way to hell. Got me a while to figure it out. The plugin handles global keyboard shortcuts even while its UI is not enabled. And all instances of the plugin do it. And one of the bindings is Shift+T. So typing anywhere ends up triggering the mouse selection mode sooner or later. With multiple piercings on the girl that drops VAM to unusable framerate.

Shift+T as a binging is not really a good idea. But in general, I don't see much point why it would even process the keybinds while the plugin's settings UI is not open? Or alternatively, why the selection/visualization should be enabled if the UI is not on. Btw you can check if the plugin's UI is on by UITransform.gameObject.activeInHierarchy on the script object.

for sure bro, i'm already aware of that. the Shift +T keybind was an eyeballed key-bind nonetheless, how would i know that somebody presses Shift + T on a regular basis? seems unlikely to me but thanks for the feedback

 

[Skynet]

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.

hmm perhaps morphs made for victoria 5 instead of base female? i really can't tell where that might stem from

 

[Foost]

for sure bro, i'm already aware of that. the Shift +T keybind was an eyeballed key-bind nonetheless, how would i know that somebody presses Shift + T on a regular basis? seems unlikely to me but thanks for the feedback

It captures Shift+T even while typing in any VAM's input fields (naming files, filtering morphs, searching for clothes, anything), that's how. Shift alone is never a good modifier to use. But it makes very little sense to have such global keybind no matter what. Only the Alt+V kind-of makes sense to work while not editing specific item's settings.

 

[Skynet]

It captures Shift+T even while typing in any VAM's input fields (naming files, filtering morphs, searching for clothes, anything), that's how. Shift alone is never a good modifier to use. But it makes very little sense to have such global keybind no matter what. Only the Alt+V kind-of makes sense to work while not editing specific item's settings.

sure thing, i'm used to writing upper case by toggling caps lock key. didn't think shift key was the usual for that but anyhow, it's probably better to just offer custom input fields so anyone can set up their own custom keybinds that won't conflict with anything else they have.