Interesting twitter thread by sebbbi
The auto generated cluster LOD hierarchy seems to be the secret sauce that nobody else figured out till now. Really impressive how they pulled it all together.
Interesting twitter thread by sebbbi
Good video, thanks for posting!My video should be going live today at 17 and at one point I mention a visual artefact with Nanite that I have seen no one else post about before - I do wonder if it is a feature of how nanite functions or if it is just an issue in the current EA version of UE5. I would be curious to hear what people think could be the cause! Essentially there is a some shuffling of nanite when the camera changes position, not anything like tessellation boiling or a discrete LOD shift, but more as if the world pieces shuffle into place as the camera comes to a rest.
So as Brian noted in his presentation, the consoles already use something more akin to a mesh shader path for the hardware rasterized triangles and while it's an improvement, the software rasterizer still wins for small triangles. The line of where it throws things at one or the other is fully configurable (via CVar) so you can go play with it yourself if you want. As relative efficiencies on different platforms adjust it's easy enough to adjust the optimal point, but at least so far on all platforms the software rasterizer wins for small triangles by a pretty large margin. This shouldn't be terribly surprising honestly... it's not so much "hardware vs software" here as when you get to small triangles you really need to use a different rasterization algorithm. Things like heavy primitive assembly and triangle setup and stamps no longer make sense if you only are drawing a few pixels. Hardware may one day take this back over (and it would be great if it did! There's always more uses for freeing up flops!), but I can't see that fundamental constraint changing any time soon. Making an efficient rasterizer for all different sizes of triangles is going to branch at certain sizes.Do you envision a time in the near future where a software renderer's flexibility will defacto trumps any efficiency gained from the mesh/primitive shader path (like mesh/task shaders beating the input assembler and tessellator) ?
This has been said a bunch of times but bears repeating again... the Ancient scene is extremely heavy and probably not representative of what a game would do. In Brian's talk they go over in a fair amount of detail how they wanted to see how far they could push the kitbashing thing and learned a lot in the process. It's sort of amazing that it works as well as it does, but in a shipping game you would not have dozens of layers of geometry intersecting in a small area like the demo does.wonder why its so heavy, ps5 was rock steady 1440p30 in first iteration, now 2070super stuggle with 1080p
So how much worse will game looks with decent performance and many npc, enemies etc, I’m still hyped by ue5 but perf in 1080p upscaling to 4k id little worrying (is quality of demo sustenable in real game environment)So as Brian noted in his presentation, the consoles already use something more akin to a mesh shader path for the hardware rasterized triangles and while it's an improvement, the software rasterizer still wins for small triangles. The line of where it throws things at one or the other is fully configurable (via CVar) so you can go play with it yourself if you want. As relative efficiencies on different platforms adjust it's easy enough to adjust the optimal point, but at least so far on all platforms the software rasterizer wins for small triangles by a pretty large margin. This shouldn't be terribly surprising honestly... it's not so much "hardware vs software" here as when you get to small triangles you really need to use a different rasterization algorithm. Things like heavy primitive assembly and triangle setup and stamps no longer make sense if you only are drawing a few pixels. Hardware may one day take this back over (and it would be great if it did! There's always more uses for freeing up flops!), but I can't see that fundamental constraint changing any time soon. Making an efficient rasterizer for all different sizes of triangles is going to branch at certain sizes.
This has been said a bunch of times but bears repeating again... the Ancient scene is extremely heavy and probably not representative of what a game would do. In Brian's talk they go over in a fair amount of detail how they wanted to see how far they could push the kitbashing thing and learned a lot in the process. It's sort of amazing that it works as well as it does, but in a shipping game you would not have dozens of layers of geometry intersecting in a small area like the demo does.
So how much worse will game looks with decent performance and many npc, enemies etc, I’m still hyped by ue5 but perf in 1080p upscaling to 4k id little worrying (is quality of demo sustenable in real game environment)
So as Brian noted in his presentation, the consoles already use something more akin to a mesh shader path for the hardware rasterized triangles and while it's an improvement, the software rasterizer still wins for small triangles. The line of where it throws things at one or the other is fully configurable (via CVar) so you can go play with it yourself if you want. As relative efficiencies on different platforms adjust it's easy enough to adjust the optimal point, but at least so far on all platforms the software rasterizer wins for small triangles by a pretty large margin. This shouldn't be terribly surprising honestly... it's not so much "hardware vs software" here as when you get to small triangles you really need to use a different rasterization algorithm. Things like heavy primitive assembly and triangle setup and stamps no longer make sense if you only are drawing a few pixels. Hardware may one day take this back over (and it would be great if it did! There's always more uses for freeing up flops!), but I can't see that fundamental constraint changing any time soon. Making an efficient rasterizer for all different sizes of triangles is going to branch at certain sizes.
This has been said a bunch of times but bears repeating again... the Ancient scene is extremely heavy and probably not representative of what a game would do. In Brian's talk they go over in a fair amount of detail how they wanted to see how far they could push the kitbashing thing and learned a lot in the process. It's sort of amazing that it works as well as it does, but in a shipping game you would not have dozens of layers of geometry intersecting in a small area like the demo does.
Maybe Epic should make Lumen in the Land of Nanite available, so people can compare the performance for themselves.
I really need to get through my Steam backlog. After a few years of Nanite / mesh shaders / GI everywhere older games will become unplayable. They will look ridiculously flat in comparison.
Yes we'll use the SM6.6 stuff when broadly available (both in drivers and the SM6 path in Unreal has stabilized a bit more). Some might guess that it's not a coincidence that made it into SM6.6 in the first placeI noticed that UE5 is using proprietary driver extensions on D3D12 but is there an open possibility where the final release could use SM 6.6 atomic operations ?
Yes, although it's visibility buffer info in the low bits, not colour per se. We write to the visibility buffer with atomics even when using the hardware rasterizer (for a variety of reasons), and sometimes overlap HW/SW rasterization with async compute. (I think that is currently disabled on PC, but it's not super critical to performance either way.)Does the software rasterizer perform depth testing via AtomicOpMinU64 where the depth value is stored in the upper 32 bits and the colour information is stored in the lower 32 bits ?
I wouldn't try and speculate too much on what games will look and perform like at this point. The demos are meant to inspire and show people what is possible, but I have no doubt game teams will find their own balances, and in many cases look even better than these demos.So how much worse will game looks with decent performance and many npc, enemies etc, I’m still hyped by ue5 but perf in 1080p upscaling to 4k id little worrying (is quality of demo sustenable in real game environment)
I really need to get through my Steam backlog. After a few years of Nanite / mesh shaders / GI everywhere older games will become unplayable. They will look ridiculously flat in comparison.
Yes we'll use the SM6.6 stuff when broadly available (both in drivers and the SM6 path in Unreal has stabilized a bit more). Some might guess that it's not a coincidence that made it into SM6.6 in the first place
Yes, although it's visibility buffer info in the low bits, not colour per se. We write to the visibility buffer with atomics even when using the hardware rasterizer (for a variety of reasons), and sometimes overlap HW/SW rasterization with async compute. (I think that is currently disabled on PC, but it's not super critical to performance either way.)
I wouldn't try and speculate too much on what games will look and perform like at this point. The demos are meant to inspire and show people what is possible, but I have no doubt game teams will find their own balances, and in many cases look even better than these demos.
There's no fundamental reason you can't have something that looks the same as the Ancient demo but perform quite a bit better (arguably see last year's demo); it's really more a tradeoff of how the content is *built* than anything. Kit-bashing in the manner done in the demo is neat and convenient to produce a lot of variation quickly from a small set of megascans, but in a production game you'd likely want to either optimize the result further (i.e. remove a lot of the stuff that will never be seen), or build things in a somewhat different way to avoid the performance costs. People are just starting to experiment with how best to the use the tech and I imagine in a year we'll have much better ideas around building efficient content pipelines for UE5.
Honestly I'm impressed at a bunch of the stuff the community has thrown together very quickly and with early access code, and really excited to see what people do in the future!
Yes we'll use the SM6.6 stuff when broadly available (both in drivers and the SM6 path in Unreal has stabilized a bit more). Some might guess that it's not a coincidence that made it into SM6.6 in the first place
I meant benchmarks between last years and this years demo.I think it's too early for people to worry about benchmarking. It's not production ready yet, and not fully optimized. I think there are a select few AAA devs working with it right now, but they have resources beyond the average UE user. For the rest of us I think it's better to just wait, because we have no idea how much performance could improve by the time it's production ready.
Ugh... this again... smhI meant benchmarks between last years and this years demo.
To be honest, I doubt last years demo running on PS5 would be possible on PC right now, as it lacks DirectStorage. The demo, especially in the last segment, was very likely using the NVMe SSD to stream data in and out fast.
When using the drone in the current demo at high speed, it stutters heavily.
I must have missed something. I only know Nanite was 2x more demanding than in last years demo, but that doesn't say much as Nanite is a fraction of overall GPU rendering cost I would imagine.Ugh... this again... smh
And again, you've been told... by Epic employees right in this very thread... that the amount of overdraw and disregard for optimizing this new PC demo VS the PS5 demo, that it's even MORE demanding.
We can actually monitor storage usage as well... There's no bandwidth constraints happening here..
I don't doubt that last year's demo would run just fine on any SSD on PC. Anything which can't be read in time can be precached in RAM.To be honest, I doubt last years demo running on PS5 would be possible on PC right now, as it lacks DirectStorage.