Unreal Engine 4.20 & 4.21 and beyond

[kpedersen]

Hi malavon,

Hope things are going well with your other commercial project!

I have been faffing about with the internals of UE4 for a slightly unrelated project (ugh Hololens!). I then started pondering how far we could go without Vulkan support. I.e you mention that it does all still compile other than the Vulkan parts.

This is more of a thought exercise because I am rarely in a rush for updates personally (I often lag behind many versions!). Though if one was necessary, I suppose we could keep going like normal and just neglect the Vulkan parts until a day when Epic will likely clean them up anyway and then perhaps it could be re-considered.

My reasoning is that I have had to hack in a few parts in DirectX for the UWP / Hololens stuff. I encountered some Vulkan parts that I don't have much of a clue on and don't really intend to learn anyway... so they might as well not be there

 

[malavon]

Ok, a small update. When Epic released the 5.0 EA* version I just had to see if I could get that one working and couldn't stop until I had at least found the Vulkan issue.

Let's start with the good news: I've been able to find where it all went wrong with the setup and I barely dare say it honestly. A bunch of assumptions that turned out bad and me looking at all the wrong places caused this. I'll explain more when I finally manage to create something that's working without issues.
Now the bad news along with the better news: the current implementation of the memory management code seems to have some issues where it goes out of (video) memory badly. A 4Gb card just no longer runs the InfiltratorDemo - which was originally shown on a GTX 680 with 4Gb VRAM - and it crashes on basically all other projects. However ... I've been re-implementing it by integrating an open source Vulkan Memory Manager and have had quite good success with it. I'm still trying to integrate it in all code without crashing but it looks like it should be possible. Most likely I'll be releasing - eventually - with this code instead of Epic's. That is unless Epic releases a 4.26.3 with fixed Vulkan code which would render all of my work useless :-D

* Unreal Engine 5 could actually work on FreeBSD as it is right now, I haven't seen much that could really stop me. There is one thing though: the build system no longer uses mono, instead it uses dotnet core (3.0) and apparently the included C# compiler segfaults when running under the Linuxulator. I think we're missing some kernel calls or libraries to run the more recent dotnet versions - as also evidenced that they're not in ports. I didn't look into it too much so I might eventually find out that it's an easy fix.

 

[kpedersen]

Hmm, interesting update. It looks like there is some substantial thought and implementation going into this. Nice work!

Quite interested in trying out UE5. I know it isn't really quite as extreme as UE3 <-> UE4 but since it is a major release I thought I should try it out.

A little disappointing they are still using mono for the build system, ubt, etc. Surely an interpreted language (i.e Python) or a light language (Lua) would be so much less of a faff. The technology behind Mono (and Java) is very unportable contrary to popular belief. Since all it is really doing is generating text, it is almost irritating it needs a complex VM requiring "exotic" kernel calls.
(Perhaps I am just bitter because I needed the entirety of Mono installed just to extract a file in my other project )

 

[malavon]

Quite interested in trying out UE5. I know it isn't really quite as extreme as UE3 <-> UE4 but since it is a major release I thought I should try it out.

I like it, or at least the bits I've seen up to now. It's still UE4, but with a few nice extra additions like Nanite. I really like the UI though, much cleaner than the UE4 one. Except for the Dotnet Core part it should be possible to port I think.

A little disappointing they are still using mono for the build system, ubt, etc. Surely an interpreted language (i.e Python) or a light language (Lua) would be so much less of a faff. The technology behind Mono (and Java) is very unportable contrary to popular belief.

It's even worse, it's the Microsoft version of it. At least Mono runs natively, Dotnet Core runs in Linux emulation mode. I really would have preferred an existing build system tbh. CMake would make a great addition to it, especially if Epic were to implement their Unity (I always chuckle when I see that term) build natively under CMake. I'm sure that 90% of the modules could easily build with CMake, it's just that the remaining 10% is full of cyclic dependencies. Then again that's a consequence of having a build system that allows bad coding habits to work.

 

[malavon]

Ok, it has been a long time replying in this post...but I've recently released version 4.26.2. Release notes etc can also be found over there. They're quite extensive this time and contain some interesting information.
I have added a "discussion" on GitHub in case anyone might want to list up some things that work or don't work. Compilation issues etc can also be addressed over there if need be.
Note that I've released this one using a script, so if you were following the repo you may have seen a gazillion different release pop up. Just testing the script...

There are many reasons it took me this long, but most of them aren't very relevant and considering the timeframe I've forgotten them anyway. One however is interesting:
I'm trying to "prep" the UE4 releases to be as resilient to (FreeBSD) changes as possible. Ever since epic released UE5 previews I've known that UE4 wouldn't last very long anymore. And since every FreeBSD upgrade (with new LLVM etc) breaks my UE4 ports, I needed to make some changes. So, that's pretty much what I've been doing for the last 4.x releases. Also note that I chose no longer to port intermediate versions (e.g. 4.26.1), hoping it would gain me some time.
Part of getting it a bit more resilient is also to make it more usable. I've ported the USD importer and it's also possible to use the glTF format for models. Bot importers seem to work well.

On another note: there is no more custom Vulkan implementation either. Ever since the new NVIDIA driver (470.10x) I've no longer experienced any issues with Vulkan going out-of-memory on the InfiltratorDemo. I'm not 100% sure if that's the cause, it may have something to do with other fixes I've done. Anyway, I'm certain there is no more need for a custom implementation, so that's a win for sure.

There's a lot of nice stuff in this release and I'm quite happy I've been able to finish it. The next and last UE4 release (4.27.2) will focus on getting it even more usable on FreeBSD.

And one last thing I've been wanting to say, but couldn't really without getting up to date with the releases a bit: I've been granted a small Unreal Dev Grant for keeping the FreeBSD port running. It's nice to know Epic at least acknowledges the port.
Maybe I should start adding the Dev Grant logo on the UE4Editor splash screen