Unreal 5.4 has come out. I have run a few preliminary tests with noteworthy results.
First and foremost, the Nanite foliage bug noted since 5.1 when foliage was first claimed to be supported actually finally seems to be fixed now. This would be mean I could finally use masked meshes, like trees and grass, in levels. I validated this by setting every Arvatur foliage mesh to Nanite. The skybox flicker bug still remains but that’s a separate issue related to volumetric clouds afaik.
Today, I tested the addition of the “Has Pixel Animation” flag added to materials primarily for use in “Temporal Super Resolution”, an updated TXAA filter primarily geared towards lazy phone game upscaling from 240p for 1080p that sh*tty games like Demon’s Souls use because they perform terribly. Incidentally, you can use TSR as a standard AA filter without any upscaling at all.
Conventionally, upscaling filters like DLSS and FSR have produced unusable, horrendous results. They are terrible. Dragon’s Dogma 2 yields how insane the ghosting, shimmering and general corruption is with this software.
However, TSR is an Epic-developed solution and it represents a significant step up from TXAA in overall functionality, and more importantly a lot of language used in the 5.4 update seems to indicate Epic is aware of, and trying to resolve, the issues temporal filters have with anything that uses motion.
“Has Pixel Animation” is primarily targeted towards WPO animations like those on trees and grass. It’s a flag that basically tells the filter to compensate for pixel velocities it can’t read so it doesn’t ghost them as badly. Basically, it makes foliage usable in TSR whereas prior to 5.4 it simply wasn’t.
I had hoped this setting might have been targeted for flipbook animations, but it’s grayed out on the materials.
You can force it on by the material instance.
All TAA solutions destroy particle effects. UE 5 has been gradually adding settings that compensate ever so slightly for this, but few dedicated to this specific problem. Notably, the extremely severe smearing from 5.3 is subdued in 5.4 and close-up particles look acceptable now. However, they still become very soft at a distance. There is the possibility that slamming out high emissive variance might compensate this somewhat, but that would require a degree of experimentation I don’t feel like doing right now.
There’s another experiment to try.
Since the textures are being mipped the further you go out they are already losing detail and resolution. I noted during messing with Faber’s assets that she was using a mip bias on hair to try to compensate for that (it didn’t help much). This came from the paragon assets she was using for her source materials.
Mip bias effectively forces the engine to push mip levels in a certain direction, whom normally scale down from 0, to, 1, etc. dropping resolution the further you get away. It means it won’t drop mip levels as quickly or will drop them more quickly by starting at a different “level”. It can be added directly to textures to force a lower resolution. It can be added to materials to change how the material accessing the texture handles its lodding. For example, hair loses its detail quite quickly, so setting a mip bias of -1 would keep it sharper even further away.
These findings may make TSR viable for the project, which would help metallic scenes in particular as they are a horrendous mess of bright aliasing. However, proper ingame testing will have to wait.
TSR softens the scene considerably by blurring the image, but its improvements in foliage and metallic areas are substantial. It also cleans up the VSM noise. I feel like we’ll be hard pressed to not use it moving forward if the project survives its current struggles. Configuring all of my particles and vfx materials for it and a proper test will ultimately be necessary for deciding either way.
Along the way I was able to discover the cause of the DragonIK crash and reported it to the author, but it remains to be seen if it’s something that I did wrong and an update brought out the bad data in or if its a legitimate bug.
Unrelated to 5.4, I acquired two retargeting-related plugins. One I haven’t tested yet (the free boner snapper), but the “easy pose” one I briefly tested as HKS begged me to figure out if it was any good or not.
To summarize, EasyPose simplifies the pose-matching aspect of retargeting. It’s basically a bandaid for the 50 cal-induced missing legs that the idiotic and rampant disregard for their own rules has earned Epic on the marketplace in which every Tom and Dick releases models that are “on the mannequin skeleton” but are 1.) differently proportioned 2.) differently posed 3.) can even include additional bones in the limbs. Basically, as detailed all throughout my dev series, retargeting is stupid and Epic has done a big f*cksy wucksy.
One part of the puzzle to obtaining a good retarget is the reference pose. Animations are very precise math. Even the slightest decimal deviation causes enormous problems. Many skeletons may be the same but the actual pose is different because authors don’t make content so they have no idea that f*cking around with it in daz 3d breaks compatibility with Unreal in ways that can take the end-user DAYS to make “ok” compensations for inside the editor. Previously, you had to eyeball poses and this just wasn’t good enough. EasyPose does it through code and precisely as the math allows.
The results are rather promising. The poses, at first glance, especially for the fox look better than my OG setups. There’s still issues with the legs, but not as severe, and of course two-handed weapons are still right out on anything that touches the hands or arms. However, it cleans up a lot of existing work and hypothetically one-handed animations should be quite viable.
Basically, EasyPose takes the tedium, time and guesswork out of pose matching. It doesn’t fix the inherit problems with retargeting. But for something I paid only a couple dollars for it’s nice. Too bad it’s necessary at all, but here we are.
These are the most relevant current developments for the engine and foundations for AXX as of 5.4’s release. I’m doing what I can to research the DragonIK crash and have narrowed it down to a minor setting I can just disable on the units that use it for the time being.
