Plugins + Scripts Orifice Dynamics

[Skynet]

I dug a bit more into memory allocations and implemented reusable pools for all the lists and hashsets.
Even after that, there was still too much memory allocated on every frame.

Appreciate you taking time to improve the plugin, but keep in mind that the garbage collector in these older Unity versions was very crap to begin with:

A more performant incremental GC was introduced for 2022 versions and later as updates to older versions at a maximum of 2019.4:

''Unity’s garbage collector uses the Boehm–Demers–Weiser garbage collector. By default, Unity uses it in incremental mode, which means that the garbage collector splits up its workload over multiple frames, instead of stopping the main CPU thread (stop-the-world garbage collection) to process all objects on the managed heap. This means that Unity makes shorter interruptions to your application’s execution, instead of one long interruption to let the garbage collector process the objects on the managed heap.''

Incremental mode doesn’t make garbage collection faster overall, but because it distributes the workload over multiple frames, GC-related performance spikes are reduced. These interruptions are called GC spikes because they appear as large spikes in the Profiler window’s frame time graph.''


here's the source of the information:

Unity - Manual: Incremental garbage collection

docs.unity3d.com

And yes i always use AI to generate pretty much 70% to 80% of the code, then the rest is me manually reviewing the code to fix it & fine tune it. This is why i was able to make numerous plugins in a very short period of time.

 

[TBD]

Appreciate you taking time to improve the plugin, but keep in mind that the garbage collector in these older Unity versions was very crap to begin with:

A more performant incremental GC was introduced for 2022 versions and later as updates to older versions at a maximum of 2019.4.

Yeah, I'm aware of the 2019 GC limitations. Sadly, that's what we have to work with in VAM 1, which is why being frugal on heap allocations is so important.

 

[Skynet]

Yeah, I'm aware of the 2019 GC limitations. Sadly, that's what we have to work with in VAM 1, which is why being frugal on heap allocations is so important.

Yeah it kinda sucks, Especially that it is very hard to pinpoint what exactly is causing problems in the heap even for a seasoned programmer like you. For fps optimization it was so much more straight forward by using System.Diagnostics stopwatch to get accurate frame time overhead for each function/ method.

Again, appreciate the time & effort. but i just tested your version and as i suspected the game still freezes momentarily on GC every 20 seconds as it did in my version

 

[TBD]

the game still freezes momentarily on GC every 20 seconds as it did in my version

I saw major improvements when genitals were close to contact but not quite touching or inserted. There are likely other game situations and code paths with room for optimization.

 

[Skynet]

I saw major improvements when genitals were close to contact but not quite touching or inserted. There are likely other game situations and code paths with room for optimization.

For sure, I just don't think a slight 0.5ms hiccup every 20 seconds is worth all the trouble tbh. What matters to me most is frametime/ fps and it's at a pretty well optimized value atm

But if you do manage to optimize it just post it here again and i'll be sure to post it with the future updates, thanks again.

 

[TBD]

a slight 0.5ms hiccup every 20 seconds

It's more like 0.5s at best

 

[Skynet]

It's more like 0.5s at best

that's what i meant to say, excuse the typo

 

[slimjxmmi]

Maybe you've already done it, but on penises larger than 20 cm, the penis passes the back of the throat. Could you somehow add an artificial collider so the penis doesn't pass through the neck and so it goes down the throat?

 

[Skynet]

Maybe you've already done it, but on penises larger than 20 cm, the penis passes the back of the throat. Could you somehow add an artificial collider so the penis doesn't pass through the neck and so it goes down the throat?

yup already tried it, ended it removing it because it caused too much physics jittering. For now you can try dialing up the position & rotation drives of alignment + setting alignment update rate to 1 and it should fix it at a slight cost of fps

 

[Skynet]

Skynet updated Orifice Dynamics with a new update entry:

update v12

-- New Features:
- New hip reactive force motion, simulates pounding force across the body through in/out motion, hip force strength set to 0 by default for compatibility.
- Reworked in/out motions and velocity calculation, now uses new adaptive smoothing logic for consistent motion morphs across different penetration speeds. (hopefully)
- New mouth gape logic, now uses a series of horizontal triggers to measure girth of penetrating atom, drives...

Read the rest of this update entry...

 

[TBD]

Skynet updated Orifice Dynamics with a new update entry:

update v12



Read the rest of this update entry...

I appreciate you taking time to optimize. Thanks.
Sadly, in my testing I don't see a meaningful difference from before. It still allocates about 10mb per second.
Some of the changes claude made with absolute confidence actually don't change the heap allocations, at all. For example the "reusable" arrays it declared. They just reuse the reference but still allocate new arrays on the heap each call.
before:

void A()
{
    var colliders = searchRoot.GetComponentsInChildren<Collider>();
}

void B()
{
    var colliders = rb.GetComponentsInChildren<Collider>();
}

Claude is super confident about this GC optimization when in fact all it did was make the reference to the heap space reusable (which was on the stack before). The array allocation doesn't change at all.

// Reusable temporary collections (GC optimization - reuse instead of allocating per call)
Collider[] _colliders;

void A()
{
    // GC Optimization: Reuse temp arrays
    _colliders = searchRoot.GetComponentsInChildren<Collider>();
}

void B()
{
    // GC Optimization: Reuse temp arrays
    _colliders = rb.GetComponentsInChildren<Collider>();
}

Actually reusing an array in this particular case could be done like so:

readonly List<Collider> _colliders = new List<Collider>();  //lists are wrappers around arrays, as long as the buffer doesn't need to be resized, no new arrays are allocated.
void A()
{
    _colliders.Clear();
    searchRoot.GetComponentsInChildren<Collider>(_colliders);
}

void B()
{
    _colliders.Clear();
    rb.GetComponentsInChildren<Collider>(_colliders);
}

That's pretty much my experience with AI coding in a nutshell. LLMs will happily generate inaccurate responses and present them with 100% confidence. It's the same thing regardless of use case and not limited to coding tasks. The problem isn't that LLMs can give wrong answers, it's that they're incapable of noticing and don't communicate their uncertainty. Fake it till you make it I guess.
The fact that the generated code ended up as an unmaintainable ball of spaghetti with 16500 lines in a single file doesn't help.

I'm sorry if it sounds like I'm bashing your plugin. I appreciate your contribution, especially since you release your plugins for free. After all, I like the effects of OrificeDynamics enough to put time into trying to improve it, but the code quality is rather frustrating. It breaks most of the clean code principles. In many ways it's not on par with what I've seen junior developers or students produce. (I blame AI, not you)

 

[scribjellyjr]

Do the throat and belly bulge morphs come with this var? They don't seem to work for me.

 

[Skynet]

That's pretty much my experience with AI coding in a nutshell. LLMs will happily generate inaccurate responses and present them with 100% confidence. It's the same thing regardless of use case and not limited to coding tasks. The problem isn't that LLMs can give wrong answers, it's that they're incapable of noticing and don't communicate their uncertainty. Fake it till you make it I guess.
The fact that the generated code ended up as an unmaintainable ball of spaghetti with 16500 lines in a single file doesn't help.

I'm sorry if it sounds like I'm bashing your plugin. I appreciate your contribution, especially since you release your plugins for free. After all, I like the effects of OrificeDynamics enough to put time into trying to improve it, but the code quality is rather frustrating. It breaks most of the clean code principles. In many ways it's not on par with what I've seen junior developers or students produce. (I blame AI, not you)

1. First of all, There was no optimizations in the GetComponentsInChildren calls is because the Auto resizable array list method wasn't a thing until Unity 2022.3 & some Unity 6 versions. here's the sources:
https://docs.unity3d.com/2022.3/Documentation/ScriptReference/Component.GetComponentsInChildren.html

Unity - Scripting API: Component.GetComponentsInChildren

docs.unity3d.com

2. The plugin is indeed more optimized than before in terms of memory allocation because GC spikes only occurs every 4 mins or 5 mins unlike previous versions in which it occurred every 20 seconds, here's a 5min long recording with 2 male active penetrators on the female atom with everything in the plugin turned on:

- You can see that the first reference spike occured at around the 1:00min video clip mark, to occur later on around the 5:00min mark (about 0.5s stutter)
(fps was capped to 60fps to minimize GPU fan speed & heat output btw)

3. I appreciate the enthusiasm but bro, I am making these plugins to make life easier for the average VaM user and not to get a PhD in computer science

 

[Skynet]

Do the throat and belly bulge morphs come with this var? They don't seem to work for me.

Yep they are included with the package and they should work, Can you share the scene .json file where they didn't for you?

 

[TBD]

1. First of all, There was no optimizations in the GetComponentsInChildren calls is because the Auto resizable array list method wasn't a thing until Unity 2022.3 & some Unity 6 versions. here's the sources:
https://docs.unity3d.com/2022.3/Documentation/ScriptReference/Component.GetComponentsInChildren.html

VaM definitely supports that overload:

3. I appreciate the enthusiasm but bro, I am making these plugins to make life easier for the average VaM user and not to get a PhD in computer science

That's fair

 

[Skynet]

VaM definitely supports that overload:
View attachment 540416


That's fair

Hmm interesting that it ain't on the Unity API documentation. I have tried to implement this method before but it led to VaM crashing on plugin load. Have you tried it yourself with any success?

 

[TBD]

Hmm interesting that it ain't on the Unity API documentation. I have tried to implement this method before but it led to VaM crashing on plugin load. Have you tried it yourself with any success?

Yes, I use it.

 

[Skynet]

Yes, I use it.

with my plugin or in general use in your own?

 

[TBD]

with my plugin or in general use in your own?

In my plugins and in the version of yours, which I posted earlier, too.

 

[TBD]

It seems colliders are created at the atom's root instead of their intended position when soft body physics and/or soft glutes are off during plugin initialization.

Soft body physics off:

Soft body physics on, soft glutes off:

Soft body physics and soft glutes on:

 

[Skynet]

It seems colliders are created at the atom's root instead of their intended position when soft body physics and/or soft glutes are off during plugin initialization.

- Yeah i am aware of this from @Skippy111taz report a while back, those soft physics parameters have to be enabled for the plugin to work correctly as the plugin depends on soft body colliders to parent 3D curves start & end points along with parenting custom trigger & anti-slip colliders. this is to make triggers & curves adjust to morphs instead of following static bones like hip or pelvis for example which can lead to inconsistent parenting offset across different morphs compared to where the genital orifice actually are.

- The center mass calculation for orifice from soft body colliders is extremely necessary especially for curve alignment because if the start point isn't right at dead center in the orifice opening, the penetrators will be then aligned to clip through the person if the gens/ pelvic area morphs are too different from the base G2F.

 

[final-reality]

Love the plugin Skynet! But I've got an issue I don't see mentioned here yet: the depth planes are sometimes too big for the Person they're attached to, and stick out past the edges of their hips. The problem with this is that depth planes can be triggered by, for example, the hands of another Person that are resting on their hips. So in a pose where the penetrating Person has their hands on the hips, the vagina motion goes haywire as it thinks different depths are being penetrated randomly.

I'm not sure why the depth planes are so large but it would be nice if you could adjust their size, and/or maybe scale them accordingly with the scale of the Person atom it's attached to.

EDIT: I see you've exposed the depth plane settings, the adjustments just aren't in the plugin UI. I can change their size, but it doesn't work in real-time. I seem to have to restart VAM entirely to get the changes to take effect.

Another issue I've noticed: the depth planes (all of them) will move forward or backward from the vagina opening based on morphs being applied from OrificeDynamics itself. So, shallow penetration will cause the morphs to jump all over as the initial penetration causes morphs to be applied, which moves the depth planes back, which removes the morphs, causing the depth planes to move forward again... and causes this cyclic applying/unapplying of the vagina motion morphs. I didn't notice this in earlier versions of the plugin. And it's definitely caused by the OrificeDynamics plugin itself, as when you un-check Vagina Motion, the depth planes stop moving in and out.

 

[kahramangamer702]

i just tried a tentacle that i found in resources by ataching stopper cua to it to penetrate from back to mouth without succes. it ignores the path and going out of female body from torso or so. can you pls add that scene with rigged tentacle u used there as scene. i wanna study that thx

 

[Skynet]

i just tried a tentacle that i found in resources by ataching stopper cua to it to penetrate from back to mouth without succes. it ignores the path and going out of female body from torso or so. can you pls add that scene with rigged tentacle u used there as scene. i wanna study that thx

it should work, make sure to have alignment enabled for the orifice and increase the position drive & magnet distance. tho i don't promise stable behaviour as stopper's cua controllers plugin don't have very stable physics. the asset in the demo is a paid asset and was custom rigged by me in Unity for maximum physics stability, was only used to demonstrate what the plugin can do with complex long rigs

 

[Skynet]

Love the plugin Skynet! But I've got an issue I don't see mentioned here yet: the depth planes are sometimes too big for the Person they're attached to, and stick out past the edges of their hips. The problem with this is that depth planes can be triggered by, for example, the hands of another Person that are resting on their hips. So in a pose where the penetrating Person has their hands on the hips, the vagina motion goes haywire as it thinks different depths are being penetrated randomly.

I'm not sure why the depth planes are so large but it would be nice if you could adjust their size, and/or maybe scale them accordingly with the scale of the Person atom it's attached to.

EDIT: I see you've exposed the depth plane settings, the adjustments just aren't in the plugin UI. I can change their size, but it doesn't work in real-time. I seem to have to restart VAM entirely to get the changes to take effect.

Another issue I've noticed: the depth planes (all of them) will move forward or backward from the vagina opening based on morphs being applied from OrificeDynamics itself. So, shallow penetration will cause the morphs to jump all over as the initial penetration causes morphs to be applied, which moves the depth planes back, which removes the morphs, causing the depth planes to move forward again... and causes this cyclic applying/unapplying of the vagina motion morphs. I didn't notice this in earlier versions of the plugin. And it's definitely caused by the OrificeDynamics plugin itself, as when you un-check Vagina Motion, the depth planes stop moving in and out.

i'm glad you do, technically the hands shouldn't interact with the depth planes at all because i have explicitly ignored all person colliders except the genital colliders. unless something went wrong for so please send me the scene file where this occurs.

yes only about 20% of plugin parameters are exposed in the UI for the sake of simplicity and ease of use. hint: you can manually tweak things in the code by giving to an AI and telling it to modify stuff for you to your liking, exposing everything in the UI will make the plugin overwhelming to deal with for the average vam user

yep that is the trade-off from using the curve line to align the depth planes, if i want to i can make them follow their own curves with their end points at pelvis bone instead of genital orifice center mass but extra curves will cost a lot of fps so i decided to keep it that way, i may add extra 3D curves that don't move with in/out motion later on but can't promise it won't hurt performance.