Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UE5 Nanite in WebGPU

github.com

Post reply on HN
Print view View original

81–90 of 117 posts

Re: UE5 Nanite in WebGPU

#81

Post by kllrnohj »

jsheard wrote: post #77
kllrnohj wrote: post #74

Earlier quoted context omitted.

In theory Nanite is superior to precomputed LODs. In practice it's less clear cut as they aren't going to be as good as artist-created LODs and it's not entirely reasonable to expect them to do so. Also the performance cost is huge as Nanite/virtual geometry is a poor fit for modern GPUs. iirc peak fill rate is 1/4th or something like that as GPU rasterization works on 2x2 quads not per-pixel like shaders do.

Rasterizing very small triangles in hardware is indeed inefficient due to the 2x2 quad tax, but one of Nanites tent-pole features is a software rasterizer which sidesteps that problem entirely. IIRC they said that for a screen entirely filled with triangles roughly the size of a pixel, their software raster ends up being about 3x faster than using the dedicated raster hardware.

Yes but I'm talking the other way around. Nanite is 1/4th the performance for triangles that aren't 1-3 pixels in size, which is the majority of the time.

The main selling point of Nanite is really just to reduce artist costs by avoiding manual LODs. But a high quality automatic LOD at build time may (read: almost certainly does) strike a much better balance for both current and near future hardware

Re: UE5 Nanite in WebGPU

#82

Post by flockonus »

theogravity wrote: post #28

Using latest chrome on M2 Max for the jinx demo: WebGPU error [frame][validation]: Fill size (7398781) is not a multiple of 4 bytes. - While encoding [CommandEncoder "main-frame-cmd-buffer"].ClearBuffer([Buffer "rasterize-sw"], 0, 7398781).

If helpful to author, on M1 no errors, can see 15+ fps at all times.

Re: UE5 Nanite in WebGPU

#83

Post by jsheard »

kllrnohj wrote: post #81
jsheard wrote: post #77

Earlier quoted context omitted.

Rasterizing very small triangles in hardware is indeed inefficient due to the 2x2 quad tax, but one of Nanites tent-pole features is a software rasterizer which sidesteps that problem entirely. IIRC they said that for a screen entirely filled with triangles roughly the size of a pixel, their software raster ends up being about 3x faster than using the dedicated raster hardware.

Yes but I'm talking the other way around. Nanite is 1/4th the performance for triangles that aren't 1-3 pixels in size, which is the majority of the time. The main selling point of Nanite is really just to reduce artist costs by avoiding manual LODs. But a high quality automatic LOD at build time may (read: almost certainly does) strike a much better balance for both current and near future hardware

Nanite batches up triangles above a certain size threshold and sends them to the hardware rasterizer instead, since it is faster to use it in those cases. This was all documented from very early on.

Re: UE5 Nanite in WebGPU

#84

Post by elabajaba »

KronisLV wrote: post #67

I wonder how other engines compare when it comes to LODs and similar systems. Godot has automatic LOD which seems pretty cool for what it is: https://docs.godotengine.org/en/stable/tutorials/3d/mesh_lod... Unity also has an LOD system, though despite how popular the engine is, you have to create LOD models manually: https://docs.unity3d.com/Manual/LevelOfDetail.html (unless you dig through the asset store and find a…

Intel Arc GPUs are terrible for Nanite rendering, since they lack hardware support for both indirect draws (widely used in GPU driven renderers, Intel emulates it in software which is slow) and 64bit atomics, which are required for nanite.

Re: UE5 Nanite in WebGPU

#86

Post by password4321 »

soulofmischief wrote: post #49
gpm wrote: post #39

Earlier quoted context omitted.

> and use WebGPU all the time I'm curious, what for?

I've used it to build and/or run various machine learning models for text generation, speech recognition, image generation, depth estimation, etc. in the browser, in support of an agentic system I've been building out. Lots of future possibilities as well once support is more ubiquitous!

Your ideas are intriguing to me and I wish to subscribe to your newsletter.

Re: UE5 Nanite in WebGPU

#87

Post by jms55 »

kllrnohj wrote: post #81
jsheard wrote: post #77

Earlier quoted context omitted.

Rasterizing very small triangles in hardware is indeed inefficient due to the 2x2 quad tax, but one of Nanites tent-pole features is a software rasterizer which sidesteps that problem entirely. IIRC they said that for a screen entirely filled with triangles roughly the size of a pixel, their software raster ends up being about 3x faster than using the dedicated raster hardware.

Yes but I'm talking the other way around. Nanite is 1/4th the performance for triangles that aren't 1-3 pixels in size, which is the majority of the time. The main selling point of Nanite is really just to reduce artist costs by avoiding manual LODs. But a high quality automatic LOD at build time may (read: almost certainly does) strike a much better balance for both current and near future hardware

> But a high quality automatic LOD at build time may (read: almost certainly does) strike a much better balance for both current and near future hardware

You can't have a manual LOD for a cliff where half is near the player and should be high resolution, and half is further away and can be low resolution. Nanite's hierarchical LODs are a huge improvement for this.

You're also underestimating the amount of time artists have to spend making and tweaking LODs, and how big of an impact skipping that is.

Re: UE5 Nanite in WebGPU

#88

Post by cubefox »

KMnO4 wrote: post #60
devit wrote: post #24

Name and description are very confusing and a trademark violation since despite the claims it seems to be completely unrelated to actual Nanite in UE5, just an implementation of something similar by a person unaffiliated with UE5. There is also Bevy's Virtual Geometry that provides similar functionality and is probably much more useful since it's written in Rust and integrated with a game engine: https://jms55.github…

I don’t think it’s really an issue. It’s clear from the readme that it’s an implementation. If I made an “implementation of OpenAI’s GPT-3 in JS” you would understand that to mean I took the architecture from the whitepaper and reimplemented it.

The technique is commonly called virtual geometry or virtualized geometry, or dynamic LOD in research papers. Really no need to reuse the name of a specific implementation.

Re: UE5 Nanite in WebGPU

#89

Post by ksec »

Animats wrote: post #17

Oh, nice. Third party implementations of Nanite playback. Nanite is a very clever representation of graphics meshes. They're directed acyclic graphs rather than trees. Repetition is a link, not a copy. It's recursive; meshes can share submeshes, which in turn can share submeshes, all the way down. It's also set up for within-mesh level of detail support, so the submeshes drop out when they're small enough. So you can…

>Current GPU designs are a mismatch for Nanite, Some new hardware operations are needed to do more of this in the GPU, where it belongs. Whether that will happen, with NVidia distracted by the AI market, is a good question.

Unreal 5 was only released in 2022, and we have been iterating the Nanite idea since then. With Unreal 5.5 and more AAA Gaming titles coming in and we can take what we learned and put into hardware. Not to mention the lead time is 3-4 years down the road. Even if Nvidia decided to make one in 2023 it would have been at least 2026 before we see any GPU acceleration.

Post reply on HN