Unreal Engine how can we achieve soft Skin Physics in Unreal Engine

[darkevilhum]

I haven't been using UE very long either so I'm in the same boat. And yeah 30 or 40 colliders is no big deal, but we were talking about potentially hudnreds of colliders remember? You can do this test: Create a new physics asset, use these settings:
View attachment 3717859
You should now have sphere colliders for most bones in the body, somewhere in the range of 100 colliders, it should still perform pretty ok (until u hit the simulate button, then it lags a lot!) then, but these are just the normal bones, you were talking about making spring bones all over the character's body with their own unique colliders, so it's safe to say that's a couple hundred more colliders.

So try again with these settings:
View attachment 3717899

This should give you the same amount of colliders, but a roughly 5x higher number of primitives, so this is at least for me roughly the equivalent of having 500 spheres. If you tweak these values a bit you can actually get the colliders to very closely match the character's body, but once you get to that point your editor might straight up die because it'll be so laggy.

So that's what I meant about performance limitations. Also you have to consider that you'll probably rarely have only 1 actor active at a time, which means if you have 100 spheres, and 500 spheres would make you lag uncontrollably, then you could only have up to 4 characters active at a time with each character dropping performance by that much more (it might not be quite that simple, maybe it's optimized to run each character on different threads when it can or something I don't really know, but you get the idea).

And that's also where the issues with accuracy come in. If you want to use colliders and have any sort of performance you'll limit yourself to simple shapes like spheres and capsules as far as I can tell, because convex shapes that conform properly to your mesh are orders of magnitude more expensive (500 convex primitives didn't even cover half the mesh but 100 spheres covered all of it more or less in quite a lot of detail)

So if you want it to be accurate, like softbody-like detect exactly where on the mesh an object is pushing and deform it accordingly with a spring bone with each bone having a sphere collider for the surface (this actually seems like a good way to make the mesh deform from the inside if the penis collides with the body on the inside come to think of it), You're gonna need a lot of spheres, and the more accurate you want it to be, the more spheres and spring bones you're going to need to do it.

The other part of the accuracy problem is that you can only attach colliders to bones, so say for instance you have a vagina, and you have a bone for the left and right labia, only one each, you can put a capsule on each bone but it will not look very convincing, it's gonna be pretty janky, because it's not actually softbody, see? So to make it look convincing you would instead need to have a lot of bones each with individual colliders...

Which means that to have the kind of accuracy we're aiming for, you need to modify the mesh a lot by adding a moutnain of bones to it, and you're gonna need at minimum hundreds of colliders which is not gonna be conducive to performance. So you can make it really accurate at an extreme performance cost, or you can make it perform well with shitty accuracy.

It's a very unideal solution, i suppose it could work though.

That might be overkill for number of simple colliders. In my mind, you have the base skeleton, and then depending on how "soft" you want to go, somewhere in the range of 5-12 bones per "soft area", which would only really be the butt and breasts, then maybe 4-8 for places like the thigh/belly etc. 2 for calves/biceps. I'm just approximating here but you definitely don't need that many. For a vagina opening for example, if you wanted to do it purely with bones and a PA, I think you could achieve good results with 4 bones minimum or 6-9 if you really want to push it. If you wanted to be super cheap though, you could defo pull it off with just two bones and REALLY good weight painting + maybe some clever logic with supporting morphs.

When it comes to multiple actors, I think it depends on your goals/project type. For me personally, my project is focused on the main character (female) and her encounters (mostly male). So I will be cheaping out on the males and have her as the focus.
That being said, if your project requires a lot of these heavily simulated characters around at once, you'd likely have to start making performance decisions. Like who to prioritise, maybe a character limit or some system to switch out low priority ones with less "heavy" physics assets.
Im not sure if thats something we can do at runtime though? At very least, we can switch characters from simulated to kinematic and we can also switch their Physical Animation profiles. I do believe those profiles also include the bodies, so a on demand body reduction at runtime is possible I think.

 

[Velomous]

That might be overkill for number of simple colliders. In my mind, you have the base skeleton, and then depending on how "soft" you want to go, somewhere in the range of 5-12 bones per "soft area", which would only really be the butt and breasts, then maybe 4-8 for places like the thigh/belly etc. 2 for calves/biceps. I'm just approximating here but you definitely don't need that many. For a vagina opening for example, if you wanted to do it purely with bones and a PA, I think you could achieve good results with 4 bones minimum or 6-9 if you really want to push it. If you wanted to be super cheap though, you could defo pull it off with just two bones and REALLY good weight painting + maybe some clever logic with supporting morphs.

When it comes to multiple actors, I think it depends on your goals/project type. For me personally, my project is focused on the main character (female) and her encounters (mostly male). So I will be cheaping out on the males and have her as the focus.
That being said, if your project requires a lot of these heavily simulated characters around at once, you'd likely have to start making performance decisions. Like who to prioritise, maybe a character limit or some system to switch out low priority ones with less "heavy" physics assets.
Im not sure if thats something we can do at runtime though? At very least, we can switch characters from simulated to kinematic and we can also switch their Physical Animation profiles. I do believe those profiles also include the bodies, so a on demand body reduction at runtime is possible I think.

I was talking about this:

You must be registered to see the links

(from the op). You can see he clearly has (at least in the second half of the video) very accurate collisions. It'd be a lot of spheres to do that. Doing it with just a few bones per area though yeah it'd probably work, but making the collisions convincing would be quite difficult. The model i've got is basically already doing this on a smaller scale for boob and butt jiggle actually, but it's just that, jiggle and twist i suppose (and the collisions are very much not convincing). I do feel like firing up naughty sandbox again though and checking to confirm just how accurate the collisions really are on the default models (if they're as good as in that vr demo thing or not).

But well, in my case i don'twant anything quite too extreme, if i can run 3 convincing females and one male then it's fine, and i do intend to use some shenanigans to optimize performance like you suggested actually,a lot of the colliders can be disabled based on conditions, and males don't realy need softbody... But futas do.

 

[darkevilhum]

I was talking about this:

You must be registered to see the links

(from the op). You can see he clearly has (at least in the second half of the video) very accurate collisions. It'd be a lot of spheres to do that. Doing it with just a few bones per area though yeah it'd probably work, but making the collisions convincing would be quite difficult. The model i've got is basically already doing this on a smaller scale for boob and butt jiggle actually, but it's just that, jiggle and twist i suppose (and the collisions are very much not convincing). I do feel like firing up naughty sandbox again though and checking to confirm just how accurate the collisions really are on the default models (if they're as good as in that vr demo thing or not).

But well, in my case i don'twant anything quite too extreme, if i can run 3 convincing females and one male then it's fine, and i do intend to use some shenanigans to optimize performance like you suggested actually,a lot of the colliders can be disabled based on conditions, and males don't realy need softbody... But futas do.

Ah I see, there is no collision in that video. It's purely a shader effect being triggered by either a world position or a trace.

The only way to get an effect like that in UE5 with real collision would be to actually use their Chaos Flesh (which isn't really game or even runtime ready) or to create your own fully fledged true soft body system with collision which the NS dev definitely didn't do. He said as much himself and the work involved for that is quite a lot. You'd effectively need to recreate your own mini physics engine either in shader code or in c++ which then drives your shader soft body system.

With the stuff I've figured out so far, I can remake the effect in that video very easily, it's just not high on my priority list atm. As I'm not focusing on stuff that is more VR inclined. I'm trying to make a more general jiggle/soft flesh system atm where the skin will react to anything specified.

 

[razfaz]

We had the ChaosFlesh idea a page back already and came to the same conclusion, hrhr.
ChaosFlesh would be ok for single characters or offline rendering. It's to costly.

However, doing such with acceptable quality and for 2 or more Chars in realtime, without burning our CPU|GPUs down, is the challenge, so...

I still have many hopes for the Skeleton-Mesh Nanite approach (available since UE 5.5+); That could do the trick for this special challenge and more.

Sadly, I didn't have much time to dive deeper into this new possibility. I just made a basic Project with a Nanite enabled SkelMesh using my localy compiled UE5.5 dev-branch, including rigs, physics definitions etc., just to have a ready-made setup for experiments when I have more free time at some point in the future.

Time is my problem at the moment, but what I have seen regarding theoretical possibilities with SkelMeshNanites has left a very good impression so far. For example my first test with 1,000 high-poly copies of my NaniteSkelMesh incl. animations in the same scene. and I have'nt got a diashow.

Nanites are really impressive. I could have used 10,000 copies, and the fps would not drop much (in my case) I guess.
More experiments pending.

PS: /WTB 1k hours of freetime

 

[darkevilhum]

We had the ChaosFlesh idea a page back already and came to the same conclusion, hrhr.
ChaosFlesh would be ok for single characters or offline rendering. It's to costly.

However, doing such with acceptable quality and for 2 or more Chars in realtime, without burning our CPU|GPUs down, is the challenge, so...

I still have many hopes for the Skeleton-Mesh Nanite approach (available since UE 5.5+); That could do the trick for this special challenge and more.

Sadly, I didn't have much time to dive deeper into this new possibility. I just made a basic Project with a Nanite enabled SkelMesh using my localy compiled UE5.5 dev-branch, including rigs, physics definitions etc., just to have a ready-made setup for experiments when I have more free time at some point in the future.

Time is my problem at the moment, but what I have seen regarding theoretical possibilities with SkelMeshNanites has left a very good impression so far. For example my first test with 1,000 high-poly copies of my NaniteSkelMesh incl. animations in the same scene. and I have'nt got a diashow.

Nanites are really impressive. I could have used 10,000 copies, and the fps would not drop much (in my case) I guess.
More experiments pending.

PS: /WTB 1k hours of freetime

I'm pretty happy with how my shader based ripple effect looks at the moment for what it is. But to get high quality results and include collision in the same shader, I'll likely transition over to 5.5 so I can use skeletal meshes with nanite. Im just wondering if that will re-open the tessellation window or if they're 100% done with tessellation? Either way, it'll be tessellation or just a higher poly character mesh to support the shader visuals. Just waiting on compatibility for a couple of plugins I rely on for other stuff in my project, as it is, 5.4 is barely supported.

 

[razfaz]

... Im just wondering if that will re-open the tessellation window or if they're 100% done with tessellation? Either way, it'll be tessellation or just a higher poly character mesh to support the shader visuals. ...

Tessellation is not dead.
UE <= 5.4 for StaticMeshes, >=5.5 also for SKM : To enable Nanite Tessellation Material options, you need to set the following Engine .ini variables:

[/Script/Engine.RendererSettings]
r.Nanite.AllowSkinnedMeshes=1
r.Nanite.AllowTessellation=1
r.Nanite.Tessellation=1

A must read for more info and use ->

You must be registered to see the links

 

[razfaz]

We have'nt talked about LOD in our discussion yet, which is also a very important factor...
Calm your pulse. I realize that we somehow left this topic out, for good reason, because we all hate LODs.

But no panic! Gladly we have a solution already at hand

Another plus using Nanite (from my POV) is the cure for the pain of creating individual LODs:

So, no more manual LOD hassle = more time for creativity.

PS: I would upload the current Bins of the Dev State 06/15/24 for UE5.5 somewere for the ones who don't know hoe to compile Win64 Apps from Sauce but are superb in using UE, but the origin UE incl. all src and binaries are sadly way too large in sum (~0.5T) without a post Build cleanup.

PSPS: On the other hand, by building UE from Src yourself You'll get in deeper touch with the Git Version Control System and some other usefull things for Your professional future. Which will come handy as an additional Skill at some point in Your live, For example: Managing the envolvement of Your unuseful doctoral thesis script and every -maybe- useful work later on, I promise. Thank me later. hrhr.

Joke aside, thats my vain hope to motivate more people to be interested in basic TechScience and Project Management.
If pr0n can't motivate, nothing can! Maybe OldSchool Assembly Coding for Shaders is the Solution to solve this current challenge, instead of clicking some checkboxes, I dunno n' can't tell at this point, but the ideas, experiments and progress by every Post are remaining exciting.

 

[SimpleTimes]

Does the ue5-main SKM Nanite stuff already support morphs?

Or any other missing features that you've noticed during your testings?

 

[razfaz]

Does the ue5-main SKM Nanite stuff already support morphs?

Or any other missing features that you've noticed during your testings?

[1.0 SKM Nanite Features]
I have'nt noticed any missing features compared to Classic-SKMs so far. In contrary, there are more options available on top when having Nanites enabled.
[From the Materials point of view.]

In conclusion: Less hassle with SKM, but more fun|work|time for|with Materials/Shaders just with few Clicks and iniSettings. // me luv it!

[2.0 Morph-Question]
Good question! I have'nt checked Morphs yet, but I can't think of any reason why Morphs shouldn't work, but it's definitely worth a test. Thanks!
Why don't You do it yourself? (rhetorical)

[2.1 Morph-Research]
How ever, when I do feel the need (sarcasm') of doing a NaniteSKM-Morph Check in 5.5 this weekend, I'll report and share my personal exp. and results here too, like others have done here. The only thing that could come between us, is a sunny weather, an old school Grill, and a very choosen bloody Steak.
(giv n' (S)take)

[3.0 Smartass end]
For the Science, Phun and Pr0n! 1.2.3.!

 

[darkevilhum]

I was looking into some older UE5 posts about jiggle and such. I noticed a fair few posts of people asking stuff like "how did they achieve this jiggle" etc. And the examples they provided always looked very spring like to me, but the creators responded and said they used blendshapes/morphs that are driven by code or a spring.

The visuals of blendshape/morph based jiggle can look super good (with a decent bit of effort) but it's got tons of limitations like no collision, needing matching morphs for clothing etc.
I had a go at recreating that level of jiggle with a single bone spring constraint. I think it looks good enough to be honest. Obviously you can tweak settings as you like but the point is, even with one spring like below, you can get a fairly realistic reaction if you make use of all the settings.

Now if you rigged each cheek to 3, 6 even 9 bones and had those all hooked up, the results would be pretty impressive I imagine.

Here I used (for a single cheek):

• A linear motor on all axis, force 200, with an offset of 2 upwards on the z axis (to counter gravity a bit).
• I moved the center of mass of the body to be more or less center of the cheek. Adjusting the center of mass is important for stability and final results in my testing.
• a 6.5 linear limit on all axis.
• a soft constraint with force of 9000 and damping of 2.
• disabled projection.
• disabled shock propagation.
• the body/primitive itself has a mass of 2 with no damping whatsoever.

I could get varying levels of jiggle/bounce by tweaking the mass of the body and the soft constraint force

 

[razfaz]

@SimpleTimes and who might concern,

as promised: UE 5.5 Nanite SKM incl. Morphs and Tessellation Test = Check!
View attachment 2024-06-22_20h22_16.mp4

 

[razfaz]

PS: While I was doing this test I discovered my love for runtime MeshDeforming and Materials again.
I feel the desire to dive deeper into these topics now, for example AI supported

You must be registered to see the links

(FBX+Alembic (.abc) which should be the next step compared to the classic SKM-Morphing used above) and to explore the new Mat possibilities with Nanites in combination.

Does anyone of you already have experience with MLD and can eval conceivable possible uses for this/our softbody needs?

 

[Velomous]

PS: While I was doing this test I discovered my love for runtime MeshDeforming and Materials again.
I feel the desire to dive deeper into these topics now, for example AI supported

You must be registered to see the links

(which should be the next step compared to the classic morphing used above) and to explore the new Mat possibilities with Nanites further in combination.

Have any of you already had practical experience with MLD?

I don't think so, the ML Deformer is extremely new tech, very few people have played with it. I found a video about training it though, might have been this one


I'm very curious to know if morphs break it or not, but i strongly suspect they do, and if they do I won't be able to use it.

 

[razfaz]

I don't think so, the ML Deformer is extremely new tech, very few people have played with it. I found a video about training it though, might have been this one


I'm very curious to know if morphs break it or not, but i strongly suspect they do, and if they do I won't be able to use it.

Yah, I guessed so too. Thats why I was asking. Early Birds and so on.
The second intention was to get neurotic researchers like me to get involved and find satisfaction. hrhr.

PS: Nice demo vid, thats what I'm talkin' about. There are some other demos where you can see the "Muscle/Cloth" simulation making use of MLD better.

You must be registered to see the links

My personal goal is to get rid of hours of "offline" rendering in the future and have more time for creativity instead! You can only be productive in creative processes if the time from idea to result is as short as possible.

 

[darkevilhum]

@SimpleTimes and who might concern,

as promised: UE 5.5 Nanite SKM incl. Morphs and Tessellation Test = Check!
View attachment 3760472

I don't see the morphs actually taking affect in the editor view on the left? Presumably the mesh isn't rendered using nanite on the right in the SKM Viewer/Editor window? Or is it?

 

[SimpleTimes]

regarding ML Deformer, i don't think it's super necessary for us, i'm quite happy with the results of JCM morphs which already exists for DAZ Meshes and Morphs.

If you are really interested in ML Deformer you may want to check out the Daz2Unreal Discord, iirc a few people there played around with that.

I'm very curious to know if morphs break it or not, but i strongly suspect they do, and if they do I won't be able to use it.

i'm 99% sure they break, iirc the ML Deformer creates a bunch of corrective Morphs, so it ends up as a JCM system under the hood.

I don't see the morphs actually taking affect in the editor view on the left? Presumably the mesh isn't rendered using nanite on the right in the SKM Viewer/Editor window? Or is it?

i don't think that the data is live updated to instances in the level (the SKM Component holds an own set of MorphValues which it uses to evaluate/render the Mesh)

 

[razfaz]

I don't see the morphs actually taking affect in the editor view on the left? Presumably the mesh isn't rendered using nanite on the right in the SKM Viewer/Editor window? Or is it?

Yap, the left is the editor instance which don't sync when in AssetEdit mode.
How ever, changing a simple morph target weight value dynamically in play mode should work as intended, but I'll create an ingame UI "ButtSlider" widget tomorrow to test the changing of a simple Val (MorphTarget weight) on runtime in play mode as well. Which should do, nothing less or more, exactly the same as using a morph weight slider when in the Asset Edit Mode and looking at the preview (as can be seen on the right side in the vid) which is a playmode instance, but only using/showing the isolated Asset edited, but who knows? Will report back.

Personal note to myself: Watch out and do only show what is important when making snips/vids

regarding ML Deformer, i don't think it's super necessary for us, i'm quite happy with the results of JCM morphs which already exists for DAZ Meshes and Morphs.
If you are really interested in ML Deformer you may want to check out the Daz2Unreal Discord, iirc a few people there played around with that.
i'm 99% sure they break, iirc the ML Deformer creates a bunch of corrective Morphs, so it ends up as a JCM system under the hood.
i don't think that the data is live updated to instances in the level (the SKM Component holds an own set of MorphValues which it uses to evaluate/render the Mesh)

Thanks for the info and the discord tip, I may join.

 

[darkevilhum]

PS: While I was doing this test I discovered my love for runtime MeshDeforming and Materials again.
I feel the desire to dive deeper into these topics now, for example AI supported

You must be registered to see the links

(FBX+Alembic (.abc) which should be the next step compared to the classic SKM-Morphing used above) and to explore the new Mat possibilities with Nanites in combination.

Does anyone of you already have experience with MLD and can eval conceivable possible uses for this/our softbody needs?

My current test cases with MLD put me off using it. While it is a great proof of concept. From what I could gather, It's primary purpose is to basically make it easier to setup corrective morph systems. But outside of that, it doesn't change anything, you still have to make/get all the morphs you want for your character.
I had hoped that they would take it further and train an actual model on human anatomy so we could just give it a mesh and it would generate deformations on the fly. Now that would be cool. But that's not what this does.

So once you have your mesh file with a bunch of morphs/jcms etc. You would then typically setup some JCM logic for your morphs in UE via some control rig or animation blueprint etc.
With the MLD however you would feed your mesh and morphs into it to train it on how to deform your mesh. Then let it handle all of that after tweaking and adjusting as needed at the training stage. So you essentially gain some potential time saved, but you lose any control over the deformations after making the morphs.

As for the usability of this for some of our discussed topics; It's not really applicable to any soft body-esque things. This will always be the case when working with morphs as they can simulate great jiggle and affects but they'll never have any collision/physics interactions with anything.
They could be used as a "result" of a collision in a similar way that some developers have used morphs to simulate jiggle by having some physical spring constraint which drives the 0-1 morph value of multiple directional morphs. But at that point you might as well make a shader do the same thing via vertex displacement to save some performance.

 

[razfaz]

Sorry guys, Morph Targets doesn't work in UE 5.5. PlayMode when activating Nanites for a SKM.
At least not yet in the current 5.5 development state. May change in the future on release, but for now... nada.
Sorry again for the nonsense I wrote before. Well, learned something again.
And it seems that the AssetEditor PreviewWindow is always using basic SKMs without Nanites enabled.
View attachment 2024-06-23_14h05_13.mp4

 

[Velomous]

Sorry guys, Morph Targets doesn't work in UE 5.5. PlayMode when activating Nanites for a SKM.

Maybe it'll be fixed by the time 5.5 is actually released? hopefully? I mean it's a pretty major issue they've gotta be aware of it, morphs are used a lot for many types of games.

Btw reason i've had little to contribute lately is because i've been focusing my efforts in a different direction, i've gotten really lost in trying to make a mechanism to make a dildo work like, well, like we all know we want it to work (it's more complicated than i thought, in theory it's simple, in practice, so many problems) and once i've done that i'll play around a bit with collision, then i'm going to go back to some courses i've left unfinished on

You must be registered to see the links

(do recommend, it's a good course) and niagara effects at which point i'll come back and try messing around with

You must be registered to see the links

.

Naturally that'll take a while though, but currently i believe that the spring bone approach demonstrated by darkevilhum will probably be the best fit for my project.