Plugins + Scripts SexyFluids

Changes Overview​

• Implemented penetration monitoring for penis, similar to DildoLanguage v12.f2.
• Exposed penetration state through storables and triggers.
• Basic behavior based on penetration - do not emit cum fluids while the penis is penetrating.
• Changed all emitters (penis, squirt, nipples) to be positioned relatively to the person's visual skin, instead of using rigidbodies or colliders. You might have to tweak positions of your colliders, especially nipples, where the base position is now much more precise.
• Emitted fluid particles can now have all collisions turned off until they travel certain distance away from the emitter. No more pesky collision with protruding nipple colliders. Squirt no longer has to emit from outside the vagina to prevent collisions.
• Updated all presets accordingly.
• Rendering of gizmos and debugging features has been rewritten to be more efficient, and use more consistent line-based visuals.

Skin Tracking​

Internally, the largest change is the ability of the plugin to track exact positions of the character's visual geometry on the CPU. This includes poses and morphs (but not softbody physics).
This tech is used to:

• Track the visual shape of the penis, compute its intersection with vagina/anus/mouth orifices (aka penetration monitoring).
• Track preconfigured parts of the skin and position the fluid emitters relatively to them, no longer relying on rigidbodies or colliders.

Penetration Monitor

If you also use DildoLanguage, you might be already familiar with this feature, it's been added to DL in update v12. The plugin tracks the visual shape and position of the penis and computes its penetration with all person atom orifices ; the targets do not need to have SexyFluids enabled on them. The penetration parameters are exposed to scene creators as Storables and also as Triggers. You can check them on the new Penetration tab. The Info tab shows the names of the exported storables, as well as their current values:

• OrificeId: 0 = none, 1 = anus, 2 = vagina, 3 = mouth
• Depth is in centimeters
• Girth is also in centimeters. If the value looks too large, that's because it's the girth circumference, not radius or diameter.
• Speed in in centimeters per second.
• So is the Strength, although it's better to think of it as a unitless value. It's derived from weighted running average of recent positive (push) speeds. It does not take the girth into account.
• For penis tracking, there is no difference between atom/orifice and target atom/orifice, that's used by DildoLanguage where a dildo can have manual orifice target selected and be attracted to it. There are already enough addons that implement such feature for penis, so I decided to not include the DildoLanguage's manual target and smart forces here.

For information about setting up the triggers, please refer to DildoLanguage v12.f2 update notes .

On the Debug tab, you can enable the visualization of the penetration or the orifices. The image on the right shows the penis shape visualization in green/blue, and the penetration girth visualization in white.

Internally, the penetration monitoring it not used for any big features yet. The Penis has a new Behavior tab, where you can configure it to not emit cum particles while penetrating. It usually does not look good, with the fluid particles just randomly finding their way through the penetrated atom's colliders. By default it's set to disable cum fluids when the penetration is 1cm or more. Set it to 0 to disable this feature.

But for now the monitoring is mostly aimed at scene creators. Use the values to drive morphs, expressions, sounds or anything else you want. The DildoLanguage v12 update has a video attached, showing a light driven by penetration depth value, and squirt triggered at certain depths.

Skin-based Emitters

All fluid emitters are now attached to the person's skin, rather than their rigidbodies or colliders. This makes their position much more precise, also they should stick to the skin, update with morphs, and not lag behind the person visual geometry's motion. While on the Burst Shape tab, the yellow outline shows the body polygons tracked to place the emitter.

For example, the nipple emitters should now be always positioned correctly, no matter what morphs are used. Even on males ; or more importantly, legacy futas. Those have no nipple colliders, so the position was rather approximate before and needed manual tuning matching the used morphs.

This means the emitter positions are slightly different from the previous version. So if updating an existing scene, you might have to tweak the offsets or rotations in Burst Shape. There is a chance you had to fiddle with those to position the emitter where you wanted it to be, now it should not be as necessary.

A feature closely related to this is the Do not Collide Near Emitter advanced option. Because the emitters now stick to the skin, they might be obscured by VAM's colliders. This option runs initial few ticks of the simulation with collisions turned off, otherwise the fluids particles would collide immediately. In general, you should not have to pay attention to this, it's configured for all existing emitters in a way that should make sense.

The overview post has been updated to match features of v5.f2. Many tweaks all over the place, the more significant changes are:

• Added description of Burst Values Curves to the "how does it all work" part
• Separated Forces Settings from the Orgasm Settings, just like in the UI. And updated the information with the new forces features

Added slider to various forces that changes the behavior from applying the value as a force to directly rotating the emitter instead.

For example, for the penis orgasm and the Left-Right force, if set the Use Side Force to Rotate Emitter slider all the way to 1.0, instead of applying a sideways force to the penis' tip, the cum will just shoot sideways. Values between 0 and 1 will combine forces and emitter rotation at given ratio.

This can be useful if you want to randomize the "shooting direction". When using only forces, the first few particles will always shoot directly forwards since it takes a while for the force to actually move the tip.

As usual, updated all defaults and presets to use this effect to some degree, and to overall improve their look.

Here is a video demonstrating the forces settings, using AltFuta penis and the sideways forces as an example. But it also works in a similar fashion for the tip (upwards) forces, for both nipple forces, and for squirt pelvis force. Squirt sideways "force" always rotates the emitter directly. And the orgasm pelvis force is always used as a force.

Spoiler: Forces Tutorial

Nasty hack to hopefully fix remaining Eosin's VRRenderer's issues:​

• Because the VRRenderer plugin breaks fluid renderer's command buffers on its cameras every frame, the fluids plugin will now verify that its command buffers are activated where they should be, and go around and fix things if they are not.
• Hopefully this will always run after VRRenderer breaks stuff and before the camera is actually rendered.
• The Use Command Buffer Effects toggle is no longer necessary, since fluids will reinstall their buffers if they get deleted anyway. But it won't hurt to have it enabled - my plugin will also remove fluid command buffers installed by VRRenderer where they should not be.
• Did I mention I dislike how it mucks with command buffers on cameras? I probably did too many times already.

Or short version:

• Correct fluid command buffers will run on VRRenderer cameras after this fix. Instead of none at all or the main camera's buffers.

I am not too happy with this workaround. But other than modifying the VRRenderer directly I see no other options. Hopefully this hacky fix won't break something else.

Other fixes:​

• Fixed squirt UI for AltFuta person atoms
• Fixed SexyFluids UI not refreshing correctly when switching person atom types with the plugin already installed.

Just a quick hotfix to v2.f2:

• Changed the default Velocity Attack-Decay Ratio for the penis emitter from 0.1 to 0.0
• Updated bundled presets Cum Default and Cum High Load to use zero Attack Ratio

I really did not like how the slower initial particles changed the look. I might tweak the base nipple presets in a similar fashion in the future. Let me know if you dislike how the default looks.

Force Updates​

• Moved forces configuration to separate tab in the UI
• Changed Decay behavior for all relevant values (velocity, particle rate, forces):
  • Before it was a simple max-to-min linear decay. The update changes it to a attack-decay curve. This can be used to produce smoother and more pleasing effects.
  • The new Attack slider configures how fast the value transitions from zero to max. Then it decays to the Decay fraction.
  • In case of velocity, the starting value is the Decay-To fraction rather than zero.
  • Both parts of the attack-decay curve are non-linear.
  • If you do not want use the attack part, set the Attack slider to zero.
  • This can be seen in the sample Milk Long Burst preset, the velocity reaches the maximum value smoothly, and then decays to lower value.
• Added Left-to-Right sideways force settings for all emitters, with its own min/max random ranges:
  • With this addition, fluids will no longer shoot in the same forwards direction, but smoothly and randomly swerve to a side.
  • Set Left-Right Force minimum and maximum to zero to disable the effect.
  • The emitter will start in the forward direction, then be pushed to reach the maximum sideways force at Side Force Attack-Decay Ratio time of the burst. Stay there for Hold. Then shift back to forward direction. As usual, these values are specified as fractions of the burst duration, rather than in seconds.
  • If you want the forward direction to be simply randomized sideways, with no ease in-hold-ease out curve, set the Attack-Decay Ratio values to zero, and the Hold value to one.
• Enabled up/down and side-to-side forces for nipple emitters, so the boobs can now be pushed a bit when emitting fluids. By default with very small and gentle values.
• Updated all bundled presets to use the new features.
  • PLEASE reload or update your nipple presets, since the previous ones had way too large forces saved in them (the emitter did not use the value in the previous version).
  • Added new Milk Long Burst preset with more obvious particle velocity attack-decay curve.

Other Updates​

• Enabled squirt emitter for AltFutas.
• Changed the look of the tabbed UI to distinguish tabs from normal buttons

Fixes​

• Fixed cumstain broken behavior when attached to colliders that have very large or very low scale. This included some of the builtin toys, for example the buttplug.
• Fixed one-frame flash when the fluid compositor is added to the scene.
• Fixed most issues with high-resolution screenshot and video taking plugins. See below for additional info about Eosin's VRRenderer.
  • The fluid renderer has some significant internal changes to fix the high-resolution screenshot/video plugin support, and the internal interface has been updated to a new version. If you use SexyFluids and DildoLanguage in your sccene, make sure to update both to the .f2 version.

VRRenderer Notes

Most bugs associated with the Eosin's plugin have been fixed, but the situation is still not ideal, and perhaps will never be.

First, things still break if the scene has both the Eosin's VRRenderer plugin and VAM's WindowCamera enabled. Disable the WindowCamera's preview to fix this issue. I am not yet sure what is causing this.

Update: I just noticed that at least in my testing scene, the VRRenderer breaks when I enable the WindowCamera preview even without any of my fluid plugins being present. It looks like a VRRenderer bug that happens if the scene has WindowCamera preview enabled and any VAM reflective surfaces.

Second, the VRRenderer does really weird things with camera Command Buffers - by default, it just kills them all. And the fluid renderer runs all its effect as camera Command Buffers. To somewhat fix this, make sure the Use Command Buffer Effects toggle is turned on. Otherwise you won't see any of the fluids in VRRenderer's renders (only in reflective surfaces).

But it still won't be perfect. With the toggle being checked, the VRRenderer will still remove the Command Buffers created by my fluids, then copy over Command Buffers from the main camera. This is not ideal, since the fluid shaders use different settings depending on the render resolution. So when you use the VRRender for high-resolution renders, these will use slightly wrong fluid settings. They will still look mostly fine, so it can probably be ignored. And I can't fix it anyway, the only solution is adding an option to VRRenderer to simply do nothing with camera Command Buffers.