I saw your last message. It works for me, and I wrote a plugin based on it. it works on 5.4 and 5.5
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.
Seriously? 
Tested on 5.5.3 and 5.5.4 with a new blank project, 100 percent repro. 
Could the developers at Epic please stop this trolling?
7 Likes
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:
int32 FGeomObject::GetObjectIndex()
{
if( !GLevelEditorModeTools().IsModeActive(FGeometryEditingModes::EM_Geometry) )
{
return INDEX_NONE;
}
FEdModeGeometry* mode = (FEdModeGeometry*)GLevelEditorModeTools().GetActiveMode(FGeometryEditingModes::EM_Geometry);
for( FEdModeGeometry::TGeomObjectIterator Itor( mode->GeomObjectItor() ) ; Itor ; ++Itor )
{
if( (*Itor).Get() == this )
{
return Itor.GetIndex();
}
}
check(0); // Should never happen
return INDEX_NONE;
}
And itās happening at the check(0); // Should never happen line. So something that should never happen, is happening.
1 Like
@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.
2 Likes
5.3 working fine, 5.5 crashing. 5.3:
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.
Is this the same you already posted, or something new?
If itās such an important feature and you absolutely need it, Iād suggest sticking with 5.3 then.
1 Like
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
3 Likes
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 
5 Likes
I think everyone wants LTS support.
4 Likes
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.
Thereās also QoF, but they barely release anything. UE4 is stable but it lacks many new features of courseā¦
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.
2 Likes
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?
It occurs on any mesh with a subsurface profile material with a directional light when you bring the camera close.
This is literally a default metahuman in the asset preview window in a blank project.
I submitted 2 bug reports since December and they just get ignored.
Can someone try to reproduce it on their machine so I know if it just me or not, I swear Iāve seen it in peopleās Youtube videos as well.
Is that project using virtual shadow maps? Does it still do that with regular shadow maps?
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.
1 Like
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.
1 Like