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

91–100 of 117 posts

Re: UE5 Nanite in WebGPU

#91

Post by runevault »

DaoVeles wrote: post #80
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…

In a past life (2000's) I was doing some dev stuff on Ps3, trying to figure out so decent uses for Cell's mass of compute and working around RSX's limited memory bandwidth while having the luxury of Blu-ray storage to burn through. One such thing I did get a fair way into was something like Nanite - I called it compressive meshing. It is the typical case of misguided engineering hubris at work. The initial work looke…

Keep in mind, it took Epic a long time to get it sorted. I think I saw the primary creator say it took him a decade of research and work to come to the initial implementation of Nanite that shipped in Unreal.

Re: UE5 Nanite in WebGPU

#92

Post by nox101 »

TaylorAlexander wrote: post #9

It says my iPhone 12 Pro Max doesn’t have WebGPU, but I enabled it in experimental features and another website[1] with WebGPU demos now works. Has anyone gotten this working on iPhone? Would be nice if the web app gave more info on what failed. [1] https://webgpu.github.io/webgpu-samples/?sample=texturedCube

WebGPU support is not finished in Safari which is why it's still experimental.

Re: UE5 Nanite in WebGPU

#94

Post by Joel_Mckay »

tech-no-logical wrote: post #59

getting the message No WebGPU available. Please use Chrome. on chrome (Version 129.0.6668.29 (Official Build) beta (64-bit)) , under windows

Look at the #enable-unsafe-webgpu flag in chrome.

Turn it back off when done, as tools like noscript only block webgl tags.

Cheers =3

Re: UE5 Nanite in WebGPU

#96

Post by pjmlp »

sva_ wrote: post #62
pjmlp wrote: post #50

Earlier quoted context omitted.

WebGPU is not supported on Linux, and it won't for the foreseeable future. On Android you should have at least Android 12, with good enough Vulkan drivers, not blacklisted.

> WebGPU is not supported on Linux, and it won't for the foreseeable future. A lot of it runs fine with a flag.

That isn't really something for production use.

Re: UE5 Nanite in WebGPU

#97

Post by guitarlimeo »

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 is actually good at AAA graphics for hardware stacks that don't do raytracing well, but if raytracing gets faster, Nanite becomes more useless as it doesn't work well with raytracing. What Nanite is actually good with is providing LODs for only parts of the mesh, so that might get some longer use in the industry.

https://threadreaderapp.com/thread/1809936882278469878.html

Re: UE5 Nanite in WebGPU

#98

Post by cubefox »

elabajaba wrote: post #84
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.

That's interesting. Are there benchmarks on UE5 games which back this up?

Re: UE5 Nanite in WebGPU

#99

Post by andybak »

TinkersW wrote: post #57
SaintSeiya wrote: post #13

Honest question: It is calim that software rasterizer is faster than hardware one. Can someone explain me why? isn't the purpose of the GPU to accelerate rasterization itself? Unless is a recent algorithm or the "software rasterizer" is actually running on the GPU and not the CPU I don't see how

A couple reasons 1. HW does 2x2 blocks of pixels always so it can have derivatives, even if you don't use them.. 2. Accessing SV_PrimitiveID is surprisingly slow on Nvidia/AMD, by writing it out in the PS you will take a huge perf hit in HW. There are ways to work around this, but they aren't trivial and differ between vendors, and you have to be aware of the issue it in the first place! I think some of the "software…

What's PS? Pixel shader? I'm guessing here.

Re: UE5 Nanite in WebGPU

#100

Post by incrudible »

jms55 wrote: post #87
kllrnohj wrote: post #81

Earlier quoted context omitted.

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 artist…

This is assuming you have this "one big cliff mesh". This is the Nanite mindset: Just let the artists throw anything that comes out of their DCC at it. That is a great value proposition for studios, especially the ones that fail the marriage of art and engineering.

It's a bad value proposition for end-users. Nanite is much slower for the same image quality that a bespoke solution would offer, which is evident with several AAA titles that choose to use in-house tech over UE.

Post reply on HN