UE5 is an urban myth, a legend 
Iād rather get 4.28 with properly working RTXGI (and supported in forward renderer), production ready GPU Lightmass, performant Chaos physics and much needed VR fixes, than UE5 that wonāt be usable until UE5.x most likely (especially for VR).
As far i understand UE5 is still almost same as UE4 except some old stuff removed like PhysX etcā¦ and added SSGI+Distance field GI+HeightField GI=Lumen and realtime Mesh Streaming with polygon culling or something similar(Nanite), 64 floating point prescision, but everything else almost same like now. Correct me if wrong but those are my observations. NB: Take this as grain of salt and i might be **very very **wrong.
I was mostly just wondering about the timeline, not the features. If 4.27 is officially scheduled to come out in the spring, that puts UE5ās release to the fall at the earliest. Until today I was operating under the assumption that 4.26 was the latest UE4 version planned and didnāt expect or plan for a possibility of another 4.xx upgrade.
RTXGI is able to kill performance even on current-gen consoles. Whatās the point of using the forward renderer which the main advantage nowadays is better performance on VR/mobile?
Thatās the very reason while they work on Lumen GI although they could already keep RTXGI and say āitās doneāā¦ Lumen supposed to give us much better performance than full-blown real-time raytracing.
The remaining things are being worked on. No matter what label they would put on the next builds, 4.xx or 5.0.
4.27 should bring much improvement to Chaos already. Thereās even a lot of Chaos fixes added every week to the 4.26 branch 
Just because RTXGI has bad performance in UE4 doesnāt meant it canāt be performant. Try Q2RTX - runs like a champ on 2060 SUPER in 1080p in HQ. And thatās fully path traced renderer!!!
Btw, I donāt need RTX in forward for VR. I need it for MSAA because TAA in UE4 is horrible and performance taxing (plus for my specific use case it doesnāt work as it blurs up everything).
When Lumen is out, we shall see about it. I bet it wonāt work in PC VR (needless to say no fancy rendering feature in UE5 will work in mobile VR).
Another annoyance in 4.26 is that many BP nodes became much wider, turning hundreds of our immaculately formatted BPs into an ugly mess:
Of course you use source control. Some feature in that new engine versionās gotta be really worth it close to release.
I donāt see 4.26.1 as an option in the Epic Launcher. Will it be available there at some stage, or is the only way to get it to download the source and build it myself?
Is there also a 4.26.1-Chaos release? Or will I have to adjust the build settings to have Chaos enabled, as with 4.25 and prior?
Under 4.26.1, why canāt the buttons in the uxtools toolkit be clicked?
It is normal to click under 4.25.
The iPad received an error prompt ācould not establish pose query processor streamā when it tried to get the Azure Spatial Anchor through ID
We already know the reason, because Microsoftās official Azure Spatial Anchor SDK version has been upgraded to 2.7.0, and the Azure Spatial Anchor SDK version in UEās plug-ins has not been upgraded.When can upgrade the SDK version of the plug-in?
Anyone know if there is a new setting for this? Cant believe this did not affect Epic the way it does us. Nodes that should be tiny are now huge.
RayTraced shadow edges have a subsurface scatter color when the shadow falls on objects that have sub-surface.
This does not always look correct or good as it creates a blotchy-colored shadow edge that looks bad.
Please consider letting us adjust this as a parameter.
I can turn off RayTrace shadows on a light as a workaround, but then no good shadows.
Unfortunately Post Process Shadow Saturation does nothing to reduce it. Itās like RT Shadows bleed color when on objects with sub surfaceā¦
+500000 for this. I was wondering why my outdoor scenes looked completely wrong with raytracing on.
Iād also love to see raytraced static baking implemented, quite possibly the one feature Iām dying for.
Hey guys! Does anyone had this behaviour in a widget blueprint before that it removes āunusedā widgets?
Actually it just happened in the morning, regular opening of my WB.
Info: Not sure its a bug or something is on its way to fix it, but I really need my content back.
https://answers.unrealengine.com/queā¦nt-999828-form
Something similar was stated as bug but also claimed fixed in 4.26.1 - which is not the case.
It still appears that UE4 is deleting the Widgets content when opening the WB.
I really donāt want to loose days of work spend on that.
(( More info: Used 4.26.0 source when it happened. Filesize of the Uasset file is still ~300kb so it seems that the content like all the text inside must still exist. The removal happens when opening the widget blueprint in the editor but does not save its changes (thankfully). I made a copy of the project and opened it in 4.26.1 - same behavior. Other testing: When trying to add the widget as a part of a widget switcher inside another widget blueprint, it removes the content as well. ))
It would be helpful to get at least access to the content of the widgets uasset or temporary turning off automatic removal to rescue the stuff.
If this would happen on a deadline day, this can risk a job.
@max99x @hard_code This has been logged: Unreal Engine Issues and Bug Tracker (UE-108973)
I hope the blueprint system UI/UX is re-done from scratch. In 2021 and beyond, this doesnāt cut it to be honest. No right-angle links, no wireless nodes, everything gets convoluted really easily.
+1000 for this. Please guys lets focus less on fancy new features, thereās a lot of base features that need serious attention.
That would be a great ānewā feature for UE5. Even a basic, across-the-board polish of whatās already there would work. Here are just a few quick and easy suggestions:
ā¢ Some of the nodes can be resized: utility nodes like Length or == take way too much space, and nodes like [Map] Add tend to blow up with direct text/string values (the right half of the node doesnāt do anything).
ā¢ The Comparison nodes (>=, ==, <=) could probably be merged into a single new node with wildcard inputs and a selection dropdown. Put it on a keyboard shortcut, too.
ā¢ Most nodes can be made slimmer. Trim the empty areas on the sides and the nodeās header, as well as give more space to the areas that require input (usually the left side) over those that donāt.
And so on. Thereās plenty more that can be said, but this is not exactly a suggestion thread, so Iām keeping it to a minimum. Suffice it to say that, as a heavy BP scripter, Iād actually prefer a BP update/polish over some of the new engine features, especially graphical ones. Hereās a haphazardly produced illustration as well:
https://i.imgur.com/FdOqrsQ.jpeg
It would be great to be able to break out properties within a node, such as ālengthā for strings or arrays, instead of having to extract a property with a separate BP node, just to do comparisons or as input to another node. Would make BPs more compact and readable. Also, I like your takes on the comparison node(s). Option C is really nice, because again, you are combining the comparison and branch nodes, which simplifies and cleans up the BP structure.
Absolutely. While with larger structs the separate node does makes sense, most of the smaller ones would really benefit from being expanded within the node, instead of creating a separate one.
And donāt get me wrong, Iām obviously rooting for more features like better connections, but even a slimmer, more polished UI will be perceived by many as an actual new feature, which is exactly what a major engine update like UE5 wants to accomplish.
Also, some of these suggestions may look like purely aesthetic changes, but having to deal with cleaner-looking layouts would result in countless hours of time saved on coding. Clean code is a universal mantra in regular programming. Blueprint scripting would undeniably benefit from it as well. Hereās another quick and dirty prototype comparison while weāre at it (note the amount of wasted space in the originals):
https://i.imgur.com/XuMstI9.jpeg