Hacker News Reader

Comment by robmerki | Hacker News Reader

I am always skeptical of tech demos like this, but if Epic has truly created a way to show full quality assets at runtime without manual LOD / optimization, then this is going to be a huge process improvement for game development. Same goes for this lighting. Baking lights is such a burden, if they can simply do all of this at runtime then making beautiful games just became that much easier.

They also bought Quixel, which gives all of these photo realistic assets to any Unreal Engine developer (even if you're some kid building a game for free). Not sure how Unity can keep up with this.

View on HN

I'm normally skeptical of tech demos, but normally they don't actually talk about the tech. Assuming the actual promises aren't misleading, this is extremely impressive.

> Not sure how Unity can keep up with this.

Unity still has a big edge on usability. Unreal is very much a AAA tool: you have to use C++, all the built-in systems have a much steeper learning curve, etc. Even as a professional dev who's tried a few times to get into it for fun, it's just too much headache for my level of project. Whereas I can whip something together in Unity really easily. All that said, this definitely widens the gap for actual studios. If you have the time and know-how to use Unreal, you have even less reason to consider Unity now.

You don't have to use C++, you have Blueprints, which can control not only shaders, but also game logic and levels.

If you're a programmer who wants to write code, you have to use C++

I'm a programmer and I love unreal's blueprint. Unreal's c++ on the other hand, I hate it.

You can also use SkookumScript, although I wouldn't. Blueprints can also be compiled down to C++.

Nah, you can do a minimal binding and write most of it in something else. E.g. Rust. Considerable boilerplate work initially for sure but possible.

For a non-programmer getting into games, C++ isn't that much larger leap than C#. Also, as others said, you have blueprints. They're not bad - though hopefully there will be some investments made into ergonomics of their use.

Ehh this is debatable. After searching for a memory bug in a AAA game C++ codebase for hours, you might feel differently

Which kind? Most of the memory problems (in particular leaks and null pointers) happen just as much in managed languages, so you'll have your fair share of those bugs in C# games as well.

Trying to find a GC-related crash on a stale pointer that is only reproducible in a Shipping build on a single platform is fun (depending on your definition of fun)

(Shipping in UE4 means release mode with full optimization enabled, most logging & profiling stripped out, etc)

That's not entirelly true, there are for instance Python bindings, and I think some work exists on bindings for other languages. I just think they don't always have a lot of support until a case exists where it ends up being really valuable. Film studios in the case of Python.

https://docs.unrealengine.com/en-US/PythonAPI/introduction.h...

Unreal's Python integration is incredible. I made some modifications to it at work to run a version of WinPython (both for loose scripts outside the engine and pip access)

It's great for complex asset pipelines and quick one-off editor scripts, at least in my experience.

The only thing that felt a bit wonky to me was attempting to use bitflag enums.

That's actually good to hear. I haven't used it, but it seems that it's important for some clients!

Blueprints felt to me like they made a lot more sense if you knew how C++ worked, but I only used UE4 a little bit to toy around with it

I looked at unity and unreal 4 before starting to learn an engine. Unreal is great, but the massive amount of tutorials and documentation is why I started with unity. I really hope unreal 5 can do something similar in the distant future. Before unreal 6 is released.

Unity pays lip service to AAA but its primary market segment mobile game development (which is nearly half of the entire gaming market).

And indie devs. A ton of indie games are on unity on the desktop.

And Hollywood, just like with Unreal, some studios are adopting Unity instead.

Don't you still need to do some of that just for file size and data transfer, if nothing else? In the demo they said it had hundreds of billions of triangles. Google tells me you can get down to 18 bytes or so per triangle, but even if we assume a lower bound of just three bytes per triangle (amortized storage of 1 vertex per triangle of an x,y,z point), we're talking about on the order of terabytes to just store that scene, right?

"virtual" is the keyword. They do some magic to not calculate or store most of it, most of the time.

I'm pretty sure the virtual word here refers to the geometry being in a virtualized form, meaning that the renderer refers to it but the GPU does not have all of it in RAM but instead is paged in on demand.

This paper about geometry images[0] was mentioned on Twitter from an old post by the programmer who implemented the functionality in UE5. Geometry images encode geometry in rectangular 2D textures that can be reconstructed later (the paper is kinda old for this, but i guess it can be done on a computer shader nowadays). If those images are stored as virtual textures, which are supported by the GPUs nowadays, they could be essentially using sparse textures/resources to store geometry.

[0] http://hhoppe.com/gim.pdf

This would be awesome tech if everyone had gigabit fiber. You could just stream all the assets during loading time or if possible during gameplay. On second thought, 125MB per second probably wouldn't be fast enough. A 30 second load time would only result in 3750mb of assets at best. 4k on a Google Stadia doesn't sound bad if the latency is good.

Somebody on reddit calculated that those Zbrush character models in demo are roughly 125MB in size.

Instancing is the key, for that part of this demo at least. One statue replicated 300 times only costs slightly more than one of those statues alone.

Wow that's obvious in retrospect. Thanks!

That's assuming 6 bytes per vertex, 3 vertices per triangle? Most assets use triangle strips, which averages closer to 1 vertex per triangle. They also said the souce mesh is in billions of triangles, but their Nanite pairs that down to 10's of millions. At ~1 vert/tri * 6bytes * 100mil tri, that's 600MB of meshes. Keep in mind this is just a demo, so they can pack what would normally be an entire level into one room. A whole game might end up be equivalent to a couple of demos after they manually optimize even more.

I was going off of this:

> Thus, when vertices are shared, the total amortized storage required per triangle will be 12 bytes of memory for the offsets (at 4 bytes for three 32-bit integer offsets) plus half of the storage for one vertex—6 bytes, assuming three 4-byte floats are used to store the vertex position—for a total of 18 bytes per triangle.

From here: http://www.pbr-book.org/3ed-2018/Shapes/Triangle_Meshes.html

And I they said hundreds of billions of triangle, not just billions (timestamp 6:29), but another commenter made a point that's obvious in retrospect that it's a ton of reused assets, not hundreds of billions of totally independent triangles.

>even if we assume just three bytes per triangle,

that give's you up to 16.7m (2^24) possible triangles. Your napkin math is way off,

I edited it to clarify I meant that as a lower bound. Even if it were somehow achievable, 3 bytes per triangle times hundreds (plural, so at least 200) of billions of triangles is at least 600 billion bytes: 600 gigabytes.

In reality its the same rock mesh 1000s of times.

You can use delta compression, you can even use lossy compression. It doesn't matter if a vertex is at x=1.001 or x=0.998 if it looks good enough.

That said, yes, of course, assets are getting enormous - Call of Duty: Modern Warfare - 175.2GB on PS4.

There was a post about the new MS Flight Simulator and how it'll stream high-def textures from the "cloud" during gameplay, because it has petabytes of textures.

I'm mostly concerned about the storage and bandwidth issues associated with this level of detail.

Are we going to download 500GB games on our Playstation 5s?

Gears of War with updates is 250G, so yeah, looks like it.

Call of Duty: Warzone requires over 100Gb free on the PS4 disk just to download updates.

Maybe we'll go back to the days of cartridges. Imagine getting a 1TB SSD that you push into your PS5

Presumably at some point the standard model for games will be streaming as you play.

Maybe, but some assets could have smaller sizes; instead of distributing a mesh with 500k vertex in LOD0 and various other LODs with less, you could distribute a single mesh with 50k vertex, then do some passes of catmull-clark subdivision on it during loading. Wouldn't work the statues and rocks seen in the demo, but good for weapons, cars etc.

As far as I know, Quixel still requires a subscription, and the assets can still be used in Unity. But the dynamic LOD optimization is definitely a killer feature.

Quixel is free for use with Unreal. The pricing structure for all other content tools is the same as it was before Epic bought Quixel.

I think it remains to be seen. Unity's big upcoming feature seems to what they call the Data Oriented Technology Stack. Essentially, this supposedly allows you to put far more non-static objects onto the screen than is usually available in a game engine. I do agree though that what Epic's doing here is a huge deal.

I love the Unity's efforts with ECS, but how many games would benefit from it?

That's the big question, isn't it? Obviously every mobile game is going to benefit from it, because it will save battery life. The greatest question related to this for me is how many games that couldn't be easily made before are now doable? I imagine that Total War style games will be much easier to make with Unity.

Wow! Quixel looks amazing!

I've been hobbyist in Unity for a long time. But I think I'll switch to Unreal just for that.

Reply on news.ycombinator.com