Assets + Accessories DildoLanguage

This is mostly just a technical update, synchronizing code shared with SexyFluids. No big new features, just smaller tweaks to the shared systems implemented while working on SexyFluids v6:

• Tweaks and improvements to penetration monitoring. The biggest difference is that the "maximum speed" storable/trigger should make more sense now, it was evaluated wrong before.
• Fluid particles can have collisions disabled until they get far enough from the emitter. This is available on the Advanced tab, and set to 0.5cm for all dildos by default.
• New debugging visualization for forces, transform axes, dildo shape, penetration girth, or person orifices.
• No more spam about re-creating fluid resources in scenes with mirror surfaces that are not visible at all time.

Changes overview​

• Reworked penetration monitoring, precise girth circumference estimation based on visual geometry
• Exposed penetration state through storables and triggers
• Reworked custom scaling to fix child bones of scaled parts being affected if connected at an angle
• Do not emit cum fluids while the dildo is penetrating
• Added information about the penetration monitor to the demo scene - the Movement chapter, starting right after the fluids demonstration at page 24/50.

Scaling​

In the old implementation, scaling of parent bones would affect direction of child bones if they were attached at an angle. The reworked implementation fixes this problem. This was visible mostly when changing the base girth of the squid tentacle dildo.

Penetration Monitor

Dildos already monitored penetration in order to support the smart forces logic. The penetration monitoring has been rewritten to be more correct and evaluate more penetration parameters:

• The tracking of position and shape of target orifices is more precise.
• Added tracking of penetration girth. This is not based on physics, but evaluates the intersection of the (simplified) visual geometry of the dildo with the penetrated orifice. Therefore it matches the shape of the penetrating part of the dildo exactly (within reason). The attached picture show the debug view of the girth shape, this can be enabled on the Debug tab.
• Added tracking of penetration speed (recent and maximum push speed in last second), as well as "penetration strength" based on the push speeds in the last second.

The tracked parameters do not do much yet. Internally, they are used only to stop emitting cum fluids while a cumming dildo penetrates any orifice (configurable in the new Behavior tab of the Fluids module). Before the fluids would either stay inside, not visible and just wasting resources; or worse, leak through the body colliders in random places.

The penetration parameters are exposed though storables and triggers. Feel free to use them in your scene to drive morphs, expressions, sounds, lights, whatever you want.

Penetration Storables​

The available penetration storables, as well as their current values, can be seen on the Info tab of the new Penetration module.

• 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.
• The difference between atom/orifice and target atom/orifice is:
  • If the Manual Orifice Target toggle is enabled on the Movement-Direction page:
    The target is simply the manually selected target. The penetrated atom/orifice is the same as the target if penetrating the target, and not set otherwise.
  • If the Manual Orifice Target toggle is disabled:
    The penetrated atom/orifice is the currently penetrated orifice. The target will be the same while penetrating, and also stay at that value for a while if the Remember the target options are set and active ; i.e. penetrated recently and/or the tip is still close enough to the recently penetrated orifice.
  • Also, the target values define at which orifice will the Smart Target Forces aim the dildo, if enabled.

Penetration Triggers

Any number of penetration triggers can be defined for a dildo. Each trigger can be either a Value Trigger or a Threshold Trigger. Both types track specified value (such as depth or girth). Both types support optional conditions for penetrated atom and orifice:

• If a condition is not set (set to None), or matches the currently penetrated target, the value will be used as is.
• If any of the configured conditions do not match, the used value will be effectively zero.

Value Triggers​

These simply track the selected value, and pass it to all transition actions configured by the On Value Changed button.
VAM strictly restricts the range of value triggers, so you will have to configure the input range. The actual tracked value will be restricted into this range, then expanded to the Start/End range configured in each of the On Value Changed actions.

Threshold Triggers​

These will fire all discrete actions configured by the On Actived button when the selected value gets higher than (or equal to) the the Activate If Above value.
If later the value drops below the Deactivate If Below value, the On Deactivated actions will be fired.
Note that if the optional conditions are not satisfied, the input value is effectively zero.

To simplify setting up the triggers, the selected value used to drive the trigger is displayed in the UI.

Demo Scene​

Check the bundled tutorial scene, a trigger example has been added to the Motion chapter, starting right after the fluids demonstration.

This video show a very similar example:

• The red light's intensity is driven by the penetration depth (Value Trigger).
• A depth Threshold Trigger is used to emit SexyFluid squirt burst.

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

This is the same fluids change as SexyFluids v5.f2. Please check the SexyFluids update notes, including the attached forces tutorial video.

Another fluids workaround for the VRRenderer plugin.
Same as the SexyFluids v4.f2 update. Check the SexyFluids update notes for details.

Fluids update matching SexyFluids v3.f2. See the SexyFluids update notes for details.

• Improved attack-decay curve for variables that change during burst - velocity, particle rate, forces.
• Moved forces to separate tab. Added randomized sideways force.
• Fixed (maybe) interaction with plugins used to capture hi-res screenshot and video.
• Updated bundled presets, as usual.
• Tabbed UI tweaks.

In addition to that, the behavior of the DildoLanguage-only slider Reduce Spring Strength During Burst has been fixed. It did not decay properly and the override usually ended up way too early.

Spoiler: Sideways Force Demonstration

It can be used to avoid the cumstains from being all overlaid on top of each other in the same strip if the emitter has no other motion.

Updates to fluids, preparing them for standalone release!

• Major tweaks and fixes of Drip particles behavior with low emit rate:
  • The produced amount should now be more correct. The drip won't suddenly stop producing particles when the emit rate is too low.
  • Fixed pre-positioning of spawned particles pushing low-frequency drops downwards way too much.
  • Added randomization to the frequency and occasional short bust to the frequency if the rate is very low, to make the drip look more natural.
• Changed fluid particle emitter origin positioning. It's not pushed forward as much as before if the Spray or Stream particles are large. You might have to tweak your Back/Forward offset to accommodate.
• Added separate Back/Forward offset for Drip particles to Burst Shape.
• Added Left/Right offset to Burst Shape.
• Added Gravity multiplier to the Advanced tab.
• Added Rendering Depth Offset to the Advanced tab.
• Tweaked many of the bundled presets, again.

Q: What the heck does the "f1" mean?
A: This is the "fluids module compatibility version". If you use DildoLanguage and other plugins using my fluids module in the same scene, both should have the same f-number, or they won't be able to cooperate correctly.

Cum Fluids Updates​

This version's focus is on several different aspect of the "flying cum" visual effect:

• Implemented alternative mode of Stream particles rendering. Instead of drawing individual fluid particles, a curve is projected through the particles.
  • Controlled by slider Join Stream Particles on the Burst Shape tab.
  • Set it to zero to disable the effect.
  • New default value is non-zero. This will affect your existing scenes, if you do not want the particles to be joined, please set this value to zero.
  • Works best when the amount of Stream particles is relatively low and the Spread Angle is not too high. Otherwise you will end up with high-frequency zigzagging curve.
• Added options to emit Secondary Bursts.
  • If enabled, they will be generated in random directions relative within specified maximal cone angle.
  • The amount, length and velocity can be randomized.
  • By default each Burst will use different random values. This can be changed to randomize the values only once for all Burst in Orgasm, or to never change the randomization and use user-specified seed.
• Added Drip particles.
  • These are simple particles that use the Spray visuals (with few optional tweak sliders), emitted at the tip at zero velocity.
  • They build up during each burst.
  • If the Emit Rate is lower than the Buildup Ratio, the particles will continue dripping for some time after each burst.
• Added UI tab for Burst Shape.
  • This is where the new Join Stream Particles slider hides.
  • Added tweak sliders to move and rotate the Spray/Stream emitter. Simple axis visual is turned on while on this tab, the blue line is the direction in which the particles will be emitted.
  • Few general sliders have been moved from the Stream/Spray tabs into Burst Shape (Spray-Stream Ratio, Stream and Spray Spread Angles).
• Updated JSONStorables used to control fluids
  • Added new float storables: "fluids:loadOverride", "fluids:speedMultiplier", "fluids:forceMultiplier".
  • Set these before starting the burst/sequence to tweak its properties.
  • Starting the emitter will reset these values to defaults - they apply only to the next start/burst, which must happen within few frames.
  • Some removing and renaming happened, see breaking changes below.
• Reduced the time it takes to generate cumstains from Stream particle contacts. This can be further tweaked on the Advanced tab. Be aware that setting the delay values too low will result in the generated cumtains breaking up into more smaller ones.
• Added option to slow down or speed up the particle simulation speed to the Advanced tab.
• Many tweaks to the particle emitter. In general, it should spread the particles more evenly and less in weirdly packed groups.
• Recreated all presets bundled with the plugin, added two more presets to show off the new features.
• Internal refactor of the fluids code, making it almost completely independent on the DildoLanguage codebase. For mysterious reasons!

Breaking changes

• As mentioned above, the defaults have been changed again. Most visible one is the new Join Stream Particles slider. So you might have to tweak your scene's settings.
• Few triggers have been renamed. "fluids:startOrgasm" is now "fluids:start" and "fluids:cleanCumstains" is "fluids:clean".
• "fluids:burstNoPhysics" is gone. Instead set "fluids:forceMultiplier" before calling "fluids:burst".

​

Spoiler: Stream particles joined by a curve, and Drip particles

​

Spoiler: Secondary Bursts

Second fluids tech update.

Cumstains sticking to skin​

TL;DR version: generated cumstains now stick to person atom's skins even during movement, while performance should be better than before.

This is the core feature of this update. In previous versions, the initial position of the generated cumstains was correctly placed onto the atom's skin. But then the cumstains attached to a nearby person collider, which could result in the position going all wrong with significant pose changes or movement. It would look like this:

Spoiler: Old version - cumstains attached to colliders

With this change, the cumstains stick to the skin's geometry even when the pose changes or the character animates. Moreover, since this new version is implemented as a compute shader and runs fully on the GPU, it should perform better than the old version in most cases (since VAM is usually bottlenecked by CPU, not GPU).

Spoiler: New version - cumstains attached to skin geometry

If you want to, you can switch to the old behavior on the Fluids-Advanced options tab. You can also turn off the compute shader implementation there, then the effect should be the same but run on the CPU instead. These options exist mostly for testing, you'll probably never want to change either of them.

Fluid resolution​

TL;DR version: fluids now render at 100% framebuffer resolution, while it was 50% before. So the rendering will be a bit slower, but it should look better. There is an option to set it back to 50% and it won't change how the lighting looks anymore (as much as it would before).

The second large change in this update is mostly internal. Large chunks of the fluid processing shaders were rewritten, mostly because I realized that the blur pass was not resolution-independent - the normals, and therefore lighting, could end up looking different depending on the rendering resolution.

The rewrite to make the blur pass resolution-independent (within reason) made it perform slightly slower, but I ended up optimizing several aspects of the renderer, so overall

it should be a bit faster than before, especially at resolutions below 4k.

Therefor, as an experiment, I also bumped the internal resolution of the fluid processing buffers. In older versions the fluids were rendered at half of the screen resolution, now the default is to render them at the full resolution.

Please let me know if you feel like this change impacts your performance negatively while not providing enough visual improvements.
After all, all parts of the fluid renderer now have to process 4x more pixels.

There is an option to change the resolution back. But it must be performed on the dildo that's actually responsible for rendering the fluids! For that reason I also added an option to force one of the plugin instances to be the renderer. These options are available on the Fluids-Advanced tab. To change the rendering resolution:

• On your chosen dildo, enable the "Always Make this the Compositor" option. This will ensure that the options below it will actually apply.
• Change the "Resolution Divider" to 2 to change the fluid renderer to run at half of the screen resolution.
• You can safely ignore all other advanced options.
• Do not try to force multiple dildos to be the fluid renderer. They'd end up fighting over the fluid processing textures, causing a mess.

Fluid Presets​

Because of the various changes to the renderer, all fluid presets shipping with the plugin have been updated. The cum fluid settings (except for the "monster" one) should be a bit more tame and reasonable, looking more real-like. They were intentionally too large before, because it partially hid the issues with the cumstains not sticking to the skin.

As a side-effect, several defaults also got updated to match the default cum effect. This means that your own presets and scenes might end up with slightly different settings when upgrading to version 6 and above.

Other Improvements​

• Fixed a small bug in cumstain visibility over its lifetime, improved how fast they appear on the skin.
• Improved handling of cumstains when a person's skin is changed, the old generated cumstains now get removed instead of being stuck in space.
• Fluids UI tweaks. Changed ranges on some settings, more of them can be set outside of the default range, particle sizes are now in centimeters (just in the UI, your presets are safe), etc.
• Internal changes to the cross-plugin interface, used by the shared renderer logic. This makes v6 incompatible with all versions before. But it should not be a big deal since you should never mix different DildoLanguage versions in one scene anyway; Unity/VAM kinda breaks when the same CUA bundle names are addressed from different VAR packages.

Fixed infinite loop (leading to VAM freeze) in fluid deregistration when deleting a dildo from scene.

First tech update of the Fluids module.

Shared Fluids Renderer​

If a scene has multiple instances of the DildoLanguage plugin, they will communicate with each other and decide on one plugin instance that is responsible for the post-processing and compositing aspect of fluids.

For scenes with one dildo emitting fluids, there should be no difference.

Scenes with multiple dildos should:

• Consume less GPU memory
• Perform faster
• If the fluids emitted from different dildos overlap, the visuals will be slightly different. Instead of overlapping on top of each other in random order, they will now mix together since they are all rendered in one post-processing pass.

The video below shows the difference. With each dildo rendering the whole effect on its own, the green fluid overlaps the blue one. It can be quite random which one ends up on top. With rendering shared, the two fluids mix together.

Spoiler: Shared Renderer differences

Details for Nerds​

The fluid rendering consists of two major parts:

1. First the various properties of the particles are rendered into off-screen buffers
2. Then the buffers are processed and composited on top of the scene

In the initial release, each dildo performed both steps on its own. Each dildo allocated its own render target textures. Each rendered the fluid particles into those textures. Then, for each camera, every dildo processed the data and composited the result into the main scene, overlapping the previously composited fluids.

With this change, only one dildo will be elected as the compositor. Only this dildo will allocate the render target textures, saving GPU memory. All dildos will render into the same textures. Then the compositor dildo will post-process the results and draw them onto the screen. The post-processing can be quite expensive, so this should speed up the rendering, although it might not really be noticeable on modern GPUs.

Additional changes​

• Added Edge Thickness Factor to Cumstain settings. At zero value (default), it will behave as before, and the Thickness (alpha, more or less) of a cumstain will fade from the middle to the edge. At one, the Thickness will stay constant, making the outline of the cumstains more defined.
• Updated all presets (except for the water one) to use slightly above-zero Edge Thickness Factor, the cumstains look a bit better that way. If you used the presets, reload them or experiment with the value on your own.
• Added Advanced tab to Fluids settings. It can be safely ignored, it's useful mostly for testing and debugging. You can see which dildo is responsible for compositing the fluids, or disable sharing of the renderer for this dildo.
• Fixed bug where the fluid render texture resolution would not get updated when the camera's resolution changed.