- May 19, 2022
- 168
- 112
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.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.
You don't have permission to view the spoiler content. Log in or register now.
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 shaderHad 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* -.-