Hacker News Reader

Comment by nrjames | Hacker News Reader

The sample project is 100Gb... I think I am going to need a new hard drive.

100GB of rocks.

I love the notion of their nanite engine and basically removing concern about LoD (though we've heard that pitch over many generations of engines), and it looks like they're finally improved on what was a terrible, clunky, extremely dated UI.

What I don't love is that it leans into going crazy with assets. Already games are getting simply ridiculous, with new games hitting 300GB, many with an unending stream of enormous patches (looking at CoD Warzone).

Instead of 100GB of rock meshes and textures, isn't there a benefit to procedural on-demand generation for stuff like this?

Since everything is just from megascans, it might make more sense to have 300gb of photorealistic assets stored on every next-gen device, and (UE5) games can just commonly load from them.

Yeah, at a certain point, it probably makes sense to have a giant library of universal assets like rocks and grass and trees. There's no reason for each outdoor game to keep reinventing the universe.

So basically you’re asking for a node_modules for games!

More like a /usr/lib shared across games on the same console

This is Unreal/C++ we're talking about. If the size of some field somewhere changes, your 300GB will need to be re-cooked...

You can do that with Substance. Store images in a library and procedurally generate textures at runtime.

"and it looks like they're finally improved on what was a terrible, clunky, extremely dated UI." doesn't hold true, it's mostly the same UI with a dark reskin. Certain editor hot paths have been reworked and that's about it. The editor is almost exclusively written in Slate, Epic's in-house Window framework/general GUI module. Slate's got a pretty interesting nested MACRO system. Most definitely not data-driven and pretty much as hard-coded as it gets, redesigning the editor for real would be difficult to say the least. In reality most experienced developers don't want a new design, they are happy with the workflow they have and I have to agree with them. I'm generally happy with the "if it ain't broke don't fix it" reskin decision.

> isn't there a benefit to procedural on-demand generation for stuff like this?

Like how demoscenes do it? I would think a huge trade off is the performance hit (and potential delay / popin) of the generation

In a way procedural generation can be tought of as extreme compression!

What are they storing that the project is that big?

It's a Chia mining plot and a few megabytes of demo project :)

Source high res texture and model assets are quite large.

Graphics and audio are almost always the culprit for large sized games.

Can you compile and run the sample project and have something to walk around in?

Yes. Your first compile may take an hour. It took about an hour and a half to get to a running sample game. You get all the source code for what goes on the target machine. It's here, on Github.[1]

I tried to load the demo used for the UE5 videos, but that's only loadable through the "Epic Games Launcher", which is Windows-only. It's apparently possible to bash that into running under Wine, but I don't have time to make that work right now.

For those who don't know what the deal is with Unreal Engine, there's no charge until you get the first million dollars in revenue. Then they take 5%. The nature of the game industry is that the top 50 or so titles generate almost all the revenue. So, rather than bothering with restrictive licenses for all the little guys, Epic just waits until a successful game starts getting media coverage and shows up on the industry charts, then has their billing department contact the game company.

[1] https://github.com/EpicGames/UnrealEngine/releases/tag/5.0.0...

You don't need the source code to make a executable version of the Game. And it won't take 1 hour on a decent machine.

Reply on news.ycombinator.com