4 ms·

That video's amazing because the part of the UE5 demo I can't wrap my head around is where Nanite magically turns 1 billion triangles of source art to 20 millio

That video's amazing because the part of the UE5 demo I can't wrap my head around is where Nanite magically turns 1 billion triangles of source art to 20 million triangles of rendered art, per frame. And then I get a minute into the UE3 video from 2004 and what do I hear? "The scene you're seeing here is about 1 million polygons of in-game assets, which came from about 200 million polygons of source art." Then, deja vu, right into a realtime lighting demo.

glenvdb 6y ago
So... UE5 is Malibu Stacy with a new hat?
dtech 6y ago
> And then I get a minute into the UE3 video from 2004 and what do I hear? "The scene you're seeing here is about 1 million polygons of in-game assets, which came from about 200 million polygons of source art." I know little about game development so might be wrong, but I think what that 2004 demo means is they had a 200M art asset geometry which was pre-rendered/transformed into a 1M in-game asset. This kind of reduction has been the standard for decades. What they are indicating in this UE5 demo is that the engine dynamically adjusts the LoD of the source geometry so the engine can render it, the engine directly uses the art asset.
- muro 6y ago
  +1 I also think they have multiple levels of detail and render the appropriate one based on distance/view. Should have said so though, as is, it's full of misleading statements (often by omission).
rsp1984 6y ago
That video's amazing because the part of the UE5 demo I can't wrap my head around is where Nanite magically turns 1 billion triangles of source art to 20 million triangles of rendered art, per frame. I was wondering about that too. My best guess is that they put the heavy geometry items in an acceleration data structure and then ray trace / cone trace these in a first pass to get the points where the camera rays intersect the geometry. Then generate triangles on the fly from these points in every frame. This would be quite similar in flavor to GigaVoxels [1] or the (IMO unjustly much hated) "Unlimited Detail" engine [2], except that instead of shading / visualising the intersections directly they just use it to generate triangles as another input to their overall pipeline. If you look at the video closely all the heavy geometry items are static, i.e. they don't deform. This matches with a classic limitation of ray tracing as deformations invalidate the acceleration data structures used for making ray tracing efficient. [1] http://gigavoxels.inrialpes.fr/ http://gigavoxels.inrialpes.fr/ [2] https://www.youtube.com/watch?v=gM6QkPsA2ds https://www.youtube.com/watch?v=gM6QkPsA2ds
- tayistay 6y ago
  If you're already tracing camera rays, you have everything you need, so why generate triangles? (GigaVoxels doesn't generate triangles)
  - rsp1984 6y ago
    Because not everything in the scene is static and the entire rest of the pipeline works with triangles.
    - tayistay 6y ago
      I'm not convinced, because mixing ray-marched and triangulated geometry is quite doable. If you've already computed a ray intersection, generating a triangle and putting a burden on vertex processing makes little sense if the geometry is static. If you wanted it to be deformable, then yes you may want to use a vertex shader. But in this demo, none of the high resolution geometries are deformable AFAICT.
- fluffything 6y ago
  In the video they mention that the "heavy geometry" you are talking about is 100s of billions of triangles. Storing 1 billion triangles using 32-bit floats takes ~12 Gb, so we are talking about N * 12 Tbs only in triangle storage for this demo. Building an acceleration data-structure on top of this would also take up a lot of storage, so I don't think how you can make this approach successful on a PS5 with limited GPU memory. To me this tech sounds more like they finally figured out all the quirks around how to properly construct "seamless geometry atlasses" (geometry images) and reconstruct geometry from them, and managed to bring that to production. It required quite a bit of compute, and there were also a lot of quirks about how to automatically "cut" an input geometry so that you can put it in a 2D image, how to compress and decompress the image or parts of it without artifacts (such that you don't get jumps across triangles), etc. That approach doesn't store any triangles, but a 2D xyz (rgb) image that you can use to reconstruct the original geometry from, and to which you can apply all usual image compression algorithms, use all GPU texture features (but for geometry), etc. That's ~15 year old tech, and they mention they have been working on this for over 10 years, so timeline-wise it would fit (search for geometry images, texture atlasses, etc. there was a siggraph talk from ~2005 about wavelet compression of geometry images).

That video's amazing because the part of the UE5 demo I can't wrap my head around is where Nanite magically turns 1 billion triangles of source art to 20 million triangles of rendered art, per frame. And then I get a minute into the UE3 video from 2004 and what do I hear? "The scene you're seeing here is about 1 million polygons of in-game assets, which came from about 200 million polygons of source art." Then, deja vu, right into a realtime lighting demo.

glenvdb 6y ago

So... UE5 is Malibu Stacy with a new hat?

dtech 6y ago

> And then I get a minute into the UE3 video from 2004 and what do I hear? "The scene you're seeing here is about 1 million polygons of in-game assets, which came from about 200 million polygons of source art." I know little about game development so might be wrong, but I think what that 2004 demo means is they had a 200M art asset geometry which was pre-rendered/transformed into a 1M in-game asset. This kind of reduction has been the standard for decades. What they are indicating in this UE5 demo is that the engine dynamically adjusts the LoD of the source geometry so the engine can render it, the engine directly uses the art asset.

muro 6y ago
+1 I also think they have multiple levels of detail and render the appropriate one based on distance/view. Should have said so though, as is, it's full of misleading statements (often by omission).

rsp1984 6y ago

That video's amazing because the part of the UE5 demo I can't wrap my head around is where Nanite magically turns 1 billion triangles of source art to 20 million triangles of rendered art, per frame. I was wondering about that too. My best guess is that they put the heavy geometry items in an acceleration data structure and then ray trace / cone trace these in a first pass to get the points where the camera rays intersect the geometry. Then generate triangles on the fly from these points in every frame. This would be quite similar in flavor to GigaVoxels [1] or the (IMO unjustly much hated) "Unlimited Detail" engine [2], except that instead of shading / visualising the intersections directly they just use it to generate triangles as another input to their overall pipeline. If you look at the video closely all the heavy geometry items are static, i.e. they don't deform. This matches with a classic limitation of ray tracing as deformations invalidate the acceleration data structures used for making ray tracing efficient. [1] http://gigavoxels.inrialpes.fr/ http://gigavoxels.inrialpes.fr/ [2] https://www.youtube.com/watch?v=gM6QkPsA2ds https://www.youtube.com/watch?v=gM6QkPsA2ds

tayistay 6y ago
If you're already tracing camera rays, you have everything you need, so why generate triangles? (GigaVoxels doesn't generate triangles)
- rsp1984 6y ago
  Because not everything in the scene is static and the entire rest of the pipeline works with triangles.
  - tayistay 6y ago
    I'm not convinced, because mixing ray-marched and triangulated geometry is quite doable. If you've already computed a ray intersection, generating a triangle and putting a burden on vertex processing makes little sense if the geometry is static. If you wanted it to be deformable, then yes you may want to use a vertex shader. But in this demo, none of the high resolution geometries are deformable AFAICT.
fluffything 6y ago
In the video they mention that the "heavy geometry" you are talking about is 100s of billions of triangles. Storing 1 billion triangles using 32-bit floats takes ~12 Gb, so we are talking about N * 12 Tbs only in triangle storage for this demo. Building an acceleration data-structure on top of this would also take up a lot of storage, so I don't think how you can make this approach successful on a PS5 with limited GPU memory. To me this tech sounds more like they finally figured out all the quirks around how to properly construct "seamless geometry atlasses" (geometry images) and reconstruct geometry from them, and managed to bring that to production. It required quite a bit of compute, and there were also a lot of quirks about how to automatically "cut" an input geometry so that you can put it in a 2D image, how to compress and decompress the image or parts of it without artifacts (such that you don't get jumps across triangles), etc. That approach doesn't store any triangles, but a 2D xyz (rgb) image that you can use to reconstruct the original geometry from, and to which you can apply all usual image compression algorithms, use all GPU texture features (but for geometry), etc. That's ~15 year old tech, and they mention they have been working on this for over 10 years, so timeline-wise it would fit (search for geometry images, texture atlasses, etc. there was a siggraph talk from ~2005 about wavelet compression of geometry images).