Using and animating characters with morph targets without glitches?

Development Character & Animation
1

Hi,
has anyone ever been able to import and animate a character (DAZ3d Genesis 8 etc.) with morph targets in UE4 without any issues?

And I mean esp. animations/poses, where the arms are raised and where the armpits are fully exposed.

I’m always getting some glitches. Either there are texture seams (all over the place) or dark shadows in the armpit area. I’m working with UE 4.25.1 Dual Quaternion Mod.

Is this a specific problem with that version and should I report that glitch?

No matter, if I use MakeHuman characters or DAZ3d characters, there is always the same problem in the same area (mostly armpit).

The dark shadow obviously doesn’t belong there (depending on sun height it’s sometimes even worse), which is very annoying, esp. with bright (sun)light/outdoor scenes in an open world environment.

Morph targets/bone driven JCMs animate perfectly, the mesh behaves correctly, topology is clean (animations are imported through blender, so no bone driven jcm setup necessary in UE4).

The example (see attachment) is from the standard DAZ Gen 8 char (no skin, only material, no other maps or materials (color material used with morph targets checked).

Example pose is even without morph targets applied (shadow is there no matter if animation has been exported with or without morph target value information). MakeHuman has identical problem. (with similar morph targets)

No difference between “support compute skincache” checked/not checked. Restarting makes no difference.
Yesterday problems with seams…UE4 does what it wants.

What to do? Whom to ask? Waiting another year for a newer version hopefully without this glitch?

btw…
Most people don’t know, but
there is a trick for exporting animations with bone driven morph targets from blender (they have to be set up in blender or imported into blender beforehand for the specific character):

If you export an animation together with the corresponding mesh from blender (your base mesh with rig and morph targets should have been imported before into UE4 and put into a separate folder), UE4 remembers the bone driven JCMs from blender for the length of the animation sequence.

If you just export the armature, UE4 doesn’t remember the shape key values for the animation. So for a successful export of animations with bone driven jcms applied you need always to export
it with the body mesh (which you can remove later on in ue and just leave the animation sequence and it will work flawlessly).

btw2
I’m surprised that only a few people worldwide seem to be using their characters for more than just some standing or walk animations in some armor outfit or even be interested in building the DQ version of UE from source since it’s really easy to do much more than what people have been doing so far and from performance perspective it works just fine, even with a character that has ~100 jcms in an open world setup.

2

Unless you made the mesh your self and you purpously added extra geometry to allow for the stretching - which is done by modeling the arm raised, and subsequently repositioning it to an A Pose - of course you will keep having issues.
the geometry is what it is, put it in wireframe mode and you’ll see what kind of stretching the vertices are getting.

Doesn’t matter how much you morph if there are no vertices to be able to cover the area with the same texel density as the rest…

Also, the setting you want is Recompute skin cache - if it wasn’t renamed or soemthing.
And you want to check the recompute tangent option as well. It should make the shadows better despite the lack of geometry.

3

Do you want to say that DAZ3d Genesis 8 and MakeHuman chars have a bad topology?
I don’t believe that, because my super high poly MakeHuman char has this as well and the glitch does not occur in DAZ3d or blender 2.79!.

The geometry allows for good stretching and behaves in a clean way. Textures are clean as well, it’s only the “lighting”.
Even without direct light source it is visible as a darker spot. No matter how many vertices the area has, stretching will always occur with arms raised up poses, no magical topology can prevent that.
The armpit is a spot where the mesh loses volume (linear skinning) or bulges the most (dual quaternion skinning).

Recomputing skin cache / recompute tangent for some strange reason does nothing anymore (have even tried to recalculate all shaders).
Really no solution possible? Not a single person who is sucessfully working on animations / poses of that kind in a real time environment, where the character skin is exposed? (clothes can hide this issue sometimes as they have an irregular topology anyway)

It’s only this one annoyance, otherwise everything would work perfectly…

4

That bend is probably going to have some issues on the base Genesis 8 no matter what you do, but from the image it look like you’re putting the whole bend on the shoulder. It needs to be split between the collar and the shoulder. The image below is with JCMs for the collar and shoulder as well (connected via my plugin https://www.unrealengine.com/marketp…/daz-to-unreal). You might also need to play with the shadow settings on the character a bit.

The seems you’re talking about might be in the texture. A lot of the Daz Marketplace assets have textures that cut off right at the edge of the UVs. So when lower mips get used, a white or black line will get merged in at the edges. That’s why they appear and disappear at certain distances and angles. The normal maps in particular can make a weird edge in the lighting. I think the fix is to go paint in a little extra in the textures.

UnderArm.jpg
UnderArm.jpg975×519 79.7 KB

5

You wrote another post while I was responding. It looks like you are bending the collar, hard to tell. Are you sure that shadow isn’t from a normal map?

6

Bone setup is ok (checked it in blender). The problem surely stems from the UE lighting implementation and not from the daz model. The mesh itself bends correctly (with jcms). Even without any texture the shadow is still there. (see example)

Strangely the bones in blender look differently, esp. the offsets (collar and shoulder bend bones aren’t connected in blender), but it doesn’t seem to have any effect on the animations, but on the shading? (example 2 with a similar pose) But why do have my MakeHuman characters this problem as well?
I would have noticed any bad effect in my animations…

The question now is if it is specific to the 4.25.1 DQ version of UE or if it is a general problem, that should be reported to Epic?

7

the recompute skin cache not working seems to be specific. Was fine in .24

Re the rest.
The composite screenshot you shared shows exactly what I mean about texel stretching.
look at the distance between verticis in the lower area compared to the above area.
its essentially missing at least 1 row of verticis.
Having those in the model would mean that the squares you see made from shadow would be much less visible.

Also, take another screenshot exactly as the last one.
one in lit, one in wireframe.
Overlay in photoshop and make the wireframe transparent on top.

Do the highlights generated by the shaows Not match mesh topology?
If they don’t then I’m wrong. Happy to be, as I’d have to learn something else.
If they do. Then like I said, add extra topology and the issue will be less visible…

Oh and BTW, the engine dynamic shadows in .25 seem to have gotten some changes. They are by default super harsh on the same default skin whereas they looked fine with the same material on .24. Similar issue on the hair material, which now gets lit like a Christmas light…

8

I’ve made an overlay and the shadows don’t match the mesh triangles, so it has to be something else than the topology. Maybe a different blueprint node setup in the material could help?
Since 4.25 everything became brighter. Where I needed 6 lux before, I need now 3 lux for the same brightness (directional light)

9

I agree with that. and the culprit must (going by the changes) be the Eye Adaptation changes.

Did you save the base layer without transparency?
I would like to see the actual colors of this area (highlighted quads) separately.
Particularly the circled area from the other picture. That’s really where the quad is visible and causing the issue, complete of triangulated split.

glitch.jpg
glitch.jpg860×626 137 KB

BTW, the docs seem to have gotten an update for eye adaptation too
https://docs.unrealengine.com/en-US/…ure/index.html
The custom curve thing works, the brightness issue can be fixed with a bit of trial and error.
Which is no different than before, but has to be done again after migrating a project unless you stick to the old way that auto exposure worked - (which should be preserved within the post process? yet it wasn’t for me?)

10

I’ve created new images for comparison, because I didn’t save the original ones. You can overlay the 3 images to see the differences between wireframe, skin and material with color only.

I don’t even use auto exposure but have set a lower value for the sunlight directional light and the scene looks as it looked before the update.

In my opinion it still has to do something with the skincache, because the shadowed area has a morph target applied and ue4 for some reason doesn’t like morph targets.

It assumes a false orientation of the triangles when it comes to shading. If I let the sun run a full day cycle I can see that UE thinks that area has a “hole”.

In the past the checkbox for support recompute skincache worked and removed this (and added ugly seams everywhere), but now none of the corresponding settings work.

I will have to import a new character and make some further test, but it has definitively something to do with the morph targets.

11

could be a combo of things.
What does detail lighting look like?

also, you can see the quad/tris relation on the last screenshot… if the setting was working that should not be viable. Adding geometry would still make this less prevalent…

12

Detail lighting looks exactly like the shadow in the image with skin texture (post #10). If I set default skin behavior to “inclusive” than it looks like below in lit mode (unlit mode has no seams) (example has only diffuse texture, so it is not even any problem with the normal map etc.; seams on whole body (legs,feet…)), although “recompute tangent” alone should have caused it to recompute, what it didn’t in “exclusive” mode.

It’s much worse than 4.24 as it had only problems with normal maps.

Adding more geometry would not reduce the shadow but instead make it finer like in the example with the skin material from #10. It is an issue of a false shader calculation.

This problem really has been holding up my workflow for several months (in 4.24 similar issue with normal maps+morph targets and now troubles just with mere diffuse textures+morph targets).

Is there anything I could do as emergency workaround (material node setup or something in the shader soruce code?)

13

Well, the only thing to do would be to try a different rendering model for the material?
maybe just a default diffuse would look better.
what you end up loosing is the skin transmission - light behind the ear getting the mesh to color slightly red.

obviously there is no guarantee that will fix anything either considering the compute skin cache seems to not be working…

14

My setting is “default lit”, no other shading model makes sense or do you mean something else?
Tested, if the normal 4.25 version without DQ mod has this as well and indeed it has the same shadow/seam glitch/non-working exclusive skin cache behavior box. Will have to report this officially as bug.

15

I meant that the skin usually uses a specific shader.

To be honest, partly because what I had needed more work, and partly because I wanted something even better, I ended up re-making and splitting my character from near 0.
this means I have to re-go through the whole setup again as well as adjusting the animations since I modified the skeleton a lot.
I actually have to figure out how I want to assign the twist bone paint right now. And after that I’ll be packing in a couple of automated morphs to handle the elbow bend and the armpit.

To be clear, my mesh is split into sections. The arms are individualized and they dip inside the chest mesh so that there isn’t any real excessive stretching occuring, and the armpit is essentially an illusion given by the combining of the 2 geometry pieces. The morphs will take care of the Zfighting by moving parts in or out depending on the pose.
Also the shading won’t matter since the pits aren’t shaved fresh, in fact maybe I can even hide it more with a pointless use of the hair simulation XD

With that said, the material(s) used to be set up as per the DigitalHuman sample project.
With an import of the previous version of the model from a .24 project, pretty much nothing works right.
The hair is glowing in the directional light like a Christmas tree.
The skin does get odd and rather very pronounced shadows when the directional light dips past a certain angle (sun is setting but realiatically it’s a winter’s 4pm when sundown would come at 6pm, no reason the shadows have to be so dark).

The eye adaptation is blasting a -4 on the scene or some crazy number like that (the max you would normally get was a -2 or so with the same scene/level in .24).

The landscape shadows and grass shading are foobar just as much with the same light angle.
Its literally as if the engine is modifying the shadow casting bias based on the angle or something equally silly.

ANYWAY. Major setbacks aside.
the material itself which now opened is set as surface, opaque. With the special sub surface profile. In this case called SSP_twinblast_skin_bust.
there are no other special settings. But my material node network was heavily modified compared to what you got form the digital human base.

I think the blendanglecorrectednormals material function does most of the needed adjusting work for the shadowing.
in essence it takes care of blending the micro normal to the actual normals - basically from overall to pore detail.
but the process of that also ajusts the overall normal map, which in turn does contribute to adjusting shadows somewhat. You may want to try and just lift the material from that project to give it a try.

Obviously though, if detail lighting looks bad and/or a simple color material with nothing else shades incorrectly, then the only thing we can do Now is build the latest preview of the engine to see if the introduced bugs are resolved.

Luckily yet very unluckily for me, I have to adjust and re-import around 200 animations, so, I’ll ptobably be busy with that until the next .2 release… :stuck_out_tongue:

16

Doesn’t your approach cause more problems than it solves, esp. when you need morph targets anyway? :slight_smile: It must be a horror to make clothing assets for a character like that. Why aren’t you using DAZ characters.

They have perfectly deforming bodies with ~94 Jcms. You can even use multilayered clothing without need of chopping up the character into several pieces and the workflow is really easy and fast, once you know what to do. The performance is super duper, because the topology (of the standard low poly character without subdivisions) is very efficient.

MakeHuman is a nice choice too (multilayered clothing, performance, can add custom morph targets, fast workflow, support for bhv animations = endless database of 1000s of animations for free available, mesh ready for subdivision)

“Surface, opaque” is the standard setting of any non-transparent material. Normal map blending sounds nice, will definitively try this out, when I find appropriate normal maps for it, but that won’t help with the shading problem here as it is not a problem with the normal map, but some awful bug somewhere at the core of the engine like the other bugs you mentioned.

At least the shadows in my world are the same as before, probably because my open world map is somehow “primitive” with mostly flat landscape with little vegetation, where I had to turn off some shadows, because of performance reasons.

17

I make all my own stuff manually. It’s a longer process but I get better results.
an no. If you want to make a shirt you just grab the original, sculpt the shirt onto it so all the weight paint is there, cut how you need and place in engine as a replacement for the chest.
the fact the arms are split already allows for modularity.

It makes changing things on the fly much easier and it is a requirement of the project since it involves armature that can be mixed and matched however the player wants.

With each major joint (hand, lowe arm, upper arm, shoulder, beast/chest, waist, upper leg, lower leg, foot) individualized i have a much easier time making specific assets.

And for the assets that cross between, say a full armor arm that goes from shoulder to arm, you just replace the top with the correct mesh, and hide the lower meshes…

This also allows me to ignore bones if I want to within the weight paint. Say for a gauntlet like item that shouldn’t take to the wrist twist or should only depend on the wrist twist…

18

Well to start with an old joke.

“Doctor it hurts when I do this”
Doctor “Well don’t do that”

So I have to ask why is it so critical that this issue be fixed to your isolationist? Is there a point in your project that such a pose is required or are you striving for perfection? Are you planning on nude skins or will there be clothing involved that can hide the blemish?

I asked some silly surface question as part of our project we have been using the Genesis 3 framework since the introduction of Genesis 3 and UE4.15 when a lot of the major issues were corrected, as in realllllyyyy bad deal breaker issues, so it’s rather clear to me that problems are being corrected on both Daz3D and Epic side of things and with out chit chat with Daz3D they are in the process of doing something targeted towards use in UE4.

Switching to game design theory.

To set the context here is a test example of the Genesis 3 female character as exported from Daz Studio into UE3 and some matching animations applied.

How was it constructed.

The Mesh:

The mesh was imported into UE4 to create a asset chain so that it would be easy to re-import the mesh once corrective measures were taken.
As part of the import morph injectors and facial expressions were imported at the same time. This included cluster shaping as part of the framework can be applied to any character.
Mesh was imported into 3ds Max to apply smoothing groups. This is idea as smoothing groups is a 3ds Max only feature and by doing so is on last worry as far as UE4 complaining that there is no smoothing groups.
Fixed any unusual deforming skin weights based on local rotations.
Re-import into 3ds Max.

The animation

All of our character animations is created using Motionbuilder so the issues of uncompleted features, like re-targeting, and once characterized as a biped character tool use becomes object aware so things like shoulder and collar joints become part of the full body IK so the result on IK is a more human rotation. Long way of saying the joint crushing is not that big of an issue.

The Materials.

The base material was harvested from Daz Studio and since the UV mapping is the same as part of the framework you have access to more than a few maps by just searching the DS library so easy enough to try out a few different options. Even with a base material the result is not bad as a starting point but there are a few options available to play with. For example the skin and hair sharders were pulled from a female Paragon character along with the sss profile.

Base materials do not behave as expected as it’s applied using a shader model that works best with the type of surface it’s applied to but even then the amount of output is generally never matched to the base environment lighting. For this project though, and as mentioned, I made use of the Paragon sss shader as the base for the multi material ID’s involved so as a surface was accurate.

Since the base mesh contains morphs make sure that the material is set to “uses morphs”

Tessellation is an option provided by the material and since G3 uses material ID,s the areas that need it, like for the under arms, can be increase as compared to other ares that does not need it. With auto LOD now available one can apply a lot more detail for the up close hero model as compared to the LOD requirements from a mile away.

Even though an accurate shader was used a texture map by it’s self is never balanced as to the lighting intensity of the object that it’s applied to as a percentage of the rest of the back ground. This is why light reflectors are used in video and photography and PBR based materials lack light information directly with in the image map.

There is a couple of ways to correct this as a problem and my number 1 trick, believe it or not, is to apply a small amount of emissive lighting to the material so I can force the lighting balance of the target object with out blowing out the lighting in general to get good coverage,

To keep it short don’t underestimate the importance of PBR material construction as the rendering system will poll both the lighting and materials for the information that it needs to properly render out the object and if done right usually avoids nasty artifacts in the process.

Lighting.

This is a topic on to it’s self but as to the example room demo second channel lighting was used just for the character model that was focused to only increase or decrease the lighting output of this single object moving with in this space. The same for the hair relative to the hair shade I stole from the Paragon character.

Do not underestimate the use of indirect lighting or the use of HDRI. Pushing up your lighting levels generally blows out the lighting.

Consider Component Construction.

Each element of the dancer is a component of a character BP as part of the total construction and then driven by a master pose component in the BP event. Makes it easier to change out elements with out having to rebuild the animation BP based on unique requirements.

Sorry if I went a bit long but some where in there is the possible cure to your problem and the only way to really figure it out is with in context of the purpose being served and having the character put it’s arm in the air showing off a blemish is not something that I’ve run across as more of a side annoyance that some how get corrected along the way.

That all said I can in my opinion recommend genesis for anyone looking for a single point framework solution as I’ve yet run across any deal breaker issues, since this little bugger,

19

To answer your questions: Such a pose/animation is absolutely required, otherwise I wouldn’t have even found out about that issue. Secondly, I need a perfect solution, because I often get very close to the NPC characters in my First Person Game. Thirdly, my characters have to show some skin from time to time.

The armpit shadow problem comes definitively from UE4. It’s only this annoyance, everything else works just fine as far as I can tell and the workflow (DAZ,UE) is really fast, once you know what to do.

The animation in your first video looks really nice and smooth from the given distance,
but the knee bends look strange (volume loss). Did you use any JCMs for the animation?

How would the same scene look in UE 4.25, esp. with sunlight and updated shading as the newest UE version introduced some changes with the lighting.
After having done some tests I think that the outdoor lighting got a better balance and esp. pale skinned characters don’t look as ‘over-exposed’ now.

Thanks for the tips, have tried out some of them already like using 2nd uv channel for the char, applying emissive lighting, setting material to “used with morph targets” and playing around with pbr materials and sss profile (my own one), tessalation (strange effects; probably didn’t use it correctly) etc.,
but to no avail as of yet for this specific issue, because whenever I try to brighten up that one spot, the whole skin - which is very pale already - becomes too bright. But generally some really interesting approaches I wouldn’t have thought of.

20

Why? See this is an instant benefit of always making your own stuff. it becomes super trivial to fix it.
Open the character in Blender, set up a “paint” material, assign the whole character to it, look up the UVs to make sure the correct one is being used. Paint the whole thing black. paint the area you want brighter white.
Save the texture out.
Bring the texture to unreal. the model and blender doesn’t matter at all.

Add a texture sampler with this texture to the skin material, use it as an Alpha to brighten the spot you need without touching the rest.

Obviously this doesn’t “solve” the light issues, but if all you want to do is lighten or even put emissive in just that area, this is it.