Is UE 4.26.1 the last version of Unreal engine 4?

Since I haven’t heard anything on this topic, I have to ask. Is UE 4.26.1 the last version of Unreal Engine 4? Are we moving to Unreal Engine 5? Is there another patch planned for Unreal Engine 4?

As I understand, not yet, 4.6.2 will be released, the 5 update is a super novades package.

Thanks. Not knowing what the upgrade plan is causing me some concern. I figure UE4 projects will require some conversion efforts to move to Unreal Engine 5.

What worries many is whether they continue to support blueprints, and that this does not disappear as in UDK. However the news is that all projects under development in UE4 will be compatible with UE5.

4.27 is on the horizon sometime next quarter, but I don’t know of any plans beyond that.

UE5 is largely UE4 under the hood because compatibility is a huge part of the effort. There will very well likely be some amount of conversion between 4 and 5, but not that much more than the difference between major versions of 4. I.E. all of your plugins become invalid and will need to be recompiled. Some structural changes will require rewrites on the c++ side. Blueprints should remain intact.


The thread title should be: Will 4.27 REALLY be the last version of UE4? :stuck_out_tongue_winking_eye: Meaning, will 4.27 be stable enough and contain enough fixes for Epic to move on! Not sure what the UDK reference and Blueprints going away remark is all about (above)??? But Epic moved on to UE4 just fine without fixing all the bugs UDK still had, WHICH IS WORRYING! However, moving from UDK to UE4 saw a massive improvement in visual scripting. So will Epic jeopardize that? No! :wink:

While compatibility has been promised, UE5 will be a whole new beast, and it may just be easier to start over on new projects. After all, World Composition is dead, and Lumen, Nanite, Doubles and Verse, make UE5 a substantially different engine already. For that reason I wish Epic had just waited until after 4.27, and then closed out the old forums and started over. When UDK was sunset, Epic at least made sure to differentiate the old forums and docs to avoid confusion. :wink:

What happened with UDK is that many people lost their learning in UrnrealScript, as it was no longer supported. Eventually the blueprints continue.

And as you mention, it will be a brutal change, but beyond what is hidden from UE, it will be the change to new tools where users will have to learn all over again.

A good reason to keep them intact is that a lot of what we’ve learned in UE4 will still be applicable in UE5!

All of the new features you mention are plugins, not integral changes to the engine itself. The roadmap for the engine moving forward is to have everything be a module, at least as much as possible. The means a single UE platform with code sideloaded as needed.

1 Like

Initially yes, but UE5 will diverge from UE4 more and more over time. So from the POV of finding relevant posts / docs going forward, does it 100% make sense to merge them? Not convinced… Especially as all the likes / upvotes also got lost in the forum switchover…

For example, once doubles get added, all the old UE4 posts about large-worlds and origin-rebasing will be irrelevant or much less relevant presumably. So screening those out automatically from web and forum searches would be helpful, no?

Overall, it really helped having UDK posts isolated and separate from the UE4 forums. But I think the biggest problem the Community faces right now, is not so much a lack of posts / docs or learning resources, but a lack of tools to really find or get ‘to the gold’ quickly. We’re stuck with search tools that are decades old.

Yes, that’s right, the UE4 engine as we know it, will be stagnant and will give way to new information on UE5 features, in this case, UE4 will be left as a dead war hero in some field, where some will go crying.

There will be some divergence, sure. But the vast majority of information will still be current. I think to separate them would be throwing out the baby with the bathwater.

I understand your concerns but I don’t see a reason to freeze the information we have and compartmentalize it - people using UE5 will find answers to their questions in the UE4 forums but think the information can’t be applicable still.

There is certainly improvement to be made with regard to the forums, like the images breaking as you pointed out. I just don’t see any benefit to separating the forums. That said I’m fine with it happening. I just want signatures restored and archived images to link correctly :slight_smile:

My understanding is that UE5 is planned for an initial release late this year (IE Nov or Dec). At least that was the plan announced before Covid-19. My concern is plug-ins that I am using from the marketplace. Will they even run in UE5? Also, does marketplace content move to UE5? Lot’s of questions but almost no answers from Epic.

As for UDK, I lost a project I was working on because of the asset scale change and the fact that the compiler just stopped working one day with no advanced notice. I hope Epic doesn’t repeat those problems again. Another thing that concerns me is UE5 compile time. All we saw of the UE5 demo was of a game running on a Playstation 5 but nothing on the tools and/or time needed to create the project. I really wish Epic could do another 5 minute demo video addressing those issues with the understanding that it’s a WIP.

BTW guys, don’t get me wrong. I am one of the biggest supporter of Epic Games. Even a bigger supporter of Epic Games than Bored Gamer is for Star Citizen. I’ve been building levels since the UT99 days. I look forward to moving to UE5, I just want to see what its going to take to get there.

UE5 will neither force anyone to nanite or lumen bacause those need beefy computers like a RTX 2070 or that grade of GPU from what i understood of a little hint tim sweeney gave, but that could be only related to the exact demo shown, wich was not small or trivial in any kind
but with all the compatibility there must be a reason to up the name from UE4 to UE5 beside adding nanite and lumen

It is that every new technology that comes out is based on the computing power that evolves every two years, more power, new cards, new processors and with that you can do new things like the example of the UE5 demo. Now, with these new technologies that emerge, the previous ones are displaced and is where the user, both as a player and developer, feels obliged to update their computing power for the next generation. I don’t know if you remember when GTA V came out, not everyone could play it, years later many new players enter those leagues, because their computing power was upgraded and the business continues. In the case of the engines it is impossible to maintain that technology that eventually becomes obsolete, because it would have to invest time in development and maintenance, then, to buy new cards, new cards and processors if we want to get the maximum performance and power to UE5,

UE5 will only support Nanite for static geo afaik, maybe for all geo, we haven’t seen UE5 in a year and as a guess there’s nothing necessarily impossible in making it work for skinned meshes as well. Either way they’ve already marked tessellation as deprecated, as just one example, and there’s very little chance they’re planning on supporting the entire legacy geo pipeline just for compatibility reasons.

As for lighting, I wouldn’t be surprised to see Lumen also being the only option. Again the entire point of UE5 seems in part to get rid of the pile of tech debt that is UE4 as much as possible. It doesn’t seem like they’re interested in creating an engine that’s as unwieldy and unfocused as UE4 was this time around either, with mentions of being “forward compatible”. They know what UE4 was primarily used for, and it wasn’t tiny indy mobile games, so they’re concentrating on the primary audience.

All that being said, I’d imagine that they still want Fortnight shipping on their primary engine, and for Fortnight to ship on as many platforms as possible. They’ve already stated Nanite isn’t nearly so expensive as it looks, which is not some huge shock. Triangles are ancient and expensive, Dreams is a PS4 game that has geometry probably similar to what Nanite is (and you can animate it!) and it runs fine on a PS4. I’d imagine Lumen and Nanite will be scalable down pretty far. And on top of that you can see changes for 4.27 for the UE4 dev branch. So it seems like there’s at least on last update coming to UE4 this year as well.

I highly doubt they’re gonna ditch static lighting. there was this big push for GPU Lightmass recently so why would they bother doing that for 4.26 only to dismiss it 2 releases later. also dynamic lighting/shadowing always has a higher cost and Lumen won’t be any different - static lighting is still very much a big necessity in the industry so removing it would be shooting themselves on the foot


Please, stop speculating.
Nobody gonna to remove blueprints. They actually a lot of improvements to blueprints with every release. Think for a second, why they would remove it? There’s no reason. Visual scripting is the fundamental part of the modern engine.

They already mentioned that the engine gonna provide a fallback for supporting weaker hardware. If only making a high-fidelity open world would be the option, it would eliminate mobile and small indie games. And yes, indie games are a big part of UE4. AAA open-world usually already have their engines. Epic only widens its reach over time. They’re not gonna abandon indie in any way.

Your plugins gonna be updated the same way as they’re updated with every UE4 update. It’s often requires some code updates. If plugins wouldn’t updated, it’s probably because author doesn’t earn money on it. Some of plugins might simply become obsolete, that happens with the every UE4 update, too.

Again, speculations. As the Engineering Director mentioned in this UE5 presentation, “you can freely mix Nanite and non-Nanite objects in the scene”.

Lumen is just a fancy name for their real-time GI, not the new lightning model. It’s one more feature, simply combining previously existing features and adding a few new things to the mix.
Lumen is composed out of 3 “layers”: SSGI, distance fields and voxel lights (for distant meshes like mountains).

1 Like

Some people thought the same with UDK unrealscript, so anything can happen.

The most drastic changes from UE4 to UE5 is the hardware power, tools, all with the same goal, but for sure more than one will not be able to run the UE5 demo, because every change transcends technology and makes it obsolete, so many will fall by the wayside, either because they do not have the computing power to run in the next generations.

Lumen is just a fancy name for their real-time GI, not the new lightning model. It’s one more feature, simply combining previously existing features and adding a few new things to the mix.
Lumen is composed out of 3 “layers”: SSGI, distance fields and voxel lights (for distant meshes like mountains).

It’s a simplification for others, but the idea is probably to simplify overall is the point. I wouldn’t doubt there’ll be some sort of static option, but what? Are lightmaps really going to stick around, or are they going to do lightprobes only which are better for gameplay, and archviz is just going to run on high end hardware anyway?

You’re assuming just as much as anyone, assuming that the demo shown is the sole target and that it requires super high end harware. They already stated the goal was to make that run at 60fps. I’m just assuming that they’re looking to simplify everything. If nanite can run all mesh types then there will be every reason in the world to get rid of every other geometry type, assuming nanite is fast enough. In fact there’s every reason to try and get nanite to run everything, mixing geometry types freely is just a massive coding headache, needing to extend it towards global illumination and different physics types and etc.

So while we are assuming and speculating, which is the entire point of this thread so its weird to complain about it, I’m just speculating that they’d rather simplify the code base as much as possible and gear it towards what UE is used for. Sure, indy games used UE4, but Abzu and The Outer Wilds are still the sorts of games that can benefit from UE5, as two major examples. There’s every reason to keep UE5 from the sort of overbroad reach UE4 went for initially. Tiny indie games using pixel art or targeting match 3 mobile games or etc. have a ton of engine competition already, UE just isn’t going to benefit overall from targeting hardware too far down.