- Mar 24, 2021
- 123
- 151
Yeah, I looked into the UE 5.5 Source code and it seems that they have prepared MorphTargets with Nanites.
It's on the TODO list.
Unreal Engine how can we achieve soft Skin Physics in Unreal Engine
- Thread starter germa59
- Start date
It's on the TODO list.
Thanks for looking into this! Yeah it'll defo be something they sort out eventually, I think we lose features with nanite most of the time but then slowly gain them back.
Let me know how you get on with the fake particle soft body stuff if you get around to it. I briefly tried it a while ago on my Daz character and I couldn't eliminate weird spikey vertices all over the body. I may have set it up wrong but I couldn't figure out why it was doing that. It was also very laggy for me.
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 withYou 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.
- Mar 24, 2021
- 123
- 151
ConclusionBtw 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 workYou 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 withYou 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.
[SoftSkin]
In my opinion, the Shader approach is the best to go for atm.
[SKM-Nanites]
Not ready to fulfill this task atm.
[Dildos]
Niagara is definitely a technique worth to learn n' share + master. /me luv it
Last edited:
Not a huge update from me on the soft body front. I have had some ideas and am researching these for collision. One of which is to do with including morphs for potential character customization.
In Unity I wrote a system from the ground up which allowed me to define "Sliders" such as "Weight". And then create delta values which would resize the ragdoll characters colliders (mostly spheres with a few capsules) to line up with the morphed shapes (blendshapes in Unity).
This doesn't seem achievable in UE5 at least in Blueprints. It seems like Physics Assets can't be adjusted at runtime in any way other than changing to an entirely different physics asset which wouldn't solve this problem. Does anyone have any knowledge for this kind of problem?
Surely this has been tackled before in UE games with heavy slider based customization and somewhat accurate collision for a character body?
In Unity I wrote a system from the ground up which allowed me to define "Sliders" such as "Weight". And then create delta values which would resize the ragdoll characters colliders (mostly spheres with a few capsules) to line up with the morphed shapes (blendshapes in Unity).
This doesn't seem achievable in UE5 at least in Blueprints. It seems like Physics Assets can't be adjusted at runtime in any way other than changing to an entirely different physics asset which wouldn't solve this problem. Does anyone have any knowledge for this kind of problem?
Surely this has been tackled before in UE games with heavy slider based customization and somewhat accurate collision for a character body?
If anyone's tackled it before it'd be Unreal games that use morphs such as head game or naughty sandbox, but I don't think they have morphs that change the body that much...
The physics asset colliders are attached to the bones, maybe that could be useful somehow? Manipulating the bones should affect the collider I think
But I'm pretty sure to do it the way you suggested, which is probably the best way, requires a deep dive into the C++ side of things. Maybe edit the physics asset c++ class to expose more controls for the colliders as a start.
I've encountered a good handful of issues where I just saw "well, that's a blueprints limitation, gonna need c++ to fix that" I've been putting it off though, I want to do everything I reasonably can, at least up to a point, before I start diving into C++, partly because I am not an experienced C++ programmer and another part because I hear some horror stories about compilation times when you start playing with the C++ side of things in unreal, such as people changing one line of code and needing to spend hours recompiling the entire project to test it out.
I'm just sorta learning the engine one feature at a time, i've mostly got the bp part down, I'm almost like a fish in water when playing with those, when there's a will, I find a way so long as enough functionality is exposed to me in the first place. I've got some barebone basics of physics asset but not enough to truly say I've learned it, similar with controlrig but the latter I at least am learning (that learning was just put on hold kinda cuz I wanted to get a better grasp of the engine basics before continuing it, i'm going back to it after I learn more about niagara) lately I've been practicing with Niagara, following Vince Petrelli's udemy course (100% recommend, it's awesome).
I've got the basics of the niagara system down already, I know enough to make most vfx any standard game would need already more or less, but I'm only 1/3 through that course. I never expeted it'd be this fun to play with it.
Once I'm through the course, I will try to play around a bit with the niagara system, things like niagara softbody, maybe niagara hair too, and of course niagara semen and saliva. Then it's back to controlrig, and it's only really after that (i'll probably spend quite a lot fo time on it, it's more complicated than niagara imo), I'll start another more comprehensive course where the author teaches you how to make a complete game with a strong focus on c++... Beacuse you're never properly utilizing unreal without using it's c++ capabilities, it's one of the best parts of the engine really, but it's alsso definitely the most complex part of it.
Last edited:
I'm in a similar boat at the moment. I come from a .NET background and haven't touched c++ in years. Im happy to jump into it but the 3 times I've tried in UE5 after following a tutorial, simply created a new class with no code in it, and then everything just fails to compile and it practically breaks my entire project and requires all sorts of deleting and fixing before it will even load the project up again ><.If anyone's tackled it before it'd be Unreal games that use morphs such as head game or naughty sandbox, but I don't think they have morphs that change the body that much...
The physics asset colliders are attached to the bones, maybe that could be useful somehow? Manipulating the bones should affect the collider I think
But I'm pretty sure to do it the way you suggested, which is probably the best way, requires a deep dive into the C++ side of things. Maybe edit the physics asset c++ class to expose more controls for the colliders as a start.
I've encountered a good handful of issues where I just saw "well, that's a blueprints limitation, gonna need c++ to fix that" I've been putting it off though, I want to do everything I reasonably can, at least up to a point, before I start diving into C++, partly because I am not an experienced C++ programmer and another part because I hear some horror stories about compilation times when you start playing with the C++ side of things in unreal, such as people changing one line of code and needing to spend hours recompiling the entire project to test it out.
I'm just sorta learning the engine one feature at a time, i've mostly got the bp part down, I'm almost like a fish in water when playing with those, when there's a will, I find a way so long as enough functionality is exposed to me in the first place. I've got some barebone basics of physics asset but not enough to truly say I've learned it, similar with controlrig but the latter I at least am learning (that learning was just put on hold kinda cuz I wanted to get a better grasp of the engine basics before continuing it, i'm going back to it after I learn more about niagara) lately I've been practicing with Niagara, following Vince Petrelli's udemy course (100% recommend, it's awesome).
I've got the basics of the niagara system down already, I know enough to make most vfx any standard game would need already more or less, but I'm only 1/3 through that course. I never expeted it'd be this fun to play with it.
Once I'm through the course, I will try to play around a bit with the niagara system, things like niagara softbody, maybe niagara hair too, and of course niagara semen and saliva. Then it's back to controlrig, and it's only really after that (i'll probably spend quite a lot fo time on it, it's more complicated than niagara imo), I'll start another more comprehensive course where the author teaches you how to make a complete game with a strong focus on c++... Beacuse you're never properly utilizing unreal without using it's c++ capabilities, it's one of the best parts of the engine really, but it's alsso definitely the most complex part of it.
Ya see? Horror stories!I'm not so worried about failing to compile (tho maybe i should) just compile times... I just dread the hours of debugging c++ code that we're eventually in for here. Everytime we wanna change something we'll have to compile, which depending on circumstances can mean changing one line of code and waiting a few hours to see if it worked; if those horror stories are to be believed.
- Mar 24, 2021
- 123
- 151
hm... Good question. I think this can be done on runtime. Challenge accepted. Will do some mockups and check.
- Mar 24, 2021
- 123
- 151
Guys,
While I was in a good mood working on an experiment regarding variable physical collision spheres,
I noticed that I apparently have gap in my UE-UI-Widget knowledge that blocks my further advancements.
[UE 5.4.2]
I want to "bind" a Character_BP Variable/Value to an UI-Slider for the final purpose of controlling a PhX Sphere|Capsule HalfRadi|Size etc.
So...
1) (Construct) get a specific PhX Sphere|Capsule-HalfRadi|Size from a Char|Actor first.
then
2) (OnSliderUpdate) Change HalfRadi|Sizes for the specific PhX Sphere|Capsule on runtime with the help of the UI-Slider
I must be looking completely stupid by not knowing how to get this to work, because I fail to even make an UI-Slider to work befor been' able to do any tests. lol
Sorry. Maybe you guys have an idea, or can have a look into, to help to get pass my temp. hurdle.
My first guess was it must have something todo with the sequence of Obj-Referencing.
So have used pre construct and Ref "OnSpawn", but it didn' help.
The Slider
BPs concerned are as follows (selected/marked blue):
Calling|Create the Slider:
The Slider UI-Widget:
4Nrds: Effectus lutum or better Effectus est pro ano.
While I was in a good mood working on an experiment regarding variable physical collision spheres,
I noticed that I apparently have gap in my UE-UI-Widget knowledge that blocks my further advancements.
[UE 5.4.2]
I want to "bind" a Character_BP Variable/Value to an UI-Slider for the final purpose of controlling a PhX Sphere|Capsule HalfRadi|Size etc.
So...
1) (Construct) get a specific PhX Sphere|Capsule-HalfRadi|Size from a Char|Actor first.
then
2) (OnSliderUpdate) Change HalfRadi|Sizes for the specific PhX Sphere|Capsule on runtime with the help of the UI-Slider
I must be looking completely stupid by not knowing how to get this to work, because I fail to even make an UI-Slider to work befor been' able to do any tests. lol
Sorry. Maybe you guys have an idea, or can have a look into, to help to get pass my temp. hurdle.
My first guess was it must have something todo with the sequence of Obj-Referencing.
So have used pre construct and Ref "OnSpawn", but it didn' help.
The Slider
BPs concerned are as follows (selected/marked blue):
Calling|Create the Slider:
The Slider UI-Widget:
4Nrds: Effectus lutum or better Effectus est pro ano.
Last edited:
I haven't really worked with widgets at all yet except creating a crosshair but a quick search found me this.Guys,
While I was in a good mood working on an experiment regarding variable physical collision spheres,
I noticed that I apparently have gap in my UE-UI-Widget knowledge that blocks my further advancements.
[UE 5.4.2]
I want to "bind" a Character_BP Variable/Value to an UI-Slider for the final purpose of controlling a PhX Sphere|Capsule HalfRadi|Size etc.
So...
- Mar 24, 2021
- 123
- 151
@Velomous: Cool, that helps!
@_Thread:
I can write you Voronoi+Delaunay triangulations in C++ or ASM, but fail at modern Unreal UI, there I'm at a loss. lol
Have to change that = Challange!
N' can only speak about myself, after over 20 years of extreme programming,
I'm glad that I no longer have it as a job, but rather just satisfy my need for solving and compute things as a hobby in my free time.
Hrhr, now I'll go and learn Unreal UE-Widgets.
@_Thread:
I can write you Voronoi+Delaunay triangulations in C++ or ASM, but fail at modern Unreal UI, there I'm at a loss. lol
Have to change that = Challange!
N' can only speak about myself, after over 20 years of extreme programming,
I'm glad that I no longer have it as a job, but rather just satisfy my need for solving and compute things as a hobby in my free time.
Hrhr, now I'll go and learn Unreal UE-Widgets.
Last edited:
Good luck with that UGM/Slate
Well good luck with Unreal UI. UMG/Slate kind of suck.
Took a fast look at your project and you where trying to use "get player character" for a actor you placed in the level. That will just return a nullptr. Make it your default pawn class "World Settings > Game Mode > Default Pawn Class" if you want to use "get player character" to access it.
If you just want to test and have fast dirty access to the Ann BP Actor in the level then you can just use "Get Actor of Class" instead of "Get player character" in the Ann UI Widget to mess around with it for testing.
Some small ui tips:
- Try to avoid using Bindings if you can for UI that stuff gets called on tick.
- Use overlay instead of canvas if you can for better performance.
@Velomous: Cool, that helps!
@_Thread:
I can write you Voronoi+Delaunay triangulations in C++ or ASM, but fail at modern Unreal UI, there I'm at a loss. lol
Have to change that = Challange!
N' can only speak about myself, after over 20 years of extreme programming,
I'm glad that I no longer have it as a job, but rather just satisfy my need for solving and compute things as a hobby in my free time.
Hrhr, now I'll go and learn Unreal UE-Widgets.
Well good luck with Unreal UI. UMG/Slate kind of suck.
Took a fast look at your project and you where trying to use "get player character" for a actor you placed in the level. That will just return a nullptr. Make it your default pawn class "World Settings > Game Mode > Default Pawn Class" if you want to use "get player character" to access it.
If you just want to test and have fast dirty access to the Ann BP Actor in the level then you can just use "Get Actor of Class" instead of "Get player character" in the Ann UI Widget to mess around with it for testing.
Some small ui tips:
- Try to avoid using Bindings if you can for UI that stuff gets called on tick.
- Use overlay instead of canvas if you can for better performance.
- Mar 24, 2021
- 123
- 151
Xantavius : Yeah, good points and sincere gratitude! I was used to GetPlayerChar as an Object. That may be the Crux.
Esp. the onTick info is good to know! What a ComputeTime waste if it would be used wrong.
Will implement n' check the coming days.
Again, thx Pal.
I hope I can return some best practice one day when needed as well.
Esp. the onTick info is good to know! What a ComputeTime waste if it would be used wrong.
Will implement n' check the coming days.
Again, thx Pal.
I hope I can return some best practice one day when needed as well.
Last edited:
Yeah it's always the easy small mistakes that get you at the end of the day. Love it when for example you forget to turn On/Off some checkbox somewhere and spend a long time trying figure out why something isn't working. Also doesn't help that unreal doc are kind of lacking in a lot of ways.
- Mar 24, 2021
- 123
- 151
@darkevilhum
Ok, I dove deeper into those "Collision Primitives" this weekend and sadly you are bloody right, they can't be accessed+modified throu APis on runtime atm.
You can instance a specific PhysicsBody throu BP|Python, but the CollisionPrimitiveBodies You are looking for are not made public for APIs. -.-
(You could have told me before! -.o)
[ERGO & SOLUTION]
The best way currently, from my POV, is by using C++ directly and override or inherit|modify some exisiting BodyInstance.* functions.
Here some private and existing functions inside BodyInstance.* from the UE-Src you may can use for further info and as a starting point writing your own custom helper functions regarding this task:
[Additional Thoughts]
Hm, Im relatively new to UE, but it seems to me that in the long run it may be better to use UE without Blueprints. (?)
1) I didn't liked those Blueprints anyway, they are an additional layer made for Designers and Scriptors. So, if you are familar with c++, it may be better to go straight to the Beef without any restrictions. Maybe (?)
2) I'm not cosy with the Code>Compile>Run Pipeline using BPs ByteCode atm, but I do know, in general, that interpreting ByteCode on runtime have a (more|less) significant negative inpact on performance. If this is the case, then using CeePlusPlus straight away would be a significant additional benefit.
Happy hacking n' all the best.
Raz
Ok, I dove deeper into those "Collision Primitives" this weekend and sadly you are bloody right, they can't be accessed+modified throu APis on runtime atm.
You can instance a specific PhysicsBody throu BP|Python, but the CollisionPrimitiveBodies You are looking for are not made public for APIs. -.-
(You could have told me before! -.o)
[ERGO & SOLUTION]
The best way currently, from my POV, is by using C++ directly and override or inherit|modify some exisiting BodyInstance.* functions.
Here some private and existing functions inside BodyInstance.* from the UE-Src you may can use for further info and as a starting point writing your own custom helper functions regarding this task:
[Additional Thoughts]
Hm, Im relatively new to UE, but it seems to me that in the long run it may be better to use UE without Blueprints. (?)
1) I didn't liked those Blueprints anyway, they are an additional layer made for Designers and Scriptors. So, if you are familar with c++, it may be better to go straight to the Beef without any restrictions. Maybe (?)
2) I'm not cosy with the Code>Compile>Run Pipeline using BPs ByteCode atm, but I do know, in general, that interpreting ByteCode on runtime have a (more|less) significant negative inpact on performance. If this is the case, then using CeePlusPlus straight away would be a significant additional benefit.
Happy hacking n' all the best.
Raz
Last edited:
Blueprints are great for prototyping, but they're limited, it's a scripting language built on top of c++ that can only use what c++ exposes to it and only works as c++ defines it.
For general purpose game development they're great, but when you need to go outside the box you just gotta use c++. You are also correct that coding the game in c++ is better for performance, what it's worse for... Is compile times.
UE used to have not that long ago (only a few versions back) a feature called blueprint nativization, what it did was simply convert blueprints to c++, and someone tested the potential performance benefits of using Native C++ vs Blueprints vs Nativized Blueprint, literally just pressing a button to make blueprints be c++ instead. The performance difference is staggering. (Each actor has a few math operations on-tick)
Epic removed the feature because it didn't always spit out perfectly functional code, it sometimes needed to be adjusted and people were complaining about it.
Generally it is best to develop as much of your game as you can in blueprints first, maybe do a few things that you can't on c++ instead along the way, then near the end of the development process you should ideally have a game that is as optimized as it possibly can be on blueprints; then for parts that would benefit significantly from further optimization, convert those to c++ instead (things like actors with complicated tick events definitely fall under that category if there are many of them at once, like it's ok if it's just a projectile that gets spawned, shoots, and then self destructs in a matter of seconds unless you expect to have many of them flying around all at the same time, but for something like an npc, converting it to c++ is very likely a very good idea at the end).
This is my current take anyhow.
Last edited:
- Mar 24, 2021
- 123
- 151
Aloha Velomous,
[Performance & Quality]
Yeah, thought so too, good to have an additional opinion on this.
I see it this way (analogy): it's similar to music. The best quality you can get is native from a live Instrument -> throu air -> to your Ear/Brain (3 steps only).
All additional things like recording mics, digital conversions (back and forth), recording medium, amplifiers, speakers... every single step is adding cumulative loss of Performance/Quality on top.
[Nativization]
Did'n knew that, but don't wonder why Epic get rid of Nativization at some point, because it added another Layer of maintainance, and every change you make in the SRC has to be replicated in the "Converter" as well = Double Work = Hell = Meh. So, Scripting+Interpreters are left. (wonder why they have taken the path of BP instead uf LUA for example. Hm, maybe because Designers are more of the "visual" type of ppl. TxT Instructions line by line is not their thing. So they thought to implement a kind of "visual coding" editor <- which is (visual coding) a very old idea and still a topic of current computer science btw. (not that easy to do as it sounds)
[Prototyping]
I feel bad why why we have to choose an approach in the beginning of a Project currently. C++ or BP.
I wish we could choose inside a Project for every Case we like.
Edit: I was wrong there, we can. (thx Velomous)
I imagine Prototyping in BP and decide its good enough (case study), because it works and I can move on to the next step while knowing I have still the option to review and replace some critical BPs with native C++ afterwards. From Top to bottom, rough to fine or sketch to detail, so to speak! instead of the other way around.
[So...]
In my view, and as I understand also from Yours, to be forced to choose on CreateProject to use C++ or BP only sux and hinders a real creative flow.
Edit: I was wrong there, we can mix. (thx Velomous)
[Performance & Quality]
Yeah, thought so too, good to have an additional opinion on this.
I see it this way (analogy): it's similar to music. The best quality you can get is native from a live Instrument -> throu air -> to your Ear/Brain (3 steps only).
All additional things like recording mics, digital conversions (back and forth), recording medium, amplifiers, speakers... every single step is adding cumulative loss of Performance/Quality on top.
[Nativization]
Did'n knew that, but don't wonder why Epic get rid of Nativization at some point, because it added another Layer of maintainance, and every change you make in the SRC has to be replicated in the "Converter" as well = Double Work = Hell = Meh. So, Scripting+Interpreters are left. (wonder why they have taken the path of BP instead uf LUA for example. Hm, maybe because Designers are more of the "visual" type of ppl. TxT Instructions line by line is not their thing. So they thought to implement a kind of "visual coding" editor <- which is (visual coding) a very old idea and still a topic of current computer science btw. (not that easy to do as it sounds)
[Prototyping]
I wish we could choose inside a Project for every Case we like.
Edit: I was wrong there, we can. (thx Velomous)
I imagine Prototyping in BP and decide its good enough (case study), because it works and I can move on to the next step while knowing I have still the option to review and replace some critical BPs with native C++ afterwards. From Top to bottom, rough to fine or sketch to detail, so to speak! instead of the other way around.
[So...]
Edit: I was wrong there, we can mix. (thx Velomous)
Last edited:
You can. You absolutely can. Blueprints is supposed to complement C++, not replace it.
At the top, go to tools, then make
You must be registered to see the links
.Edit: Here's another performance comparison that shows the actual code, in particular i'm interested in the c++ and blueprints combined code. So he makes a function in blueprints, a function in c++, and a simpler c++ function (basically just one half of it) that he puts it in blueprints. The performance loss is very acceptable when he merges a c++ function into the bluerpint to do most of the heavy lifting, compared to doing it in BP which errors out.
But i'm linking this video because it shows you a practical example of how BP and C++ can and should be used together.
Last edited:
- Mar 24, 2021
- 123
- 151
@Velomous
1ms vs 5ms : This Diff is criminal regarding computing time!
@AllWhoMightConcern
1) Use C++ instead of BPs, enjoy more coding freedom and release|gain 5*fold less pressure on Processors.
2) ReEvaluate Your ambitions with Assets|Scenes|Levels in UE to meet the abilities of GPU|CPUs currently available for civilians.
3) Make use of a Monitor-PotatoPC for testing Your Apps, if it worx on Potato, then it will work on NasaPC's as well or better.
1ms vs 5ms : This Diff is criminal regarding computing time!
@AllWhoMightConcern
1) Use C++ instead of BPs, enjoy more coding freedom and release|gain 5*fold less pressure on Processors.
2) ReEvaluate Your ambitions with Assets|Scenes|Levels in UE to meet the abilities of GPU|CPUs currently available for civilians.
3) Make use of a Monitor-PotatoPC for testing Your Apps, if it worx on Potato, then it will work on NasaPC's as well or better.
Last edited: