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

71–80 of 117 posts

Re: UE5 Nanite in WebGPU

#71

Post by HappMacDonald »

eigenvalue wrote: post #44

Whenever I see rendered scenes like this (I.e., lots of repetitive static geometry) I imagine that annoying guy’s voice going on about “unlimited detail” from that old vaporware video. I guess nanite really did solve that problem for real, as opposed to whatever that old thing was using (I remember something about oct-trees or something).

I recall those claims being made by a company called "Euclidean", from Australia I think. Online rumors suggested they might have been using octtrees, but later Euclidean videos flatly denied that.

Re: UE5 Nanite in WebGPU

#72

Post by mdaniel »

astlouis44 wrote: post #70

Here's an actual implementation of UE5 in WebGPU, for anyone interested. Just a disclaimer that it will only work on WebGPU-enabled browser on Windows (Chrome, Edge, etc) unfortunately Mac has issues for now. Also, there is no Nanite in this demo, but it will be possible in the future. https://play.spacelancers.com/

I was curious what "issues" Mac has, and at least for me it didn't explode for any good reason, it puked trying to JSON.stringify() some capabilities object into localStorage which is a pretty piss-poor reason to bomb loading a webpage, IMHO

Re: UE5 Nanite in WebGPU

#73

Post by raphlinus »

HappMacDonald wrote: post #71
eigenvalue wrote: post #44

Whenever I see rendered scenes like this (I.e., lots of repetitive static geometry) I imagine that annoying guy’s voice going on about “unlimited detail” from that old vaporware video. I guess nanite really did solve that problem for real, as opposed to whatever that old thing was using (I remember something about oct-trees or something).

I recall those claims being made by a company called "Euclidean", from Australia I think. Online rumors suggested they might have been using octtrees, but later Euclidean videos flatly denied that.

It's Euclideon. And it is octtrees. My interpretation after reading a fascinating Reddit thread [1] is that these denials were misdirection. There's definitely new interest in splatting techniques (Gaussian in particular), though they've long been an alternative to triangles in the 3D world. I think it'd be fun to experiment with implementing some of that using modern compute shaders.

[1]: https://www.reddit.com/r/VoxelGameDev/comments/1bz5vvy/a_sma...

Re: UE5 Nanite in WebGPU

#74

Post by kllrnohj »

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…

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.

Re: UE5 Nanite in WebGPU

#75

Post by hyperthesis »

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…

This is like when Joel said git stores diffs.

Re: UE5 Nanite in WebGPU

#76

Post by kllrnohj »

NotGMan wrote: post #18
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

I'm a bit out of the GPU game but so this might be slightly wrong in some places: the issue is in small triangles because you end up paying a huge cost. GPUs ALWAYS shade in 2x2 blocks of pixels, not 1x1 pixels. So if you have a very small triangle (small as in how many pixels on the screen it covers) that covers 1 pixel you will still pay the price of a 2x2 block (4 pixels instead of 1), so you just wasted 300% of y…

> So even if you do it in software the point is that if you can get rid of that 2x2 block penalty as much as possible you could be faster than GPU doing 2x2 blocks in hardware since pixel shaders can be very expensive.

Of course the obvious problem with that is if you don't have most of the screen covered in such small triangles then you're paying a large cost for nanite vs traditional means.

Re: UE5 Nanite in WebGPU

#77

Post by jsheard »

kllrnohj wrote: post #74
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…

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.

Re: UE5 Nanite in WebGPU

#78

Post by daemonologist »

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).

Same (different number) on Chrome on Android (Pixel 7).

Re: UE5 Nanite in WebGPU

#79

Post by mbforbes »

Funny coincidence, was just reading through an amazing thread on the three.js form a couple days ago about a web graphics implementation of virtual geometry (nanite). webgl, 2021: https://discourse.threejs.org/t/virtually-geometric/28420

it's closed source, but I found the discussion and description of the tradeoffs interesting

Re: UE5 Nanite in WebGPU

#80

Post by DaoVeles »

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 looked promising but the further into the problem I get the more complicated the entire thing become. Having to construct the entire asset generation pipeline was just way beyond what I could manage in the time frame that would look anything decent and not blow out the memory required.

I did manage to get something that vague resembled large scale meshes being rendered in a staggered level of detail but it ran SLOW and looked like rubbish unless you hammered the GPU to get sub-pixel accuracy. It was a fun experiment but it was far too much for the hardware and too big of a task to take on as a single programmer.

When Epic showed off Nantine... wow they did what I never could in a fashion way beyond even my best vision! It is one of those technologies that when it came along really was a true solution rather than just hype. Yes there are limits as with anything on that scale but it is one of the technical jewels of the modern graphics world. I have said that if Epic was public traded company I would considered putting in a sizable amount of money just based on Nanite tech alone.

Post reply on HN