Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature currently requires accessing the site using the built-in Safari browser.
Hi Guest!
We are extremely excited to announce the release of our first Beta1.1 and the first release of our Public AddonKit! To participate in the Beta, a subscription to the Entertainer or Creator Tier is required. For access to the Public AddonKit you must be a Creator tier member. Once subscribed, download instructions can be found here.
Click here for information and guides regarding the VaM2 beta. Join our Discord server for more announcements and community discussion about VaM2.
Hi Guest!
VaM2 Resource Categories have now been added to the Hub! For information on posting VaM2 resources and details about VaM2 related changes to our Community Forums, please see our official announcement here.
This new features allows you to create your own component which will control any triggerable parameters you add to it. If it's a value that can modified from a trigger, it can be added to this custom component. All other SceneDirector features will work with this component, just like the built-in ones.
You can find the UI to create and tweak the custom components on the Atom-Components-Custom tab.
Add triggerable params from any storable of the controlled atom.
Atom State UI is automatically created for any params added to the component. You can choose the order in which they appear, the UI column, and the UI label, for each of them.
Custom Params will store/apply with states, smoothly transition or animate via sub-state mixes, just like the built-in ones.
You can add drivers for scalar (toggle/slider/string) Custom Params.
The video below shows this feature - where and how to add Custom Params, and how to use them in idle animation which uses sub-state mixes:
The following video is a bit more advanced, displaying how Drivers can be used to control Custom Params.
And yes, if you wanted to achieve just the result from this video, a slider+trigger for the four params would probably be a simpler solution, since it can do linear interpolations natively (but not much more). However, rthe Expression/Driver system is much more flexible ; you could trivially add a toggle to control whether the wetness controls only the gloss or the cloth overlay ; you could make the gloss range configurable ; or the wetness itself could be derived from penetration duration, BodyLanguage's stimulation, or anything else. Anything more complex than a linear interpolation of a couple values gets very messy very quickly with triggers in my experience.
For a reference, here is the wetness setup based on BodyLanguage's stimulation and recent orgasm count I am using in one of my scenes:
SubState Mix Changes
When animating atom's parameters via sub-state mixes, any changes to currently relevant sub-state values will be applied to the mix immediately.
Implemented Odd/Even sub-state animation mode. If this is enabled, the atom will bounce between random mixes of odd and even states (the main state being considered state 0 = even). This allows for controlled ping-pong animation but still with some randomized variations.
The video below shows all these features in action:
Wetness controlled by the setup shown in the video above. Whenever I move the wetness slider in the video, it gets applied to the animated states immediately.
The idle animation uses the new Odd/Even mode, with the butt-sway using two sub-states for either side for some variation.
Technical note about the sub-state mix changes:
Before this update, whenever the atom started animating transition from one sub-state mix to another, it would pre-compute both mixes and then transition between them. So any changes to the source or target sub-states while the atom was transitioning would not show, only once another transition to the modified sub-state started. So in the example video above, before this change, the wetness slider changes would not show up on the skin immediately ; only after the next butt-bounce would the skin wetness transition to the new set of values.
This can be actually seen in the top video (the tutorial), which was recorded before I implement this change. Even after I change all sub-state colors to red, the top still transitions to black once, because it recorded that value just before I changed it. Overall, the old behavior was fine originally, but with Drivers implemented it got quite confusing and useless.
Other Changes
Fixed Drivers not loading correctly for Morphs
Changed Properties controlled by Driver Expressions to still respect their minimum/maximum limits, if they are hard-limited in the corresponding VaM's UI.
Changed the slider for floating-point variables to be limited to 0-1 range by default. It can be moved past the limits of course.
Fixed log and log10 expression functions being swapped
Fixed empty expressions still applying their last recorded value when being used as a driver, instead of behaving as a no-op. Now it will be possible to set up an empty driver and then override it with a custom expression only in some states.
Fixed Chapter Index int variable source being misspelled
Fixed exception being thrown on plugin destroy/reload
The main new feature of this update is the addition of Drivers, which let you drive any(*) of the component properties by mathematical expressions. Some ideas/examples for use of drivers are shown at the bottom of this update.
Drivers for atom properties are defined on the Components-Drivers tab. For now the expression system supports only scalar values, so drivers are available only for boolean (toggle), int/float (slider) and string properties. Support for colors, vectors (positions) and rotations will be added later.
For more information, check the Variables, Expressions and Drivers documentation (hopefully I will update it before this gets approved and published! )
Atom-scoped Variables
Closely related to drivers, in addition to the previously existing global variables defined on the main Variables tab, each atom now also has its own Components-Variables tab. The UI is the same, the variables and expressions defined here are visible only for that atom's expressions. It's useful mostly for organizing the variables, removing the global clutter. In the future expressions will be able to reference variables from other atoms too, but now you are limited to:
Global expressions can reference only other global variables/expressions.
Atom-scoped expressions can reference either variables/expressions defined at the same atom's scope, or global variables/expressions.
Live Editing
When a sub-state is applied, and therefore now transitions/sub-state animations are running, editing properties of that sub-state in the plugin's UI will apply them to the scene directly. Just like editing atoms directly in VAM's native UI would work.
Other Changes
UIObject component can control the state of slider and toggle values,
Various tweaks and fixes
Driver Examples
Example 1 - Blinking Light
A light source with intensity updated by a driver. In this example it will be blinking at user-controllable amplitude and frequency, using a simple sine-wave shape for the intensity.
Step 1:
Define user-controlled variables. The source being set to Public Value means that the plugin will create a triggerable param for each of them. The sliders have a trigger defined on them, setting the individual values (not shown in the picture)
Step 2:
Define an expression variable at the LightHeart atom. This expression will update the angle to a value between 0 and 360 degrees. Sine of the angle will then later make the intensity blink. This is a bit more complex expressions, showing several features of the expression system:
Expressions can reference themselves. The plugin ensures that each variable will be evaluated at most once each frame. This means that we can use the frame's duration and the current variable's value to compute the next frame's value, which results a smooth transition/animation.
Expressions support conditional if-statements. In this example:
If the user-defined frequency is zero, the angle will smoothly transition towards the zero value. That will effectively stop the blinking, but not stop it at whatever angle it was when the frequency got set to zero, instead if will smoothly return to the neutral intensity.
Otherwise advance the angle by the frame's duration multiplied by the frequency, looping at 360 degrees ; the magical 6 multiplication factor is just 360/60, so the angle will advance by 360 per second when the frequency is 60 (and yes that's not Hz, that's beats per minute, I mistyped the slider's label)
Step 3:
Last step defines the actual Driver for the Intensity property of the Light atom. The complex math was all in the angle which drivers the flashing, this just applies the sine-wave multiplied by the amplitude, with the neutral intensity added. Rather simple.
And the video blow shows the result:
Example 2 - Morphs Controlled by Morphs
This simple example controls the tongue length morph as 10-times the belly bulge 4 morph, which comes from the BodyLanguage plugin.
Realistically you would probably use the penetration depth to control something like this, and use a more complex morph setup. Probably with some kind of smoothing/delay (delay is quite tricky to implement exactly, but slow smoothing would do a similar trick).
Step 1:
Add a variable tracking the bulge's morph value. Remember that the morph must be marked as a "favorite" for it to show in VaM's geometry storable.
Step 2:
Set up drivers for any of the morphs controlled by SceneDirector on the atom. Naturally, you must first set up controlled morphs on the Morphs tab, not shown here. In the scene where I tested this, I already had a group of Face morphs configured, so I just chose the tongue length morph for this example.
This allows you to track any public storable param of anything in the scene as a variable.
While usage of variables and expressions is still limited mostly to text formatting, you can already use this feature to show any boolean, floating-point or string param value in the scene on UI objects.
Other Changes
Support for SexyFluids v10.f4
Automatically create a component for each fluid emitter, including custom emitters.
Adding/renaming/removing emitters in SexyFluids will automatically refresh that atom's components in SceneDirector.
As a side-effect, SceneDirector will no longer take so long to initialize when controlling an atom with SexyFluids attached (it used to wait to see if it might be a female with alt-futa plugin before initializing the fluid components, now it can refresh whenever it needs to).
Capturing SexyFluids state will now set the preset to none ("no change"), rather than the currently selected fluid preset.