Having a problem right after updating from 5.5.3 to 5.5.4
MetaHuman model has Fuzz, Eyelashes correctly attached and following facial animation morph, but Hair and Facial Hair do not follow no morph nor position of the head, despite having a Binding asset and being groom components under the head component. I tried giving it an Attachment Name, but Facial Hair is not being influenced by facial animation anymore. Everything was working fine before updating.
Help?
Edit: just looked up the basic model we used as reference for our own project, and on it everything works fine (so far). So just our model got broken somehow.
Edit 2: so, after some digging, apparently the metahuman model is also broken, cards and particles and curves do not follow the binding assets anymore.
Epic, help someone broke something.
Is AMAZING that this is still happening in 5.5.4 when packaging a project with the Project Launcher (this is not the same error I reported before, which was related with AMD). This happens in any PC, just when launching the packaged project.
I forgot that people still actually use BSP stuff, even when Epic has basically said theyāve moved away from them in favor of things like the grid tool and other primatives in the geometry editorā¦
But if you look at the code for the error, which hasnāt had a commit in 3+ years, youāll see itās happening in the following function:
@Krzysztof.N Hi, was Lumen support INTENTIONALLY removed in DX11? If so, was there an official announcement? If Lumen was NOT intentionally removed, then this is a major regression and should be addressed in a hotfix as it is still not working as of UE 5.5.4. This potentially cripples many projects that rely on the improved performance combination of DX11 and Lumen. @Uno1982 already fixed this in a pull request but for some reason the fix was rejected by Epic Staff. Thank you.
Itās pretty sad when anyone can make a scene with a few props for Instagram in the game engine, but when you, as a developer, need basic fast greyboxing, it falls apart. Not to mention that I have to wait for several hotfix patches in each version, which I was used to with Autodesk and Max, but not with Unreal.
And I can say for myself that now when it comes to support, Epic is starting to lag far behind Autodesk. Which is tragedy.
I tried to PR this twice both in 5.5-dev and release and both were closed and marked as intended removal. According to the feedback they donāt want to support dx (dx11 or dx12) sm5 lumen but continue to support vulkan and metal. It feels a bit odd to me as itās a very simple thing to add the const back and get parity across all sm5 shader models and rhiās however they want lumen bundled in with the higher cost shader model (sm6) for d3d only ā¦ itās not even about dx11 really at this point itās the complete lack of d3d sm5 swrt support at all. This also forces people into the dx12 pso caching pipeline instead of being able to rely on dx11 driver compilation which again dx12 pso has been consistently problematic. we have had a very long time to overcome dx11ās shortcomings and know how to handle it. DX12s pso pre 5.3 the and even post 5.3 auto precaching is a headache in and of itself. Iām simply confused at this point because I donāt see Fortnite dropping sm5 or dx11 support anytime soonā¦. But maybe because Fortnite disabled lumen in sm5 a while back thereās a conflict of interest with PRs that contradict this at the engine level when dumping the Fortnite merge CLs back to the engine release branches. Also as you stated the docs and release notes made zero mention and continue to mislead the community as it states DX11 SM5 for SWRT lumen is the min requirement
Iām sorry but Iām getting tired of seeing suggestions that people/studios stick with an older engine version (one that canāt even publish to android/google play without major modifications) due to a slew of constant instability or bugs being introduced into newer versions while epic has no skin in the game for an official LTS and thousands of PRs pile up waiting for review or acceptance. For every version we stay behind we also have to risk assess depreciation or dealing with whatever is borked in that minor version. Iāve been developing with unreal since udk and Iāll say that as much as I love this engine I find itās current āaccountabilityā and āquality standardsā appalling and simply unacceptable. Every company Iāve developed software for within the last decade would simply not stand for this. Iām not even angry ā¦. Itās simply sad at this point and hurts my heart
Well I hate to be that person, but your opinion on the matter isnāt going to change the fact that this is what studios/people tend to have to do. Sometimes things get broken, changed, deprecated, removed, etc between engine versions and if they are important enough systems to the project, then you donāt upgrade the project. I mean look at a game like Wukong, it was using 5.0 I think(maybe with some custom merges here and there for specific new features), even though we were all the way up to 5.4 by the time it came out. You donāt always hit the magic upgrade button every time a new engine version comes out.
But again, I think Epic suggested people move away from the BSP related workflows quite some time ago. They will likely fix whatever little bug is causing the problem though, but itās likely pretty low priority since the feature isnāt really used as much anymore.
If you want an āLTSā version, the final UE4 release is pretty solid still. UE5 is still heavily under development and UE4 wasnāt really widely adopted over UE3 until around 4.16+ for similar reasons.
Yeah ā¦ your fine. Nothing new really being said here. Itās pretty much re-stating my opinion on why it sucks to be in the position and I have that opinion because your outline has essentially been my life over the last decade. Iām saying that UE4 even though it had its issues could take āreleaseā branches to production and UE5 ā¦ meh itās debatable. Quality is pretty easy to measure when you kind of live eat and breath Unreal as a career. Donāt even take my word for it ā¦ the internet including colleagues/studios Iām really close to (many who were at the last unreal fest) have gone public in some form vocal about the issues. UE5 is extremely Virtual Production heavy in its priorities and āgame devsā are feeling neglected.
Nobody serious hits the āmagic updateā button. We usually take on the task of cherry picking fixes unless they are massive undertakings like the rhi async and chaos changes which you evaluate the risk/reward of taking the changes in bulk. Many times it is us that have contributed to the thousands of PRs awaiting acceptance. Just because something āhas been the wayā doesnāt mean its the best way or optimal way. If everyone followed that Montra we would never see improvement. Unfortunately itās the people that have the courage to challenge the status quo or ask the question that make people uncomfortable that catch the pushback from the ācomfortā of not changing from the known in pursuit of improvement.
My point is that getting from point A->B since UE5 has been really rough and everyone is so quick to use UE5 isnāt different than UE4 to ādefendā the engine and when things are borked they are like āUE5 is not UE4ā you should likely stick with UE4. Well you canāt have it both ways and I was there during the UE3 to UE4 migration. I remember it well I remember the studio I was with counting down the days to 4.7 ā 4.8 etc. The reality is that UE4 has almost as long of a list with deprecated APIs third party tooling (google play, meta, consoles, steam sdk) that itās been left in a state that is almost as challenging as starting with UE5 and fighting its battles. (Even if you start in 4.27-plus) [Iām not even going to open the fab migration and storefront changes pandoriaās box and what that did to anything older than UE5ās workflow.]
In reality THAT (UE3->UE4) was a much larger change and we are quickly approaching the minor version where stability was focused on with UE4. I guess as always, we will continue to take it as it comes.
Context: Being critical of something in the pursuit of improvement and constructive change is an act of love and caring. If I didnāt care ā¦ I definitely wouldnāt have waisted my time providing feedback. You offer support, advice and corrective feedback to your kids because you love them. There is no difference here really. Iām not out to bash the very thing that has fueled my career over 20 years. Iām simply concerned and stating what at this point is no longer swept under the rug ā¦ itās the elephant in the room.
I read somewhere years ago - companies pay 5-6 figure for Unrealās license prior to UE4 and they still have to patch quite a lot before they can reach a stable version of their own games. My reaction was wow - āthe quality is that bad ehā etc etc (you get the drift). But then, Unreal was still one of the most popular game engine and track record prove it.
So having realize that, I think in summary game development is very complicated along with the dependence of (mostly) nvidiaās buggy driver where unknowing programmers will blame the game engine whereas it is the driver that is at fault (there are reasons why console dev is āeasierā in that context). At the end of the day, just do whatever you feel needed to get your games release - patch it yourself, downgrade to whatever version that works for your game etc etc.
I feel like Iām going crazy, thereās been a very obvious bug in the engine for 6 months now and no one seems to care, I canāt find anyone (other than me) mentioning it on the internet.
If someone is reading this and has unreal 5.5 can you open your engine and tell me if you have the same shadow bug?
Could potentially be an RT shadows issue, so try disabling them. Iāve seen a lot of other people with similar issues lately, usually involving nanite though, but it might be related in this case.
The problem goes away if you turn off virtual shadow maps, but I need to use virtual shadow maps unfortunately. Also this problem doesnāt exist in 5.4 even when Virtual Shadow maps are enabled.
This is very true and just life in the middle of an engine transition. Iād go even further to some degree and say unreal (UE5) isnāt right for some projects where unity or godot might be better suited. (webgl, wasm, 2D, VR) Any engineer will evaluate the lift for said project and pulling HTML5 from 4.22 into UE5 is just an insane lift vs using another tool that does it out of the boxā¦ however as someone who has tasked themselves with going to market with ārelease branchesā of UE3, UE4, UE5 ā¦ At the end of the day that is your āstarting pointā and anything you need to mod in source is your burden.
Iām simply stating relative to itself the quality bar and effort needed to be successful in this partnership (Epic Today) is a larger burden on the studio/dev than its been in the past (Epic in 8th Gen). The target platform and engine support (UE3/UE4) during the 8th gen was of a higher quality standard and required less lift than the same attempt with UE5/UE4/UE3 today. UE3 had bangers coming out well into UE4s life (Rocksteady used UE4 then went back to UE3) Iām not questioning the process or the āknownā best practices for using unreal. All of that is kinda besides the context of my feedback. Its a given and should be second nature for any serious studio at this point.
This isnāt a hard thing to understand reallyā¦ comparing Unreal Engine to itself over the course of Major/Minor and patch version revisions, the support, the feature stability and the expected lift from epics partners (studios) ā¦ A tool has a quality standard and accountability standard to be called āreleaseā and failure to hold accountability to some said standard is not only bad ā¦ itās self-destructive to the partnership. Mechanics and carpenters understand this. Engineers understand this. The vendor relationship and tool quality is very import to a final product of any said partnership and when your the customer in said relationship it is your responsibility to give said feedback.
Having absolutely no skin in the game or accountability for calling a āproductā a āreleaseā is no different than the backlash from the customer that goes directly to studios when they call their said āproductā a āreleaseā ā¦ the engine doesnāt get an out just because its the tool the studio used. Thatās where our partnership and customer relationship starts and we have every right to demand accountability no differently than our customers.
When you can look at UE5ās release branches and literally not a single one can make it across the line without source modifications or heavy cherry picks/fixes from almost hundreds of PRs of which havenāt even been merged yetā¦ and comparatively you look back and studios went to market with 4.17, 4.19, 4.22, 4.26, 4.27.2 launcher builds (keep in mind the time to get to these minor builds also vs UE5)ā¦ The writing is on the wall is what Iām saying.
You canāt be a āgeneral purpose engineā marking yourself as ābest in classā slapping āreleaseā on your tool only for your customers to realize ā¦ dang. I gotta finish this tool because it cant do x,y,z the way it needs to yet. And be like ā¦ well thatās ok because craftsman gave me the blueprints on how to finish tempering the steel so its strong enough to torque this bolt. Some empathy and understanding is fineā¦
UE4 released in 2014 and by 2017 āreleaseā branches were going all the way to production. 2022 UE5 entered preview, and we are 1 month away from the 3 year mark of release. Stability and quality should be the highest priority and that should include āgame development tooling and feature stabiltyā as much as UEFN and Virtual Production tooling at this point.
we have had a very long time to overcome dx11ās shortcomings and know how to handle it. DX12s pso pre 5.3 the and even post 5.3 auto precaching is a headache in and of itself. Iām simply confused at this point because I donāt see Fortnite dropping sm5 or dx11 support anytime soonā¦. But maybe because Fortnite disabled lumen in sm5 a while back thereās a conflict of interest with PRs that contradict this at the engine level when dumping the Fortnite merge CLs back to the engine release branches. 
Also as you stated the docs and release notes made zero mention and continue to mislead the community as it states DX11 SM5 for SWRT lumen is the min requirement
I remember the studio I was with counting down the days to 4.7 ā 4.8 etc. The reality is that UE4 has almost as long of a list with deprecated APIs third party tooling (google play, meta, consoles, steam sdk) that itās been left in a state that is almost as challenging as starting with UE5 and fighting its battles. (Even if you start in 4.27-plus) [Iām not even going to open the fab migration and storefront changes pandoriaās box and what that did to anything older than UE5ās workflow.]
