Plugins + Scripts SexyFluids

[kim05]

The fluids should collide with standard Unity colliders (so far, I'd like to change that at some point). Only then the cumstains are attached to the "closest" skin point, which does not always work very well for mouth/tongue. But they should not fall through like this.

Do you have all colliders enabled normally, no weird ColliderEditor changes?

Or did you maybe tweak the "Do not Collide Near Emitter" Advanced setting? It exists there to prevent collisions with the emitter (especially important for squirt). Maybe the tongue/mouth is still ignored by this setting, try reducing the value for the penis emitter. Although now I see in the vid the Advanced tab appears briefly and it's set to 0.5cm, so that should be fine. Maybe try setting it zero to check if there might be a bug with that logic. Iit's kinda hacky since you really can't run on/off collisions of individual Unity particles, which is why I ultimately want to write my own more fluid-like sim instead of partially using Unity's particle system. But that won't happen this year.

And if that does not help, can you share the scene with me to test what's happening?
View attachment 523555

I did not edit female collider until today, when I tried enlarging the tongue colliders, which helped a little (I am really not sure, as it works sometimes and then suddenly refuses to work at all and starts falling through).
I did not adjust "Do not collide near", but reducing it does not affect the success rate. Frankly I can't really tell what could be the problem even in theory
Scene files attached.

 

[Foost]

I did not edit female collider until today, when I tried enlarging the tongue colliders, which helped a little (I am really not sure, as it works sometimes and then suddenly refuses to work at all and starts falling through).
I did not adjust "Do not collide near", but reducing it does not affect the success rate. Frankly I can't really tell what could be the problem even in theory
Scene files attached.

That took me a while to figure out, but I am afraid I have bad news for you. It does not work because you have the VaM's teeth and tongue turned off, replaced by a clothing item. The fluids don't work on cloth. It's one of my long term goals to make them work on (manually selected) clothing items, but that's a VERY long term goal. It won't work any time soon.

Tbh even without that trying to stick the fluids to the tongue is a bit wonky, but that won't be much better until I implement GPU-based direct collision with the skin (if that ever happens, that will be super complicated to get right, but it's a plan)

 

[kim05]

That took me a while to figure out, but I am afraid I have bad news for you. It does not work because you have the VaM's teeth and tongue turned off, replaced by a clothing item. The fluids don't work on cloth. It's one of my long term goals to make them work on (manually selected) clothing items, but that's a VERY long term goal. It won't work any time soon.

Tbh even without that trying to stick the fluids to the tongue is a bit wonky, but that won't be much better until I implement GPU-based direct collision with the skin (if that ever happens, that will be super complicated to get right, but it's a plan)

ffs I really should have known... seems so obvious now that you said it.

 

[faaipdeoiad]

That took me a while to figure out, but I am afraid I have bad news for you. It does not work because you have the VaM's teeth and tongue turned off, replaced by a clothing item. The fluids don't work on cloth. It's one of my long term goals to make them work on (manually selected) clothing items, but that's a VERY long term goal. It won't work any time soon.

I had Jackaroo's Teeth/Tongue/Gums in the video I posted earlier too. Setting the native tongue/teeth to not render the materials doesn't turn the skinned meshes off, it just makes them invisible (the clothing teeth/tongue are wrapped to those vertices, after all).

If you turn on "wrap to smoothed vertices" in the clothing assets and play with the surface offset/thickness, it might help them follow the low-poly meshes a little more closely, which would help with the sticking.

But... I've been finding recently that sometimes the collision has issues if the would-be collision target is affected by morphs that are animated in Timeline. But the problem is with the Particle System's collision detection, not your sticking logic. If I debug draw the collision points in 3D space, they show up fine for a static model but start passing straight through some to most of the time when there are animated morphs happening. The more morphs you're animating, the more it seems to happen. I'm not really sure what's happening there, because most of the colliders are attached to skeletal joints, not the mesh itself, so I wouldn't think they'd be affected by morph targets. But ironically, skeletal animation seems to be fine while morph animations cause problems. Maybe it's a frame budgeting thing? Unity is kind of a black box, so... who knows.

 

[faaipdeoiad]

Unrelated: I'm testing a new scene idea that uses a custom Unity environment with lots of baked lights in the background and a few mixed lights in the foreground. It's working really well, because the runtime shadows blend right in with the scene bake. But currently SF is ignoring any lights that aren't set to realtime.

I made this small modification in `LightManager.cs` if you're up for adopting it into the next release. Doesn't seem to be any down side, but there could be something I'm not thinking about.

// Line 105
if ((l == null) || (! l.isActiveAndEnabled) || (! l.gameObject.activeInHierarchy) || (l.bakingOutput.lightmapBakeType == LightmapBakeType.Baked)) {
    info.priority = 0.0f;
}

Here are some before and after screenshots (and a shameless show-off of the scene lighting).

 

[Foost]

Unrelated: I'm testing a new scene idea that uses a custom Unity environment with lots of baked lights in the background and a few mixed lights in the foreground. It's working really well, because the runtime shadows blend right in with the scene bake. But currently SF is ignoring any lights that aren't set to realtime.

I made this small modification in `LightManager.cs` if you're up for adopting it into the next release. Doesn't seem to be any down side, but there could be something I'm not thinking about.

// Line 105
if ((l == null) || (! l.isActiveAndEnabled) || (! l.gameObject.activeInHierarchy) || (l.bakingOutput.lightmapBakeType == LightmapBakeType.Baked)) {
    info.priority = 0.0f;
}

Here are some before and after screenshots (and a shameless show-off of the scene lighting).

View attachment 528173
View attachment 528174

Good point, thanks . I will fix that when I get back to fluids.

Looks pretty! <3

 

[TheGamer0069]

Is there a way to implement sound effects to the plugin?

 

[Foost]

Is there a way to implement sound effects to the plugin?

I definitely have no plans to add any kind of sounds directly into the plugin. I could add triggers to more events where you might hook whatever else you want to generate sounds. The only triggers now are for the penetration monitor - speed, girth, depth, "strength" - you could already use those to script penetration sounds. Which is probably not what you are asking for. But sounds for what exactly? Cum really does not make any.

 

[SlimerJSpud]

Whatever is being used to trigger the fluids could also trigger specific sounds using the SoundsFromAssetbundle plugin. If Timeline is being used to trigger fluids, it could also trigger sounds.