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