Plugins Naturalis (free)

[RonBurgundy]

I'm not able to view the video, says "No video with supported format and MIME type found." Is it working for you?

Regarding your settings, why the 240Hz physics rate?

weird, works for me but maybe because it is a 4K video in H265?
I mainly use the 240Hz because i use a frame capture plugin (Eosin Renderer) and want to make sure that collisions and everything have the best possible setup and since frame rate doesn't matter i figure, why not? Now maybe i am misunderstanding and there is absolutely no benefit to running Physics rate faster than frame rate?

Regardless, this is the FIRST time i have ever noticed this issue with Naturalis with ANY physics setting. If you check out the FULL vid, when the looks are backlit you can see the the breasts are oscillating before they start moving (Left is most noticeable)

can you please let me know if you can see BOTH of these vids? It would be good for me to know if people can't view vids that i am posting.
This one is H265 & downscaled to 1080p

This one is H264 & downscaled to 1080p

here is a link to the FULL vid on Vimeo

 

[everlaster]

Using Naturalis 60 and trying to figure out why they are still bouncing even when static?

Just noticed this now - Naturalis.60.var is v1.3-beta3 which is a paid release and far from the latest version.

Update your scene to use either the latest free version (v1.2.4 or 53.var), or the latest paid version from Patreon (v1.3.4 or 68.var). Let me know if the problem still persists in whichever of those versions you test with.

wierd, works for me but maybe because it is a 4K video in H265?
I mainly use the 240Hz because i use a frame capture and want to make sure that collisions and everything have the best possible setup and since frame rate doesn't matter i figure, why not? Now maybe i am misunderstanding and there is absolutely no benefit to running Physics rate faster than frame rate?

Sure, I was just wondering. For frame by frame capture it probably makes sense. However keep in mind that physics will still slow down if your frame rate goes under Physics Rate divided by Update Cap. In your case, 240Hz with cap 3 allows physics to update in real time all the way down to 240/3 = 80 fps, but below that frame rate, physics will run in slow motion since it's capped to 3 physics updates per frame. At 40 fps physics will run at exactly half speed. It's much easier to avoid this at a lower physics rate.

can you please let me know if you can see BOTH of these vids? It would be good for me to know if people can't view vids that i am posting.
This one is H265 & downscaled to 1080p
...

This one is H264 & downscaled to 1080p
...

H265 - Works in Edge, not in Firefox. Can't test Chrome (not installed)
H264 - Works in Firefox as well. I was able to view it now but I'll wait for you to report back with results using an up-to-date Naturalis version.

Only OGV works in the in-game Hub browser, in case you want your videos to be viewable there as well

 

[RonBurgundy]

Just noticed this now - Naturalis.60.var is v1.3-beta3 which is a paid release and far from the latest version.

Update your scene to use either the latest free version (v1.2.4 or 53.var), or the latest paid version from Patreon (v1.3.4 or 68.var). Let me know if the problem still persists in whichever of those versions you test with.


Sure, I was just wondering. For frame by frame capture it probably makes sense. However keep in mind that physics will still slow down if your frame rate goes under Physics Rate divided by Update Cap. In your case, 240Hz with cap 3 allows physics to update in real time all the way down to 240/3 = 80 fps, but below that frame rate, physics will run in slow motion since it's capped to 3 physics updates per frame. At 40 fps physics will run at exactly half speed. It's much easier to avoid this at a lower physics rate.


H265 - Works in Edge, not in Firefox. Can't test Chrome (not installed)
H264 - Works in Firefox as well. I was able to view it now but I'll wait for you to report back with results using an up-to-date Naturalis version.

Only OGV works in the in-game Hub browser, in case you want your videos to be viewable there as well

Thanks, i will try that, quick question, what IS the cap exactly?
Is Lower (1), more accurate/slower or Higher (3)? Or am i misunderstanding completely and the cap is just a limit that the system places on framerate to allow physics to keep up?
Basically I am often running timeline in Game Time (instead of realtime) which slows down the frame rate to make sure that each frame is processed correctly, which is needed for a complex scene if you're recording. I could technically put a dozen dancers on the screen using this and it will take longer to render/record it, but the resulting video won't have any lag.

I do notice that when i have a higher physics rate, it takes significantly longer to calibrate, which makes me feel like it is making calculations more frequently.

My biggest concern is that i don't want clipping issues with SIM clothing if i can avoid it, so the best way i can accomplish that is how i want to set it up.
I want it configured for accuracy over speed.

 

[everlaster]

Thanks, i will try that, quick question, what IS the cap exactly?
Is Lower (1), more accurate/slower or Higher (3)? Or am i misunderstanding completely and the cap is just a limit that the system places on framerate to allow physics to keep up?

It means how many physics updates are allowed per rendered frame. Unity (the game engine VAM is built on) runs physics at a separate rate from the frame rate.

If your frame rate is higher than your physics rate, there's only going to be 1 physics update per frame, no matter what the cap is set to.

But when frame rate is lower than the physics rate, physics can update as many times per frame as your Update Cap number. If set to 1, only 1 update per frame is allowed, which means any frame rate lower than the physics rate causes physics to slow down. It's trying to run e.g. physics at 60 Hz but with a frame rate of 45 fps, it can only run 45 Hz, so you get a slow down of 25%. If set to 2, frame rate can go down to half the physics rate (e.g. 30 fps with 60 Hz physics), before physics stops being real time. And if set to 3, frame rate can go all the way down to one third the physics rate (e.g. 30 fps with 90Hz physics) before physics slows down.

I do notice that when i have a higher physics rate, it takes significantly longer to calibrate, which makes me feel like it is making calculations more frequently.

The calibration shouldn't be physics rate dependent. I just tested in the latest paid version and it's was as quick at 240Hz as 60Hz

My biggest concern is that i don't want clipping issues with SIM clothing if i can avoid it, so the best way i can accomplish that is how i want to set it up.
I want it configured for accuracy over speed.

Yep that makes sense

 

[RonBurgundy]

It means how many physics updates are allowed per rendered frame. Unity (the game engine VAM is built on) runs physics at a separate rate from the frame rate.

If your frame rate is higher than your physics rate, there's only going to be 1 physics update per frame, no matter what the cap is set to.

But when frame rate is lower than the physics rate, physics can update as many times per frame as your Update Cap number. If set to 1, only 1 update per frame is allowed, which means any frame rate lower than the physics rate causes physics to slow down. It's trying to run e.g. physics at 60 Hz but with a frame rate of 45 fps, it can only run 45 Hz, so you get a slow down of 25%. If set to 2, frame rate can go down to half the physics rate (e.g. 30 fps with 60 Hz physics), before physics stops being real time. And if set to 3, frame rate can go all the way down to one third the physics rate (e.g. 30 fps with 90Hz physics) before physics slows down.


The calibration shouldn't be physics rate dependent. I just tested in the latest paid version and it's was as quick at 240Hz as 60Hz

Yep that makes sense

Tested this on 53 and on 65 and the same issue arises.
It's not 100% of the time but it is much more likely to happen when i really stress it out with 5 or 6 dancers and set the physics rate high.
It won't do it with only 1 look on screen but with 5 or 6 looks, sometimes the oscillating will happen to 1 or 2 of the looks and sometimes all of them.

I just happened to capture this yesterday with it happening to all 6 looks.
you probably haven't run across this issue because of the demanding setup but I figured you would want to know about it.

 

[everlaster]

@RonBurgundy That's good reporting, anchorman.

So if you have 5-6 dancers but run at 60Hz physics for example, there's no issue, and if you have fewer people but run a very high physics rate, there's no issue?

When it occurs, does the issue go away if the plugin is reloaded? What about when you lower the physics rate after the issue occurs, does it go away then? And what about removing person atoms down to 1-2 after it occurs?

I imagine this kind of scene isn't really feasible to run and test in real time, i.e. you have to record the frames, compile the video and only then it will become apparent if there was an issue?

 

[RonBurgundy]

@RonBurgundy That's good reporting, anchorman.

So if you have 5-6 dancers but run at 60Hz physics for example, there's no issue, and if you have fewer people but run a very high physics rate, there's no issue?

When it occurs, does the issue go away if the plugin is reloaded? What about when you lower the physics rate after the issue occurs, does it go away then? And what about removing person atoms down to 1-2 after it occurs?

I imagine this kind of scene isn't really feasible to run and test in real time, i.e. you have to record the frames, compile the video and only then it will become apparent if there was an issue?

i didn't test ALL of those scenarios yet but I've noticed if i lower the physics rate (to 144 or 120) and DON'T calibrate, it almost always fixes it.
Sometimes if i calibrate after rate change, it comes back.

I will try with a 60Hz rate (haven't done that yet)

Is it absolutely necessary to calibrate after a physics rate change? What happens if i don't? It doesn't seem to really look "off" to me when i do that.

 

[everlaster]

Is it absolutely necessary to calibrate after a physics rate change? What happens if i don't? It doesn't seem to really look "off" to me when i do that.

No it's not absolutely necessary. Nothing breaks, it's just not using the optimal damper settings (pectoral/glute joint and soft physics joint dampers) for that physics rate. I could hot swap in the new dampers since damper values don't affect the calibration result - I'll put a note on looking into that later

 

[everlaster]

everlaster updated Naturalis (free) with a new update entry:

v1.2.5

• fixed issue where glute joints still had gravity acting on them when BootyMagic was disabled/removed (thanks @CuddleMocap !)
• fixed a physics explosion issue when the plugin was removed after changing skin while Freeze Physics was enabled in Control & Physics 1
• the Enabled toggle of BootyMagic is no longer interactable if loaded on a male character
• disabled scrolling in most text fields

Read the rest of this update entry...

 

[RonBurgundy]

@RonBurgundy Does that scene have some custom gravity settings in the Scene Misc tab? Naturalis currently only works with normal gravity (x =0, y = -9.81, z = 0)

EDIT: I checked the scene json file and there are at least lots triggers relating to gravity

gravity seems normal. one other thing i noticed was that it isn't constant, like if the person is standing still, the breasts seem to move slightly in random increments just like when the wind plugin is activated. there is a breeze with slight gusts.

 

[VRmatt]

I think I'm having troulble when I use this plugin.
I'm getting crashes saying "too many heap sections" for a GC error.
I have Nvidia 4090 and tons of ram.
Anyone else seeing this?

 

[everlaster]

I think I'm having troulble when I use this plugin.
I'm getting crashes saying "too many heap sections" for a GC error.
I have Nvidia 4090 and tons of ram.
Anyone else seeing this?

This is likely an issue with too many morphs being loaded in your installation. Naturalis of course adds a few so it contributes, and its morphs get loaded on demand by default, so in theory adding the plugin can be the thing that tips the program over the edge. See https://hub.virtamate.com/threads/too-many-heap-sections.38525/#post-108657

 

[too]

Hi everlaster

I'm getting some weird bug with naturalis. Is there some debug log that I could send over?

I attached the settings in use.

I suspect there's some weird interaction with other plugins that's causing this, because titty magic produces the same results.

If I remove titty magic and naturalis, the boobs go back to behaving like normal.

Do you have any idea on how to fix this?

Thanks for the cool plugin!

 

[everlaster]

Hi everlaster

I'm getting some weird bug with naturalis. Is there some debug log that I could send over?

I attached the settings in use.

I suspect there's some weird interaction with other plugins that's causing this, because titty magic produces the same results.

If I remove titty magic and naturalis, the boobs go back to behaving like normal.

Do you have any idea on how to fix this?

Thanks for the cool plugin!

Hi, the morph values in Naturalis are driven by the angle of the pectoral joint. If something causes the pectoral joint to not rotate smoothly but warp back and forth like that, it would cause the morphs to also not adjust smoothly.

If you suspect it's an issue with the plugin interacting other plugins, can you test that and remove other plugins and see if it still happens? if it doesn't happen, can you narrow it down to which plugin interaction is the culprit?

Does it also happen with the default softness and quickness values (70 and 0)?

One possible but I think unlikely cause for this could be a synchronization issue between morphing and the physics due to physics rate and frame rate not being synced. VAM updates morphs per frame (but not exactly, the logic runs in a separate CPU thread), while the joint angle updates at the fixed physics rate. I'm not sure if it's even possible but if the frame rate varies wildly, maybe the plugin could end up applying morphs using old joint rotation information and the application of the morph would itself rotate the joint, and that would then feed into the next frame and cause the oscillation until it stabilizes. Just theorizing..

 

[too]

Hi, the morph values in Naturalis are driven by the angle of the pectoral joint. If something causes the pectoral joint to not rotate smoothly but warp back and forth like that, it would cause the morphs to also not adjust smoothly.

If you suspect it's an issue with the plugin interacting other plugins, can you test that and remove other plugins and see if it still happens? if it doesn't happen, can you narrow it down to which plugin interaction is the culprit?

Does it also happen with the default softness and quickness values (70 and 0)?

One possible but I think unlikely cause for this could be a synchronization issue between morphing and the physics due to physics rate and frame rate not being synced. VAM updates morphs per frame (but not exactly, the logic runs in a separate CPU thread), while the joint angle updates at the fixed physics rate. I'm not sure if it's even possible but if the frame rate varies wildly, maybe the plugin could end up applying morphs using old joint rotation information and the application of the morph would itself rotate the joint, and that would then feed into the next frame and cause the oscillation until it stabilizes. Just theorizing..

About the pectoral joint, do you mean the chestControl? I have it set to OFF for both position and rotation.

Does it also happen with the default softness and quickness values (70 and 0)?

Yep it happens on default values too. I probably threw in too many plugins and then something broke with naturalis.

I'll debug it by removing plugins bit by bit. This will take a while. I'll be back!

 

[everlaster]

About the pectoral joint, do you mean the chestControl? I have it set to OFF for both position and rotation.
View attachment 361655
View attachment 361656



Yep it happens on default values too. I probably threw in too many plugins and then something broke with naturalis.

I'll debug it by removing plugins bit by bit. This will take a while. I'll be back!

I mean rPectoral and lPectoral. Those don't have controllers and UI's, but they exist as joints just like chest, rShoulder etc.

 

[alwaysblue]

I get physics explosion if I use the plugin sometimes the tits gets crazy, sometimes it's the vagina, sometimes the explosion is so bad the atom flies off into the distance, any idea what causes this? this happens after I load my scene so I have to remove the plugin and reload it again and disable what part of the body is exploding. I know I dont really have a powerful pc I have my soft body physics in the settings off idk if that is the reason..

 

[everlaster]

I get physics explosion if I use the plugin sometimes the tits gets crazy, sometimes it's the vagina, sometimes the explosion is so bad the atom flies off into the distance, any idea what causes this? this happens after I load my scene so I have to remove the plugin and reload it again and disable what part of the body is exploding. I know I dont really have a powerful pc I have my soft body physics in the settings off idk if that is the reason..

Seems like a collider issue. If you can send me the scene file, I can investigate further

 

[too]

I mean rPectoral and lPectoral. Those don't have controllers and UI's, but they exist as joints just like chest, rShoulder etc.

hmm that's news to me. can you point me towards a direction on finding those? I'll cross check those during my debug attempts.

 

[everlaster]

hmm that's news to me. can you point me towards a direction on finding those? I'll cross check those during my debug attempts.

Some plugin other than Naturalis might be doing something with them. But I think that's unlikely. Within VAM, it's possible to link to them:

I think that's also an unlikely explanation for the issue.

 

[everlaster]

@too

I'm pretty sure I know what it is now. Something is animating bone morphs, i.e. morphs containing "bone formulas" (red cog symbol in the Female Morphs tab). If those bone formulas include movement/rotation on the chest bone (or any bone above it in the DAZ G2 skeleton's hierarchy: Hip > Pelvis > Abdomen 2 > Abdomen > Chest > ...), the chest rotation is reset which causes the morph values to be reset, since the morphs values are based on the chest joint rotation

 

[too]

Ok I think I found it. It's something to do with clockwise' expression script. One of the morphs is probably affecting the pectoral bones you're mentioning above.

when i change to another preset facial expression, the bug goes away.

I'll update you if what I proposed, proves to be incorrect.
thanks for your help!