Unreal Engine 5 Early Access Release Notes | Hacker News Reader

Unreal Engine 5 Early Access Release Notes

docs.unrealengine.com

119 pointsksec65 comments

UE5 is a game changer in a lot of ways, but I personally would not begin to migrate any projects over to it yet. They are looking for people to hammer out the bugs with the early access (which is exactly what they should be doing), so you should know what you're getting into if you're going to convert your large project over. You could be in for a lot of pain. I have seen a few reports on /r/unrealengine of projects with custom C++ modules having very little support (docs or otherwise) post-migration.

That said, big features with UE5. Lumen is the biggest imo (bigger than Nanite) because it (in theory) achieves a holy grail of automatic dynamic global illumination, without a super expensive RTX-like raytracing card. The number of lighting problems and lighting-related workflows it will obsolete cannot be overstated.

Nanite is cool, but from my super high-level understanding of the tech, it is only going to work on static meshes where the engine can build the fancy indexes it needs to render dynamic LODs. My understanding is that it won't work on any mesh that needs deformation of any kind (someone correct me if I'm wrong here please).

Well it is an early access after all. Curiosity aside, why would anyone want to migrate?

Because your particular project might really benefit from one or more of the new features?

One reason would be that you have a future (years) ship date and aren't yet in full production (but close). The sooner you adopt the new environment art and lighting workflows, the less sunk cost you'll have in assets/workflows that are now irrelevant.

There are also staffing implications. If you no longer have to create LODs for your environment art, do you reprioritize your environment art outsource budget? Likewise lighting, if we can hit higher quality with 1/3 of the personnel, where does the budget then go to? The earlier you can get a handle on the implications of these new workflows, the better you'll be able to answer those questions.

It's really amazing not having to worry about light maps at all. Also the integration of Quixel Bridge and all the free high quality assets should be mentioned. It's really quick to build something that sounds and looks impressive.

And nonetheless there are hilariously bad scam games on Kickstarter like Dreamworld (which got it's first "funding" through ycombinator)

Agreed, see this thread here on HN that was posted recently about how much of a scam it is...YC backed it too, which is embarrassing to say the least!

https://news.ycombinator.com/item?id=27319457

Lighting is easily the biggest hurdle I encountered trying to build games as a solo dev. It's not particularly hard to understand the concepts, but it's quite unintuitive and labour intensive to get good looking lighting. It was also very prone to engine-specific bugs or tweaks in obscure settings, very frustrating.

I guess like many industries as these new technologies come in there will be old-hands who lament how easy it is for newcommers, but if I could do away with the whole lot and just look at lighting as if I were dressing a movie set, and materials acted exactly as you'd expect, it would be so enabling.

I don't think any old hands will lament how easy things become to get quicker feedback.

It benefits them as well. These aren't substitutes for lighting knowledge and skills. Just more good tools in a toolbox.

I think its a generalised thing. Old Hands will lament that new hands didn't have to suffer nearly as much work/wear/time to produce something very similar.

It's about the seeming unfairness in cost of producing, not the end product. Everyone benefits with the new way (assuming its actually undeniably better). The newcomers also don't have the 'back in the day we had to...' stories either, and will make some mistakes the old hands wont with the new technology.

Lighting a movie set isn't trivial either but it would be nice not to deal with implementation specific settings.

You should look at Unity's high definition render pipeline. It uses physically based lighting so you can just e.g. look up the brightness of a particular light, enter it in, then it will render as you would expect.

And yes, you're right about it being enabling. Anecdotally, I've heard that people coming from e.g. photography background find HDRP insanely easy to get good results and pick up quickly.

Lumen is very cool tech, but it has its imperfections. Namely, fast transitions between lighting will have weird, unrealistic fades. But honestly, who cares, it's very cool.

It's not unique to Lumen either, a lot of RT implementations use multi-frame accumulation to achieve good results, we're just not quite there in terms of raw power to do bounce lighting without it.

This is probably one of those things which will separate next-gen lighting from current gen when we have truly instant bounce lighting fill after a geometry change or light position change.

unfortunately with so many temporal optimizations even anti aliasing is no longer "instant" I think that specifically things like large bounce light changes will have to have some sort of hacky "pre-accumulation" step that is done case by case at least for the forseeable future... ray tracing tech is still gorgeous stuff but again there are trailing edges on so many moving objects because information has to be collected over multiple frames.

I've implemented temporal anti-aliasing, and done poorly it can leave ghosting artifacts, but done well it's like magic how much more detail you can get out of a scene using this technique. There's a really excellent GDQ talk about this by the makers of Killzone: Shadow Fall, and it's like night and day how much they were able to improve volumetrics using temporal stabilization, and for their split-screen multiplayer they basically use it to upsample a half-resolution image with very good fidelity.

With AA it's a little easier, because you can just throw away accumulation data if the new pixel is too far away from the last frame's result, and you might get momentary aliasing but without ghosting. With RT it's a little harder, because that bounce lighting information actually needs a few frames to exist at all.

The best part of unreal compared to unity is the stability. You lose that with experimental and early access modules or versions

> without a super expensive RTX-like raytracing card.

Without a card that supports hardware raytracing, Lumen falls back to a software raytracing mode that carries some limitations[1]

The min-rec non-RTX GPU is a GTX 1070, so there's (roughly) only one generation of supported GPUs that are supported but don't support hardware raytracing. My prediction is that the software fallback will eventually lose support and become deprecated as raytracing cards become more common.

[1] https://docs.unrealengine.com/5.0/en-US/RenderingFeatures/Lu...

> The min-rec non-RTX GPU is a GTX 1070, so there's (roughly) only one generation of supported GPUs that are supported but don't support hardware raytracing.

What about all of the AMD cards? There’s the 5x00 and 6x00 series, peers of GTX 20x0 and 30x0 respectively. None of those AMD cards have raytracing, right?

For Lumen's hardware raytracing:

> Video cards must be NVIDIA RTX-2000 series and higher, or AMD RX 6000 series and higher.

Looking at these image comparisons with the sliders I'm both amazed at how far real time rendering tech has come and the ingenuity on display, but also by how relatively little it matters at this point.

Like the shadow comparison, it's undeniable that it looks better and more details in the "shadow map raytracing" version, but it's not like the reference picture looked all that terrible.

I don't have a particular point to make, but as time passes I feel so privileged to have grown up with videogames in the 90's and early 00's. A watershed moment in computing, where we went from low res 2D graphics to high resolution 3D graphics. We've clearly hit diminishing returns since then.

That might be different once you start wearing VR goggles.

The experience becomes more immersive if you see a realistic world, and not pixels.

The difference is likely in how hard it was to get the original result, and some unseen limitations in the technology.

Game lighting has always been dozens of tricks and shortcuts to get lighting to look like it behaved properly, without it actually behaving properly. But newer technologies work on getting better at lighting and material behaviour and that allows a level of "overall correctness" that is much easier to achieve.

I've made a similar comment previously, but Raytracing can make a Minecraft world feel like real life, because the lighting is correct even if the world is surreal. PBR was a huge leap for lighting correctness, and it's part of the reason why a game with "okay" textures can still feel just as good as a game with incredible textures. I think our brains can pick up on these lighting cues.

I think the difference real-time lighting makes will become more obvious as games cease to be cross-gen and really embrace current generation hardware. Baked lighting can achieve very good, near-photorealistic results in staticly lit scenes with static geometry.

Once we see games really take advantage of dynamic lighting in highly dynamic scenes with a lot of moving elements, I suspect we'll look back at current and recent games and see them as lifeless by comparison.

The main advantage of new technology is interactivity. Dynamic illumination is _dynamic_ instead of statically baked. That has obvious environmental advantages. Comments like yours that pixel peep screenshots miss the point.

These limitations seem imperceptible to you, but are very real in terms of an artists ability to execute on their vision. Most games do not currently have multiple dynamic light sources in a scene. You can go back and play Fear on PC to see that and it's awesome - Doom 3 as well.

But graphics tech optimized away from that direction (rightfully), and now we need to account for dynamic illumination and transparency. Better shadows (especially in interactive moments) is a nice bonus.

Funny you should mention that! I’m around your age or perhaps a little bit older. I was playing 2015’s Arkham Knight last night - a triple-A title in its time and by any measure a good looking game - and was struck actually by how far we’ve come in just the last 5-6 years. I finished The Last of Us 2 recently and the gap between Arkham and that is night and day on every dimension: resolution, lighting, particle effects, textures, animation, temporal reconstruction techniques.

I won’t disagree with your central point about diminishing returns. On the other hand, the jumps are probably bigger than I realised until I went back and looked.

> Nanite intelligently streams and processes only the detail you can perceive, largely removing poly count and draw call constraints, and eliminating time-consuming work like baking details to normal maps and manually authoring LODs, freeing you up to concentrate on creativity.

Not having to create normal maps/LODs seems like a pretty big deal if this is true.

If I understand right normally in games you have multiple discrete versions of the same mesh with different detail levels depending on how close the player is. You sometimes notice this glitching out in games where a model will suddenly pop in to a higher detail.

It sounds like nanite is more like having continuous LOD for the mesh.

I wonder how well it works in practice.

Also curious how it will affect game asset sizes

For non-vegetation non-deforming assets it works great so far. Looks absolutely seamless and works an order of magnitude faster.

Unreal actually already has an automatic LOD creation system (https://docs.unrealengine.com/4.26/en-US/WorkingWithContent/...), and there are quite a number of 3d Content middleware solutions that run this sort of mesh reduction processes. In one sense Nanite isn't anything brand new, but what is really exciting about it is that it operates from the sculpt downwards. As in, you import from zbrush raw, with the highest raw textures, and everything is automatically handled by the engine itself, in such a way that the LOD transitions are really hard to spot.

From what I've seen on Twitter, it looks like it really delivers, even in its early stage: https://twitter.com/IonizedGames/status/1397636481913610241

Now that's impressive. Seeing the dog picture scale out is encouraging. All the LOD algorithms do a good job on rocks. It's all repeated instances of one object, though. I'd like to see someone load in a big game level at high res and give us a tour.

Quadric mesh reduction, where the algorithm tries to minimize the volume difference between original and reduce geometry, does great on rocks. Terrible on thin sheets like cloth or long thin things like hair. Mediocre on objects with lots of hard edges, like houses.

I've been trying to run the UE5 Early Access version on Linux. Building UE5 Editor worked, and I built and ran one of the built-in sample projects. But the files for the demo are only available for download via Epic Game Loader, which is only available as a 32-bit Windows program. Trying to run that under Wine leads to a popup complaining some DLL is missing. But it doesn't tell you which one. Some people have been able to get it to work, probably depending on what Windows DLLs they happen to have installed.

Trying to run Nanite on Linux produces a line of red text saying that the machine doesn't have a supported graphics card or driver. This is with a NVidia 3070 with the current NVidia driver on Ubuntu 20.04 LTS, which is about as good as it gets today.

It's a typical "we tossed the Linux users a crumb" port. Well, it's early access. Filed all the appropriate bug reports.

> This is with a NVidia 3070 with the current NVidia driver on Ubuntu 20.04 LTS, which is about as good as it gets today.

Driver installed by “hand” or via the Ubuntu packages? More importantly: What’s the output of nvidia-smi?

Ubuntu packages. Driver version 460.73.01 Cuda version 11.2. GeForce RTX 3070.

Hmm. The Linux statement for UE4 just says “use latest stable” [1] (which is why I always just download the .run file and install “by hand”).

But your driver was released in April. While there are a lot of serious-ish sounding issues fixed in the 460.80 series [2], I sort of doubt UE hardcoded that. Then again, UE now relies entirely on Vulkan and it feels like every NV driver release has fixed at least one major Vulkan bug, so maybe since they just released it they are asking folks to use 460.80+?

[1] https://docs.unrealengine.com/4.26/en-US/Basics/RecommendedS... (then select Linux from the drop down icon I guess)

[2] https://www.nvidia.com/Download/driverResults.aspx/175203/en...

One of the things I think goes a little underappreciated about Unreal is the fact that everyone gets the source code. Interested in how Nanite or Lumen work? The source is right there! With all the comments (or lack of), with all the debug statements and branches that can be used to diagnose the behaviour of the system.

Often while developing, I dive into the source of the engine to understand how exactly some low level system works. I also blatantly copy all the complex UI widgets available in the editor when I want to extend them/make custom ones for my games (I hate UI programming). This is invaluable for teaching the next generation of engine developers imo.

True, but does it expose you to liability if you later do engine dev work elsewhere? Actually curious how that works

Only if they have patented the algorithms and I seriously doubt Epic sees a future for itself as a parent troll.

Demo was super impressive. Wish they had shown off a wider variety of terrain though. Bit of jungle, bit of snow maybe. Don't particularly blame them, but they were definitely playing to their strengths there

the demo project is 100GB, I dont think I have the hard drive space for more variety at this quality level!

Which would actually be interesting for consoles and even PCs the geometry detail that UE5 supports has a huge cost in terms of storage space the demo project is quite tiny compared to a game but it takes more storage than some chunky titles out there that used uncompressed assets for video and audio like the newer COD games.

People were already complaining about 50-70GB games now it seems that 400-500GB titles might be coming in the next 2 years or so.

I hope there is a resurgence in procedural geometry. Much better to have a nice 1kb rock than an awesome 1GB rock.

my guess is that with this explosion in photogrammetry we're quickly developing enough data to start training neural networks to create procedural geometry... whether that'll be fast enough to happen at run time or even at realtime render time... who knows yet

Recent and related, though without specifics:

Unreal Engine 5 enters Early Access - https://news.ycombinator.com/item?id=27290854 - May 2021 (151 comments)

The introduction of Chaos Vehicles and specifically the "predictable physics simulation that can be replicated over a network" sounds like something they made for Rocket League.

If they have proper physics I'll have to have a look at that, I wanted to try and make my own simracing game in Unreal Engine previously (i.e. use the engine for graphics and inputs etc.), but the built-in vehicles were a step in the right direction but ultimately very hard to try to use realistic physics with.

Does predictable physics mean it can be replicated over a networked game easily?

Yes - but I wouldn't put too much emphasis on the "easily" part. I think that the physics are now pretty deterministic if you run a simulation using the exact same input/setup (on different clients). However, in reality you'd still have to synchronize the state of the objects every now and then (e.g., if a client didn't receive certain inputs on time).

I tried to run this on my 16" mbp (8 core i9, 64gb ram, radeon pro 5500m 8gb). The starter 3rd person template maxed out every single core and I was getting about 17-20 fps.

edit 2016 !== 16", and it was apparently still compiling shaders behind the scenes. Now it's stable at 120 fps.

TBH that's better than I'd expect on an old laptop with an unoptimized build. Like the hardware they're using is what, 20% faster CPU and 400% faster GPU-wise, and they're developing on Windows?

So, I can't type. 16", not 2016.

I think you would need a laptop with more powerful cooling. Your MacBook is most likely throttling a lot to not melt. My 2019 gaming laptop, i9 and a rtx2070, becomes a fan heater if I want good performances in Unreal Engine.

So, I can't type. 16", not 2016.

It's a very nice x86 laptop, but it's still throttling a lot when it gets warm.

It was apparently still compiling shaders behind the scenes. I changed something that caused to it show me the status in an overlay. As soon as those shaders were compiled, it ran totally fine.

Not sure what you expected.. a 5 year old _mobile_ GPU simply isn't cut out for modern gaming.

So, I can't type. 16", not 2016.

I fooled around with it during my lunch break, it really is power hungry. R5 3600/2080 and It still ate all CPU during initialization.

Once running, it was sitting at 30-70% depending on what I was doing.

> "Full Body IK (FBIK)"

I have a sense that this acronym could have been clarified a bit further. After going to the second page of Google results, I now think it's probably "Inverse Kinematics", but it shouldn't have been so hard.

I don't disagree, but the target audience knows exactly what IK means

It's like spelling out JPEG in the release notes for Photoshop. You could do it for good form, but it's mostly a waste of characters.

Sure, I wouldn't be making that comment is they just hadn't expanded the acronym. But assume that you were an otherwise technically savvy reader but unfamiliar with graphical formats, encountering the text "Joint Photographic EG (JPEG)". You'd find that to be a bit weird, no?

The target audience of photoshop knows what it is. The material is for them. It’s not written for random technically savvy people.

Any word on build/import times? Nanite looks great but I wonder how it'll feel working with these large assets at scale. Although, could be cheaper overall than importing all the LODs and imposters you would normally make.

No mention of the scripting language they've been teasing, hope it shows up soon!

Does anyone know what (UI) tech is used for the editor?

There's some info here: https://news.ycombinator.com/item?id=27294649

Reply on news.ycombinator.com