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

[animetiddyenthusiast]

Given that I've now tried an implementation of all the methods discussed in this thread including a shader based approach with a custom physics solution (not the shader that I shared earlier) I think my personal choice to fall back on multi-bone physics was at least worth sharing. It just ends up being the most realistically usable solution for any project and without any scalability concerns.

The only circumstance I think where it's still worth chasing a soft body solution would be in a situation where the project only has 2-3 max characters running the soft body simulation at a time. Ontop of this, you'd likely want some very close camera angles or some specific game feature/mechanic to take advantage of the soft body, such as some kind of interaction or touch. VR is the best example of this. For anything else, I wouldn't recommend devoting development time/resources to this.

The nice thing about this solution is that it meshes perfectly with all of the existing tooling in UE5. So with some decently setup physics shapes in the physics asset, all of these "soft" body parts collide with everything else, including other actors.

Examples of my results (3 bones per breast, 3 bones per glute, 2 bones for the thighs (front and back))
The difference in jiggle is subtle at these constraint values (I'm going for something a little more realistic/subtle for this particular character) however the difference is night and day between a single bone constraint and this.

Spoiler: NSFW

You don't have permission to view the spoiler content. Log in or register now.

bro that is literally perfect what the hell?? Damn near ideal level of give and bounce back. If I could get that going with reasonably low latency VR hand collision/grabbing you may never get me out of the headset.

Had some freetime today and felt the need for some AI-Assisted-Coding.

This challenge is getting a PITA because of the need of performance.

The more I try to put calcs to the GPU for the performance sake, the more I have to struggle with lowlevel things like parallel Shader-Buffers and its management, Memory Addressing and so on. Which I expected, but have to rethink it partly now.

The more I get LowLevel the more it will make such a plugin very hard to maintain in the future.

So, I decided to revert some performant LowLevel Code in exchange of performance, because I don't want to get back everytime the UE API changes it's version just on the 3rd digit (x.x.1)

So, thats my current state and journey for today|night.
Grok3 helped me a lot porting the code from UE 4.X to 5.5.X and spared me ages of time fixing things just by discussing debugger and|or exceptions output.

Again, I can recommend! 10x timesaver, at least for the ones who are more or less fluent in UE-API & C++ - which I'm not, but have always the learning mode ON - and therefore able to fix and maintain such mixed code of Human+AI Code.

God, I fear Oldschool-Coders will have a hell of work todo in the near future to fix all the AI generated code produced by Ppl. who can't maintain and fix the created code created and may be used by consumers or companies by a larger scale.

How ever, here the "BASIC" Shader (HLSL) that I use for testing (see attach). The Shader is very Basic, because I'm focused on the C++ Implementation of the Plugin first, which still throws runtime memory acc. vios at the moment of writing... *argh* -.-

Your shader you sent looks okay so far. One thing I'd note is that the skinning shaders in 5.5 are virtually identical to 4.2x. There are some differences from the switch to double precision floats and change in standards for number of bone influences but they're pretty small. If you're doing shader based work I don't think there's a huge concern with future proofing. That being said I wonder if perhaps we'd benefit from just directly altering or extending the skinning shader

 

[razfaz]

You mean with relation to the multi-bone technique? Yep those all work fine too.

The only caveat I've encountered is if you use morphs for very significant character customization, such as normal breasts to huge breasts. In this circumstance, the collision shapes for the breasts would need to be updated to match the new size.
This isn't too difficult to do. But can become a cumbersome bit of work if you have a lot of these.

But generally speaking, using morphs for customization in this way is easily offset by instead using bone scaling (which is the OG/Standard way of doing character customization for the body).

In my current project I'm using a mix of bone scaling and morphs for character customization because morphs make more sense for some things like finer details/muscle toning etc, and less for others such as a general size/width/depth/length.

Yes, I still can't get over my self to alter skeletons with additional bones, because I was always used to get those things from another department.
I love to learn and seek other perspecives that may fill some of my gaps.

I think I'll burry my current approach (thanks to You), becuase You are bloody right, it hurts a bit, but it has to be done!

We have to take the look more into the technical future. Therefore I took my learnings and my "Evil Plan", re-evaluted it and crushed all the old things that were deprecated. YEAH! -> Feels good.

Anyway.
I have Good and Bad News to report regarding our lovely UE-API in this regard,
as follows:

Good:
- [Nanite-Core] Is now a part of the core and not experimental anymore.
- [Nanite-DSKM] Still experimental, but for the first time basic functions can be tried out now for the public since UE 5.5.3+ (<- Big one & more to come!)

Bad:
- Your older Code as a Developer will probably not work anymore, especially regarding vertex buffers (RHI) and so on, big pain ahead. *as always*
- Experimental DynamicNaniteSK has no extra collision solution, that means that the collision still falls back on the base mesh and is NOT (at the time of writing) reacting to the granulated nanite mesh.

Some hacks may be possible to make collisions work with the granulated nanite mesh, using Rays or other things, I dont know.... just be creative!

I just hope You Guys have fun with the current challenge and I wish all the best and happy coding!

 

[darkevilhum]

Yep, I was in the same boat honestly for the longest time. I wanted to out source any 3D assets/skeletons and not mess with them. But in order to achieve the ideal results and fix problems it becomes necessary. I still rely on Daz3D personally but with a work flow that has enough flexibility to achieve my goals.

For anyone interested, my current project will have 1 female player character, and multiple male and female NPCs. With females being the sort of focus of the content. (Male target audience).

With that in mind*, my work flow evolved through the following thought process and actions:

• Determine the features I want for both females and males that would depend on a particular skeleton hierarchy or adjustment. Such as; Jiggle/attachments/clothing nodes/bone based joint correction or morph based? etc
• Once I have a clear idea of what I want and therefore what I need, I use Daz3D to alter the skeletons for my player character and the first generic Male in my project. These skeletons (male and female) become the base skeleton for all future characters and clothing.

With this base in place, I can use handy plugins like Daz2Unreal to send clothing and characters over to UE5. This works a solid 75% of the time. When it doesn't there is usually a mismatch between the base body morphs and the clothing or the weighting isn't fantastic. In these instances I can just load up blender and manually make corrections fairly quickly and then reimport into UE5.

I also created some easy-animate control rigs for both skeletons in UE5. This lets me create animations directly inside of UE5. Very handy.

 

[razfaz]

Hey everyone,

There is a long list of exciting technological advancements on the horizon (not only AI, but others as well),
so we should combine our stubborn wills, common interests, and skills to stay updated, or even better, get ahead!

Real-time networking using Discord, for example, would be advantageous for transferring ideas and portions of knowledge;
from there, we'll see where it takes You and us.

Users who should form and could be the base for such a win/win network:

darkevilhum Velomous mikeblack JigglySquish RawDarkness TheExordick


P.S.: This reminds me of planning and creating a new Guild in WoW back in the days to tackle the most nasty End Game Bosses. HrHr.

 

[Velomous]

I'm trying to be anonymous, at least keeping this id as distinct from my other online ids as reasonably possible.

Discord doesn't allow that at all, doxing yourself is part of the registration process so I'm afraid I'll have to decline.

 

[razfaz]

I see, yeah. ok.

 

[Velomous]

This post is gonna be a bit ranty and mildly off topic.

I have been considering switching to another engine. At least just to see what it's like to do this there. We've already seen how it goes with unreal, there are ways, but ultimately it all boils down to how much research and work we're willing to put into it. How far we're willing to dig into c++ code or what other features we're willing to sacrifice. We always have to sacrifice something for this, be it months of time developing in c++ to get the perfect result, or sacrificing good collisions or something along those lines...

If some incompetent moneygrubbers managed to make a game that does all this stuff in unity (virt-a-mate), I wonder how hard it can really be to do it there. I'm not so deep into my project htat I can't switch engines yet so it's worth a try actually. I really like the workflow in unreal tho... I like blueprints, i hated them at first but they grew on me fast.

-----------------------------

The other decent option would be to use an older version of unreal. Maybe even unreal 4. Or some particular older version of unreal 4 even.

I mean if you've been keeping track there is a growing list of reasons to avoid unreal 5. I'm sure you've noticed the stuttering, even in a template project you'll get stuttering! Most ue5 games stutter a lot, epic games blames devs for it (but fortnite stutters a lot too lol);


A video explaining that nanite ain't all it's cracked up to be, channel also has

You must be registered to see the links

explaining how bad (fake even) optimization in modern games such as TAA is destroying graphics. You can't just turn TAA off in unreal 5, I mean you can but it breaks a shitload of features. You need to leave it on, turning it off costs too much. I'm sure you guys have noticed the ghosting when you're playing in the editor, TAA is the primary culprit. And lumen relies heavily on it.

The thing about TAA is that it looks good on still frames. Screenshots. It breaks fast in motion, ghosting and smearing galore.

TAA dependence and Stuttering are the main reasons to avoid UE5 in general (although I think ue4 might have had the TAA issue as well, i think maybe there was an option to use fxaa or something instead though, fxaa is ass, but it still looks better than TAA).

In our context however, it's per poly collision. Finding a version of the engine (or just a way in any version really) where per poly collision works properly... Would probably solve our most difficult issue. No matter what technique we use for jiggle, if we're modifying the body with morphs, something like this is the only way to have accurate collisions. I remember playing with it and giving up on it before but I don't remember the details.

But also an older version of ue will support tesselation which means we could try using the methods we have deduced might have been used by the nauaghty sandbox dev for the softbody effect.

Edit: Unity has a function called mesh colliders, it's similar to per-poly collision, it can be finicky to get working on rigidbodies (unity for skeletal mesh) but seems people tend to get it working by setting it to convex. As for per-poly collision in unreal,, I read somewhere that a guy managed to get it working by editing the blueprint via a text editor (e.g. ticking it in the editor didn't actually enable it in the code so he ediited the actor directly via text editor or something like that to enable it; do note you need to be using a pawn actor and not a character actor to use this cuz of the capsule collider that comes with the character actor getting in the way otherwise), which is worth looking into.

As for softbody, they are probably just using a similar bone based approach as darkevilhum, they're just not as good at it as he is (as I mentioned, they're incompetent) but it still looks ok. They might also be using a plugin like

You must be registered to see the links

.

This took minutes of research so I suppose I was right about doing it in unity being uncomplicated.

Bone based jiggle is the standard way to do things for a reason I guess, reaching the same conclusion as darkevilhum on that one here. There might be better ways but this is the well travelled path. The real tricky part is always going to be collisions on morphable skeletal meshes; and jiggle adjustments based on the meshe's modified proportions.

I think the only way to have those collisions using unreal's traditional physics asset colliders would be to generate them on the fly by somehow measuring the model's dimensions and creating the colliders dynamically. Which I am not inclined to do. (engine already has a function for this but we'd have to finetune it and optimize it to death to make it work like we need).

Edit2: Did some more digging into unity, if you need reasons to consider unity.

You must be registered to see the links

has them.

Some of those things I can't even think of how to implement in unreal. Like

You must be registered to see the links

and

You must be registered to see the links

(I mean we've played with that a bit ago, we even got somewhere with it, but getting it to that level? I just don't see how, don't see how in unity either, but at least it's been done there apparently). He also apparently does make tutorials, but

You must be registered to see the links

.

 

[mikeblack]

Edit2: Did some more digging into unity, if you need reasons to consider unity.

You must be registered to see the links

has them.

Some of those things I can't even think of how to implement in unreal. Like

You must be registered to see the links

and

You must be registered to see the links

(I mean we've played with that a bit ago, we even got somewhere with it, but getting it to that level? I just don't see how, don't see how in unity either, but at least it's been done there apparently). He also apparently does make tutorials, but

You must be registered to see the links

.

Sakura Rabbit shows great stuff for Unity.

For wrinkling there are options available in UE. Like faking it with materials or blend shapes /

You must be registered to see the links

.

 

[darkevilhum]

This post is gonna be a bit ranty and mildly off topic.

I have been considering switching to another engine. At least just to see what it's like to do this there. We've already seen how it goes with unreal, there are ways, but ultimately it all boils down to how much research and work we're willing to put into it. How far we're willing to dig into c++ code or what other features we're willing to sacrifice. We always have to sacrifice something for this, be it months of time developing in c++ to get the perfect result, or sacrificing good collisions or something along those lines...

If some incompetent moneygrubbers managed to make a game that does all this stuff in unity (virt-a-mate), I wonder how hard it can really be to do it there. I'm not so deep into my project htat I can't switch engines yet so it's worth a try actually. I really like the workflow in unreal tho... I like blueprints, i hated them at first but they grew on me fast.

-----------------------------

The other decent option would be to use an older version of unreal. Maybe even unreal 4. Or some particular older version of unreal 4 even.

I mean if you've been keeping track there is a growing list of reasons to avoid unreal 5. I'm sure you've noticed the stuttering, even in a template project you'll get stuttering! Most ue5 games stutter a lot, epic games blames devs for it (but fortnite stutters a lot too lol);


A video explaining that nanite ain't all it's cracked up to be, channel also has

You must be registered to see the links

explaining how bad (fake even) optimization in modern games such as TAA is destroying graphics. You can't just turn TAA off in unreal 5, I mean you can but it breaks a shitload of features. You need to leave it on, turning it off costs too much. I'm sure you guys have noticed the ghosting when you're playing in the editor, TAA is the primary culprit. And lumen relies heavily on it.

The thing about TAA is that it looks good on still frames. Screenshots. It breaks fast in motion, ghosting and smearing galore.

TAA dependence and Stuttering are the main reasons to avoid UE5 in general (although I think ue4 might have had the TAA issue as well, i think maybe there was an option to use fxaa or something instead though, fxaa is ass, but it still looks better than TAA).

In our context however, it's per poly collision. Finding a version of the engine (or just a way in any version really) where per poly collision works properly... Would probably solve our most difficult issue. No matter what technique we use for jiggle, if we're modifying the body with morphs, something like this is the only way to have accurate collisions. I remember playing with it and giving up on it before but I don't remember the details.

But also an older version of ue will support tesselation which means we could try using the methods we have deduced might have been used by the nauaghty sandbox dev for the softbody effect.

Edit: Unity has a function called mesh colliders, it's similar to per-poly collision, it can be finicky to get working on rigidbodies (unity for skeletal mesh) but seems people tend to get it working by setting it to convex. As for per-poly collision in unreal,, I read somewhere that a guy managed to get it working by editing the blueprint via a text editor (e.g. ticking it in the editor didn't actually enable it in the code so he ediited the actor directly via text editor or something like that to enable it; do note you need to be using a pawn actor and not a character actor to use this cuz of the capsule collider that comes with the character actor getting in the way otherwise), which is worth looking into.

As for softbody, they are probably just using a similar bone based approach as darkevilhum, they're just not as good at it as he is (as I mentioned, they're incompetent) but it still looks ok. They might also be using a plugin like

You must be registered to see the links

.

This took minutes of research so I suppose I was right about doing it in unity being uncomplicated.

Bone based jiggle is the standard way to do things for a reason I guess, reaching the same conclusion as darkevilhum on that one here. There might be better ways but this is the well travelled path. The real tricky part is always going to be collisions on morphable skeletal meshes; and jiggle adjustments based on the meshe's modified proportions.

I think the only way to have those collisions using unreal's traditional physics asset colliders would be to generate them on the fly by somehow measuring the model's dimensions and creating the colliders dynamically. Which I am not inclined to do. (engine already has a function for this but we'd have to finetune it and optimize it to death to make it work like we need).

Edit2: Did some more digging into unity, if you need reasons to consider unity.

You must be registered to see the links

has them.

Some of those things I can't even think of how to implement in unreal. Like

You must be registered to see the links

and

You must be registered to see the links

(I mean we've played with that a bit ago, we even got somewhere with it, but getting it to that level? I just don't see how, don't see how in unity either, but at least it's been done there apparently). He also apparently does make tutorials, but

You must be registered to see the links

.

Just to add to this, if you want real soft body simulation with collision and you want the control to manipulate those colliders as you see fit (for morphable characters for example) in Unity, I would recommend this plugin

You must be registered to see the links

. I used this in my project when I started out with Unity.

Though I moved to Unreal because Unity simply cannot handle strong joint corrective morphs. The normals break because Unity does not support tangent recalculation like Unreal does. This was a deal breaker for me as I want to be able to put my female characters in any anatomical pose and correct the joint to look natural.

 

[TheExordick]

This post is gonna be a bit ranty and mildly off topic.

I have been considering switching to another engine. At least just to see what it's like to do this there. We've already seen how it goes with unreal, there are ways, but ultimately it all boils down to how much research and work we're willing to put into it. How far we're willing to dig into c++ code or what other features we're willing to sacrifice. We always have to sacrifice something for this, be it months of time developing in c++ to get the perfect result, or sacrificing good collisions or something along those lines...

If some incompetent moneygrubbers managed to make a game that does all this stuff in unity (virt-a-mate), I wonder how hard it can really be to do it there. I'm not so deep into my project htat I can't switch engines yet so it's worth a try actually. I really like the workflow in unreal tho... I like blueprints, i hated them at first but they grew on me fast.

-----------------------------

The other decent option would be to use an older version of unreal. Maybe even unreal 4. Or some particular older version of unreal 4 even.

I mean if you've been keeping track there is a growing list of reasons to avoid unreal 5. I'm sure you've noticed the stuttering, even in a template project you'll get stuttering! Most ue5 games stutter a lot, epic games blames devs for it (but fortnite stutters a lot too lol);


A video explaining that nanite ain't all it's cracked up to be, channel also has

You must be registered to see the links

explaining how bad (fake even) optimization in modern games such as TAA is destroying graphics. You can't just turn TAA off in unreal 5, I mean you can but it breaks a shitload of features. You need to leave it on, turning it off costs too much. I'm sure you guys have noticed the ghosting when you're playing in the editor, TAA is the primary culprit. And lumen relies heavily on it.

The thing about TAA is that it looks good on still frames. Screenshots. It breaks fast in motion, ghosting and smearing galore.

TAA dependence and Stuttering are the main reasons to avoid UE5 in general (although I think ue4 might have had the TAA issue as well, i think maybe there was an option to use fxaa or something instead though, fxaa is ass, but it still looks better than TAA).

In our context however, it's per poly collision. Finding a version of the engine (or just a way in any version really) where per poly collision works properly... Would probably solve our most difficult issue. No matter what technique we use for jiggle, if we're modifying the body with morphs, something like this is the only way to have accurate collisions. I remember playing with it and giving up on it before but I don't remember the details.

But also an older version of ue will support tesselation which means we could try using the methods we have deduced might have been used by the nauaghty sandbox dev for the softbody effect.

Edit: Unity has a function called mesh colliders, it's similar to per-poly collision, it can be finicky to get working on rigidbodies (unity for skeletal mesh) but seems people tend to get it working by setting it to convex. As for per-poly collision in unreal,, I read somewhere that a guy managed to get it working by editing the blueprint via a text editor (e.g. ticking it in the editor didn't actually enable it in the code so he ediited the actor directly via text editor or something like that to enable it; do note you need to be using a pawn actor and not a character actor to use this cuz of the capsule collider that comes with the character actor getting in the way otherwise), which is worth looking into.

As for softbody, they are probably just using a similar bone based approach as darkevilhum, they're just not as good at it as he is (as I mentioned, they're incompetent) but it still looks ok. They might also be using a plugin like

You must be registered to see the links

.

This took minutes of research so I suppose I was right about doing it in unity being uncomplicated.

Bone based jiggle is the standard way to do things for a reason I guess, reaching the same conclusion as darkevilhum on that one here. There might be better ways but this is the well travelled path. The real tricky part is always going to be collisions on morphable skeletal meshes; and jiggle adjustments based on the meshe's modified proportions.

I think the only way to have those collisions using unreal's traditional physics asset colliders would be to generate them on the fly by somehow measuring the model's dimensions and creating the colliders dynamically. Which I am not inclined to do. (engine already has a function for this but we'd have to finetune it and optimize it to death to make it work like we need).

Edit2: Did some more digging into unity, if you need reasons to consider unity.

You must be registered to see the links

has them.

Some of those things I can't even think of how to implement in unreal. Like

You must be registered to see the links

and

You must be registered to see the links

(I mean we've played with that a bit ago, we even got somewhere with it, but getting it to that level? I just don't see how, don't see how in unity either, but at least it's been done there apparently). He also apparently does make tutorials, but

You must be registered to see the links

.

This is not the time nor the place to discuss this but we all know TI channel. The guy is just a kid full of shit who tried to lure people into funding him 900 k$ to "rebuild" UE5 source code.

The engine is just a toolbox which gives you a set of tools. You, as the developer need to know how to use the tools, when to use them and how to optimize. Epic did some marketing to sell their product telling people that nanite and lumen where some magic tools that needed no optimization and would make your game magically run smoother then ever. We should be smarter than this and see marketing for what it is.

It was the same shitstorm many years ago with raytracing technology.

That being said, you are free to use any engine you want and see if you find someone that already solved the problem you are encountering or you can try to find the solutions you are looking for by yourself. If you find them, please share them for the future developers to come. (in any engine)

 

[Velomous]

Just to add to this, if you want real soft body simulation with collision and you want the control to manipulate those colliders as you see fit (for morphable characters for example) in Unity, I would recommend this plugin

You must be registered to see the links

. I used this in my project when I started out with Unity.

Though I moved to Unreal because Unity simply cannot handle strong joint corrective morphs. The normals break because Unity does not support tangent recalculation like Unreal does. This was a deal breaker for me as I want to be able to put my female characters in any anatomical pose and correct the joint to look natural.

That looks cool, I know about another one called obi softbody, it's particle based (so possibly replicable in unreal if we were to go far enough with the particle softbody i tested a while ago), i suspect the vertexmotion shader solution you shared is better, seems it's not being maintained though, dev's been quiet for the better part of a year whereas obi was last updated about 2 weeks ago.


(You can see the collisions working great there, the rest not so much, but it was 3 years ago)

Your info on joint corrective morphs might be out of date, I'm pretty sure I saw sakura rabbit using them to great effect in one of his reels (either the 2022 or 2024 one), I suppose that's a magician though so him being able to do it doesn't mean it's easy.

This is not the time nor the place to discuss this but we all know TI channel. The guy is just a kid full of shit who tried to lure people into funding him 900 k$ to "rebuild" UE5 source code.

The engine is just a toolbox which gives you a set of tools. You, as the developer need to know how to use the tools, when to use them and how to optimize. Epic did some marketing to sell their product telling people that nanite and lumen where some magic tools that needed no optimization and would make your game magically run smoother then ever. We should be smarter than this and see marketing for what it is.

It was the same shitstorm many years ago with raytracing technology.

That being said, you are free to use any engine you want and see if you find someone that already solved the problem you are encountering or you can try to find the solutions you are looking for by yourself. If you find them, please share them for the future developers to come. (in any engine)

Yeah you're absolutely right that it's the developer, not the engine, that makes the game. Engines are tools, but tools can be faulty, and with game engines it's not a question of if they're faulty, it's a question of how.

Whatever his motives, TI has dug into one of the most

You must be registered to see the links

with unreal's rendering pipelines (ghosting, due to TAA and TSR) and poked some holes into nanite to demonstrate that nanite would perhaps have served us better as a situational tool than an always on for everything tool. Nanite is amazing, but it can be less than ideal in some situations.

And unreal has a real problem with traversal stutters, it's not just the developers fault there's something inherent to unreal that makes it a more common issue than it should be. Shader stutter is a dev issue tho, should compile those shaders when the level loads not when the shader loads. The traversal stutters are quite a lot more difficult to deal with though, it takes an exceptionally good developer to resolve those and unreal seems to have a bit of a habit of letting happen.

And these are issues that every unreal dev needs to be concerned about too, because they will fuck them over. They already have fucked some big name games over, like stalker, and jedi survivor for two.

I've installed and fired up unity just to see what it's like, off the bat i noticed 3 things.
1. Minimal ghosting even with TAA (for some reason it's a lot better, I think the ghosting in unreal might not just be caused by TAA, could be something to do with lumen, something else than just it's dependence on taa that is).
2. No stutters, as I mentioned, I'd sometimes experience stutters in the basic 3rd person template while walking around, unity was smooth.
3. Superior performance; I ran unity on my igpu without issues, if I try the same with unreal it's laggy as hell (keep in mind, both cases with a small viewport, with a maximized viewport they both lag a lot on the igpu; but in a nutshell I can develop on unity with just my igpu, i need my dgpu to develop on unreal).

I also noticed that disabling TAA is fairly trivial in unity and doesn't disrupt a great deal of graphical features like it does in unreal (no TAA dependence in unity) so ghosting can be entirely eliminated there.

But yeah, I'm gonna play around with unity a bit, it's gonna take a while, I will need to import a model and some morphs (I suspect i'll go for one of the daz genesis models, hopefully it's less of a pain in the ass to import to unity than unreal; morphs are easy to get for them too), then i'll set up a character creator and basic animations to test jiggle and such, and then i'll start testing the jiggle, not sure how much I'll focus on it either so it could take weeks or months, but I will share my results once I have them; since I'm sure you're as curious as I am, and it's all kinda adjacent anyhow (ways to do it on unity will likely be achievable on unreal too; but for both engines bone based jiggle is standard).

 

[darkevilhum]

Your info on joint corrective morphs might be out of date, I'm pretty sure I saw sakura rabbit using them to great effect in one of his reels (either the 2022 or 2024 one), I suppose that's a magician though so him being able to do it doesn't mean it's easy.

Yeah relatively "safe" morphs will work fine in Unity, it's when you want to do slightly more extreme morphs, for example correcting a humanoid knee when the leg is fully compressed (like when you kneel). That's pretty much the joint at around 150-160 degrees of motion. After about 120-130 degrees morphs will break in Unity. Sakura Rabbit basically creates show cases so he can cheat in his examples because there's no need for them to be functional or usable outside of that show case.

 

[JigglySquish]

Yeah relatively "safe" morphs will work fine in Unity, it's when you want to do slightly more extreme morphs, for example correcting a humanoid knee when the leg is fully compressed (like when you kneel). That's pretty much the joint at around 150-160 degrees of motion. After about 120-130 degrees morphs will break in Unity. Sakura Rabbit basically creates show cases so he can cheat in his examples because there's no need for them to be functional or usable outside of that show case.

Yeah, to do knees in a way where you can have characters take actual extreme positions (like sitting on their heels), you need to make them closer to the way that anatomical knees actually work.

When you bend your knee, the knee rotates yes, but it also translates and opens. Your femur isn't a perfect circle, instead, as it rotates on the tibia the pivot pulls back. Actually making that work in a rig is not particularly difficult, but it is kinda fussy.

 

[NMMMN]

need to make them closer to the way that anatomical knees actually work.

Agreed, its all in the prep. a model needs to have the verts, proper topology to let the physics deform nicely

not particularly difficult, but it is kinda fussy.

+1 best way to describe it


check the last minute to see the vids results, really good tutorial:

I've installed and fired up unity just to see what it's like

welcome to the dark side, we have cookies
the performance is deceptive at first bc of the package manager doesnt front load the editor, keeping good performance will requiring smart handling of whats running in the scene and in view. keep your draw calls to a minimum, make sure to check the stats tabs for the CPU and GPU ms (milliseconds time) when every you make changes to keep track of the performance

here's my layout i find it flows better scene window on top / game view on bottom / hierarchy to the right etc:

Spoiler: unity layout

You don't have permission to view the spoiler content. Log in or register now.

I think obi is the way to go,

Unity physics options:

• For simple jiggle/movement → Use Vertex Shader (GPU)
• For muscle & skin deformation in characters → Use Blend Shapes & Bones
• For real soft-body physics with interaction → Use Obi Softbody
• For custom physics (if you have time) → Implement a Mass-Spring System (DOTS Physics)
• For high-end soft-body physics (if Nvidia GPU) → Use Nvidia Flex (proprietary poop)

Cheers gl ^ ^

 

[Velomous]

I had an interesting thought... Remember SMP from Skyrim? That's a softbody implementation, or at least a softbody imitation, it was used for hair physics, cloth physics and jiggle physics. It was pretty efficient too I think (kinda had to be).

Something else cool about SMP, it's

You must be registered to see the links

, it ran entirely on CPU, and only one core I think.

As is

You must be registered to see the links

which is a rewritten more efficient version. It also has CUDA support though it's disabled by default so it defaults to running on cpu as well.

But yeah they're open source, the code is there, it's all MIT license so we can use it quite easily just about however we want. We obviously can't just copy that code and use it(cuz different physics engine), but we could study it and learn from it to make our own softbody implementation that serves our actual needs.

It would be a lot of work, but it's a solid option if someone want's to go that route, however I'd first try the chaos cloth route. I've wanted to go there but I haven't because I'm not much of a modeller and prepping the model for that requires at least some basic blender knowledge that I haven't learned yet. It's probably only a matter of time before I start dabbling with it though.

Cool things

Thanks for the useful tips! Always keeping the profiler handy, dunno why i didn't think of that yet. Seems to be overall the same game as unreal, minimize drawcalls, make efficient code. I suppose it'd be like that in any game engine.

Vendor specific physics solutions seem like a bad idea, who would want only half the gamers to be able to fully enjoy the game? It's a concept nvidia still fails to grasp.

some guy implemented a mass spring system

You must be registered to see the links

, it's open source too, looks interesting, might be able to use it for some physics interactions. But yeah it's likely I'll end up with obi, i'd like to have a way of testing it without paying though. Problem with plugins is that you don't know if they're right until you've used them a bit, fronting the cash for something you might not end up using is just bad business sense; unless you have unlimited cash.

I kinda like the unreal layout (it's grown on me somehow) so I just copied that, then added the profiler down next to the console, I'm pretty happy with this setup actually.

Spoiler: Screenshot

You don't have permission to view the spoiler content. Log in or register now.

I have a newfound respect for game devs that made succesful unity 3D games, you know, valheim, sons of the forest and such. Learning this engine is a bit of a minefield, perhaps even moreso than Unreal. (The Forest devs tripped a lot of those mines when they made the original The Forest, but as far as unity games are concerened, Sons of the forest was a coding masterpiece, game performed so damn well!)

Spoiler: Learning unity vs learning unreal for new devs rant

You don't have permission to view the spoiler content. Log in or register now.

Once I finish playing with the rite of passage (input, movement, camera; the barebone basics which I'm doing to get a grip on how to work with unity) I'm gonna shift my focus back to what I'm really after here, but as I said before, gonna have to figure out importing a daz model to unity, and It's probably gonna take multiple tries to get that one right since I have virtually no blender experience.

 

[NMMMN]

yeah i havent shelled out the money for obi yet
best deals are on cyber monday, though i think its one of those assets that doesnt go on sale often

i did however get a few other lesser evils (though hardly tested):

Spoiler: other unity assets / soft body things

You don't have permission to view the spoiler content. Log in or register now.

I feel so seen and validated lol, as unity hobbyist dev im still trying to figure out the movement and camera xD
those unity tutorials lol, probably why my instinctive first advice is check the profiler

there is Unity's official character controller

You must be registered to see the links

and

You must be registered to see the links

package, but using them always felt like de-bloating an install of windows, so ive been working on my own

Spoiler: unity rb movement

You don't have permission to view the spoiler content. Log in or register now.

this might be your kind of tutorial

You must be registered to see the links

for the camera... gl ^ ^; im still ironing out the kinks in mine,
im thinking of sphere casting a ray from the player to the camera then offsetting it closer than the hit distance to prevent it from clipping

 

[Velomous]

yeah i havent shelled out the money for obi yet
best deals are on cyber monday, though i think its one of those assets that doesnt go on sale often

Actually didn't take me long to find out there's a decent

You must be registered to see the links

. You can get it there, it'll allow you to at least play with it before deciding if you wanna shell out the money for it or not.

It's interesting you pointed out a bullet physics plugin. that's the physics engine skyrim uses, so it should be usable with the SMP code I linked to in my last post without changing the code all that much.

The third person starter asset at a glance looks like it'd probably have proper input management, since it requires the new input system, but i've seen people use that and then just contiune doing it the same way as the old input system so I wouldn't be too sure but I'll give them the benefit of the doubt.

As for movement, I've seen the code you sugggested for moveposition and tried it, but it's not very good; It moves the character all right but there's no acceleration or deceleration handling, just from standstill to maxspeed in an instant, then stops in an instant. A lerp might help with that but that still leaves deceleration, I mean it just instantly stops; I also don't know why you think the moveposition is interpolated. Do you mean it uses rigidbody interpolation (smooths motion between the 50fps of a rigidbody)? But why wouldn't velocity work that way too? Are you sure that information is correct?

As for the velocity code, I've repeatedly seen warnings to not do that. Including

You must be registered to see the links

. I know how to do it in a way that mitigates most of the issues with it but based on some nuance it might not be enough. The way you're doing it is definitely

You must be registered to see the links

though, and seems like one of the things you might lift off one of aforementioned bad unity tuts. (The way to do it that mitigates the issues is to add velocity instead of set velocity, but it comes at a cost of more complex code, however it also allows you to precisely control acceleration)

I will probably actually stick to addforce, that's the only way to have good velocity based movement that interacts as expected with physics. If I want the kind of movement where the character will bulldoze through any other rigidbody I would use moveposition.

That video was very educational, learned a couple things I didn't know certainly better than most unity tutorials.

As for the camera, on the off chance you didn't konw, you gotta use cinemachine, but yeah camera work takes time, i did a lot of it in unreal, it's a long process to tweak camera behavior to perfection.

I feel like we've drifted way off topic here though, i'll make another thread soon where I'll takl about some of these unity basics after i've worked them all out and i'll redirect you there once I do; so this thread can stay on topic for softbody.

 

[NMMMN]

well thought out and wise things ^ ^

I had a feeling you were gonna like the bullet physics,
im glad it and the tutorial turned out insightful

Spoiler: off topic unity movement reply

You don't have permission to view the spoiler content. Log in or register now.

 

[razfaz]

The latest Posts were full of information and inspirational, I liked it. Thanks Guys, its inspirational.

---

I don't know how many of us in this thread are friends of delving deeper, beyond scripting, regardless of engine.
However, for those working somewhere deep down every day, I might have a small experience to share that might be helpful in the future.

It's about buffering, fences, and the endless attempt to make our Sauce RockSolid and fail-proof. Esp, when we are in the Realm of Vertex, Position and Constrains....

And not only that, but also securing it so that other processes don't interfere with our sacred buffers.

This isn't that easy to da and manage as it sounds like.

Here's my current approach (in Unreal 5.5.4), which may change in the future, as the RHI API changes frequently between releases:

Quick Summary: Buffering and Fencing in Our UE5 Quest (not so serious, but kinda serious)

We’re fighting Unreal Engine bugs with buffering and fencing to sync (or async) our mesh updates and GPU solver(s) for ages.

Buffers are like barrels holding mesh data—positions and constraints. We set up a fixed-size PositionsBuffer once,
pad updates to fit, and share it between MeshUpdater and GPUSolver using some kind of FRDGBuilder.

Fences are our bouncers—BufferSetupFence and ReadbackFence ensure the GPU finishes before we touch anything, avoiding crashes.
It’s a tight dance with render graphs, keeping data flowing and chaos contained. Still tweaking, but it’s almost dragon-slaying time—want in?

Then there is Nanite... Oh fuck!

Now we have dynamic Verts (LOD dependent) in addition.
Back to the Board. -.-