Character Transparency

Plugins Character Transparency

This issue was already in the initial plugin; I have no idea of how to fix it or if it's even fixable. So the answer is no, unless somebody can point towards a possible solution.
I had a little play with your code and a simple change of reading out the previous specular value of the material and only changing its alpha instead of setting the whole thing to RGBA=0,0,0,0 (is there a specific reason for this?) brought the specularity/gloss back. I also applied a little optimisation to avoid allocation of two Color objects.
This doesn't solve the tesselator problem, but one step at a time...

line 753ff:
material.SetFloat("_AlphaAdjust", t);
var color = material.GetColor("_Color");
color.a = 0;

material.SetColor("_Color", color);
color = material.GetColor("_SpecColor");
color.a = t;

material.SetColor("_SpecColor", color);
 
only changing its alpha instead of setting the whole thing to RGBA=0,0,0,0 (is there a specific reason for this?) brought the specularity/gloss back.
Thanks for looking into this! I'll try it out as soon as I have some time for VAM (rare commodity those days)

I don't know the reason of many things in this code, I built up on an existing plugin, very useful but quite wonky. I guess it was quickly made and never packaged; that can explain why some stuff are crude: there is certainly room for improvement but I'm no expert, so thanks for any help to make this better ;)
 
@HAL9001 please let us know if you crack the tessellation code on this! I can't use any plugins that remove tessellation as the models look so blocky. Thanks!
 
@cmramlow @ZRSX For now, I had a quick look at both, the code of ZRSX.Character_Transparency and HuntingSuccubus.AutomaticBodySmoother - and I don't think it's possible to fix their interference without actually creating a "merger" of the two scripts (which is not going to be a 5min job and would also require cooperation or permission from both authors).
Both plugins are doing effectively the same: when the script activates, it replaces the current shaders by specialised ones, one for adding Alpha (everything in lines 678ff with "SeparateAlpha" in it), the other for tesselating ("Custom/Subsurface/GlossNMTessMappedFixedComputeBuff"). Whoever runs last, "wins" and overwrites the shader of the first, and with it the desired feature.
You can actually try that by adding both scripts, and dis/enabling them in random order. Depending on which script was last, and when you (de)activate it, you get all sorts of combinations of wrongly applied/restored shaders.

The one question that needs to be clarified before even thinking of attempting a merger is whether there is an actual default shader that has tesselation AND alpha in one, e.g. "GlossNMTessMappedSeparateAlphaFixedComputeBuff" or "TransparentGlossNMTessMappedFixedComputeBuff" ... which doesn't seem to be the case from my tests just now.

For @cmramlow : There might be a workaround if you are OK with transparent bodies being non-tesselated because that won't be so apparent:
a) make sure the Tesselation script is first
b) the Transparency script is second and starts disabled and
c) when the body is about to become invisible, activate the Transparency plugin (which will turn off tesselation), do the fading, and
d) only once the body is totally visible again, deactivate the Tranparency script so the tesselation is back...
(in theory, though... I haven't tested that)
 
@HAL9001 Thank you for looking into this as deeply as you have. Unfortunately, my use case is hiding only certain parts like the hips and genital area to remedy clipping through some clothes in those areas and still have tessellation on all the non hidden parts, which is removed by this process :(
 
which is not going to be a 5min job and would also require cooperation or permission from both authors
If you ever decide to go for this, you've got my permission.
Even though you don't really it, as it's not really "my" plugin but rather a collaborative work already.
 
...as it's not really "my" plugin but rather a collaborative work already.
Yes I noticed when trawling the forums for other examples ;-)

Thinking of trying a version where you still have the sliders you have in your plugin, but the shaders are only replaced based on the alpha value > if there is no transparency, the old shader "stays"... (e.g. the tesselation shader)
 
@cmramlow @ZRSX Here's a first version you could have a look at and try, especially together with the Tesselation Smoother (worked for me so far). You can adjust the Alpha as well as the render queue index for every part (RQ currently only via editing the scene JSON file after a save). The RQ is quite nice to avoid "popping" of shadows or scalp parts.
Todo:
- Shortcut buttons/sliders for the body sections
- A toggle to switch the sliders between adjusting Transparency or RQ index (all visible at the same time would be overkill)
- Maybe also a toggle to show/hide body sections
 

Attachments

  • GoingGoingGone.cs
    13.4 KB · Views: 0
- A toggle to switch the sliders between adjusting Transparency or RQ index (all visible at the same time would be overkill)
Nice idea!

The plugin I built upon had Render Queue sliders, but I removed them for the sake of simplicity (ease of use and lighter UI).
Having a toggle would avoid those issues and bring back the control over the render queues. The only issue remaining is the number of triggers it adds...
 
@cmramlow @ZRSX Here's a first version you could have a look at and try, especially together with the Tesselation Smoother (worked for me so far). You can adjust the Alpha as well as the render queue index for every part (RQ currently only via editing the scene JSON file after a save). The RQ is quite nice to avoid "popping" of shadows or scalp parts.
Todo:
- Shortcut buttons/sliders for the body sections
- A toggle to switch the sliders between adjusting Transparency or RQ index (all visible at the same time would be overkill)
- Maybe also a toggle to show/hide body sections
Hey @HAL9001 you genius, I'll give it a try over next few days and let you know, thanks!
 
... The only issue remaining is the number of triggers it adds...
Is that a problem other than cluttering a selection dropdown-list? How often will you send render queue value changes ;-) There should be a way to a) hide or b) re-order them.

...it works mate, it works!!!! WOW, mind blown with how easy this works now, thank you very tremendously much dude!!
Sounds like it's time to find out how to make a Hub-Hosted .var then ;-)
 
Sounds like it's time to find out how to make a Hub-Hosted .var then ;-)
Way easier than figuring out how this plugin works! Here are some guides:
or if you prefer a video:
Video guide by JustLooking ForNothin

And then please read this to make clean packages:
TL;DR: build upon a clean VAM install and do not make a demo scene with unnecessary dependencies.


Is that a problem other than cluttering a selection dropdown-list?
None that I can think of, if it's clearly named. Adding more and more is just going to make the plugin (a tiny bit) harder to use on the trigger side.
That was one of the reasons I got rid of them. The main one was that it was a lot of work for me to transform the code so those values are saved with the scene and reapplied on scene load: I decided to make it work for the transparency first...

And that is one issue you should address before packaging.
I finally got the time to try out your version of the plugin. Great refactoring, looks way cleaner. But there is one major issue that was in the original plugin and the main reason I made my version: the transparency isn't kept anymore when reloading a saved scene. It goes full transparent on scene reload, not matter what your inputs were when saving the scene.
This is why I had painfully added the long list of UIDynamicSliders and Float, one by one. Surely there is a better way to do this but I don't know enough of C# for this. Once again, I tried to make it work first :p
 
Last edited:
Way easier than figuring out how this plugin works! Here are some guides:
Thanks, I've gone through them and got the clean var already (only two minor dependencies). Also found the way to have it Hub hosted - looks straightforward

...But there is one major issue that was in the original plugin and the main reason I made my version: the transparency isn't kept anymore when reloading a saved scene. It goes full transparent on scene reload...
Yes, I am aware of that and been working on this problem yesterday (also monitoring any skin changes which breaks any set values so far)
Got my todo list worked through so far
+ Shortcut buttons/sliders for the body sections > done
+ A toggle to switch the sliders between adjusting Transparency or RQ index > done
 
This plugin doesn't seem to work any longer. When loading the plugin, I get the following:

Code:
!> Something failed: System.NullReferenceException: Object reference not set to an instance of an object
  at ZRSX.CharacterTransparency+SkinHandler+<GetMaterialsToHide>c__AnonStorey0.<>m__0 (System.String materialToHide) [0x00000] in <filename unknown>:0
  at System.Linq.Enumerable.Any[String] (IEnumerable`1 source, System.Func`2 predicate) [0x00000] in <filename unknown>:0
  at ZRSX.CharacterTransparency+SkinHandler.GetMaterialsToHide (.DAZSkinV2 skin) [0x00000] in <filename unknown>:0
  at ZRSX.CharacterTransparency+SkinHandler.Configure (.DAZSkinV2 skin) [0x00000] in <filename unknown>:0
  at ZRSX.CharacterTransparency.ApplyAll (Boolean active) [0x00000] in <filename unknown>:0
  at ZRSX.CharacterTransparency.Update () [0x00000] in <filename unknown>:0

EDIT

Nevermind. Huh. I guess the "FEMALE DUMMY" conflicts with the plugin
 
Oh, interesting. I haven't tried on that model. Always good to get rid of NullPointerExceptions anyway. Will have a look into this. Thanks, @Saglinger.
No worries.
For what it's worth, I also noticed that the gums are permanently transparent with this plugin. You can adjust the opacity so that they're completely invisible, but you can't make them completely opaque.
 
D'uh, I just noticed that the crash described earlier isn't related to my own GoingGoingGone plugin, so I deleted my former comments.
However, @Saglinger, GoingGoingGone does not have the gum problem.
And related to the original crash problem: The Dummy Skin is special as it only uses one single material. That is such a special case that I am not sure it warrants the effort to add it to any plugin. It might be easier to create a custom skin with one simple white texture for all 4 body areas instead.

No worries.
For what it's worth, I also noticed that the gums are permanently transparent with this plugin. You can adjust the opacity so that they're completely invisible, but you can't make them completely opaque.
 
Hello,

Thanks for the plugin, it was the inspiration and enabler for an xray scene I uploaded recently. The end result works completely as I wish, but I'm wondering if there couldn't be a more effecient way to control individual parts.
In my scene for example, I fine-tuned the transparency of eye components to be less transparent than the rest. This however means I have a slider in the scene where I had to add every body part and input their values.
I was thinking it could be possible to instead have modifier values. So you'd set a global transparency, but could subtract or add to it for individual parts.
 
Hello,

Thanks for the plugin, it was the inspiration and enabler for an xray scene I uploaded recently. The end result works completely as I wish, but I'm wondering if there couldn't be a more effecient way to control individual parts.
In my scene for example, I fine-tuned the transparency of eye components to be less transparent than the rest. This however means I have a slider in the scene where I had to add every body part and input their values.
I was thinking it could be possible to instead have modifier values. So you'd set a global transparency, but could subtract or add to it for individual parts.
Hm, possible but a lot of effort. Here's an idea: the order of sending transparency values might be helpful. If you send a global transparency, yes, it overrides every slider, but if you then - one step later, or one block further down in the event list - send only the individually adjusted transparency values, that would in turn override the global one. I can't test that now, maybe you can?
PS: Also good to know somebody else is using my plugin ;-)
 
Hm, possible but a lot of effort. Here's an idea: the order of sending transparency values might be helpful. If you send a global transparency, yes, it overrides every slider, but if you then - one step later, or one block further down in the event list - send only the individually adjusted transparency values, that would in turn override the global one. I can't test that now, maybe you can?
PS: Also good to know somebody else is using my plugin ;-)

Yo. That actually works. I expected simultaneous application for all values in such a setup. This is good info in general for VAM. Thanks!
 
There is never such a thing as "in parallel" in computers, they always work sequentially. I have several scenes where I set a parameter to false and then immediately in the next event block back to true (or vice versa) to enforce a certain behaviour.
 
Today I came across a strange thing. when I turn on the plugin the character's eyes disappear, this has never happened before
 
Back
Top Bottom