My two cents on how I guess Nanite will behave on systems with lower I/O performance than the next-gen solutions, or even when next gen I/O is not enough for a given situation that happens to be too demanding.
I'm assuming epic does not want to make an engine that crashes or stutters when things fail to load in time. I mean, there were 1990's 3D games streaming data from CD ROMS with streaming systems more robust and smooth than that.
The easiest assumption to make, is that when geometry data is needed, but hasn't been loaded in time, Nanite will show a Lower LOD of it (the highest one it happens to have in memory by then) and a couple (or several) frames later, the required LOD will have been successfuly streamed into their virtual geo-cache in RAM and the low poly model will be swaped by the High Poly one. Hopefuly, UE5 will have some form of smooth blending to slowly fade or morph from one LOD into the other in these situations so as to make swap less distracting.
Such fading system can't hide obvious swaps happening with large objects way too close the the camera going from the Lowest of the Lower LODs right i to one of the higher ones, granted. But that would be one of the most extreme examples of I/O slowness. A object in the distant BG swapping from one lod level to the next other half-a-second too late, though, would be nearly imperceptible most of the time.
The precedent to make such guess is that this is how most games with a minimally polished streaming sytem do it today. UE3's own texture streaming works exactly like that. Other open world games handle 3D mesh streaming the same way.
That said, if we assume this demo was pushing PS5's IO to its very limits, how would it then look on an XBSX?
Well, the same, except on the moments the camera is moving the fastest (the ones that stress streaming the most) some of the more distant assets would display in slightly lower geometric detail than the nanite's target for twice as many frames more than PS5.
So if when PS5's IO gets pushed the most (when the character is flying through the ruins) some of the assets swap to higher levels of detail as they aproach the camera 1-2 frames later than they should have, that will happen in 2-4 frames in XBSX.
Not the end of the world in my opinion.
Considering the engine is still in development, there are a lot of things it may be lacking still.
Maybe, their streaming is not as polished as it needs to be to not cause stutters and freezing, so they can't run it confidently on hardware that doesn't outperform its requirements 100% of the time.
Maybe they don't have their smooth LOD swapping figured out yet, so those swaps would be more poppy, distracting, and easy to spot (not a good first impression to their -it just works™- system)
In those cases, a PS5 devkit is the safest bet to make a public showing TODAY, as in TODAY that is the machine where you get the most reliable streaming from.
Also, PS5's HW compression uses a more generalized data compression sheme that may provide friendlier prototyping. As I understand XBSX decompressor is texture-centric, so to use it with other data one must encode such data in a texture format (which in essence isn't rocket science) and in a way ends up compression-friendly (that is when things require more testing/refinement). I would guess whatever encodings Nanite uses for geo, they are probably easy to translate into image based formats, it just takes some extra interation time to find the sweet-spot there.
When it comes to PS5 vs PC on Sweeny's comments, as he said "system inegration" It's probably the case that for a dev trying to build a robust high performance engine, they will welcome the ability to go low level when needed, and a console dev-kit is probably the most confortable environment to do that in.
That does not mean that there can't be ways to achieve the same or similar results in other platforms, but when you are still building your engine, the platform of choice will usually gonna be the one where prototyping, testing, debugging, documentation/engineering consulting and general tinkering, is the easiest at. Prototype there first, and then port to the other stuff.
Under those circumstances, it should not be surprising that PS5 ended up being their preferred dev-environment (at least for this demo, for now, and acording to T.S.)
In the future, it might be that with XBSX optimised compression, they end up finding equal or even higher performance there than on PS. They might end up leveraging their extra compute to achieve even higher compression ratios too, thus stressing raw I/O speed less. All is possible as of now. Relax.
Kids can go to bed now, there os no monster under the bed.
I'm assuming epic does not want to make an engine that crashes or stutters when things fail to load in time. I mean, there were 1990's 3D games streaming data from CD ROMS with streaming systems more robust and smooth than that.
The easiest assumption to make, is that when geometry data is needed, but hasn't been loaded in time, Nanite will show a Lower LOD of it (the highest one it happens to have in memory by then) and a couple (or several) frames later, the required LOD will have been successfuly streamed into their virtual geo-cache in RAM and the low poly model will be swaped by the High Poly one. Hopefuly, UE5 will have some form of smooth blending to slowly fade or morph from one LOD into the other in these situations so as to make swap less distracting.
Such fading system can't hide obvious swaps happening with large objects way too close the the camera going from the Lowest of the Lower LODs right i to one of the higher ones, granted. But that would be one of the most extreme examples of I/O slowness. A object in the distant BG swapping from one lod level to the next other half-a-second too late, though, would be nearly imperceptible most of the time.
The precedent to make such guess is that this is how most games with a minimally polished streaming sytem do it today. UE3's own texture streaming works exactly like that. Other open world games handle 3D mesh streaming the same way.
That said, if we assume this demo was pushing PS5's IO to its very limits, how would it then look on an XBSX?
Well, the same, except on the moments the camera is moving the fastest (the ones that stress streaming the most) some of the more distant assets would display in slightly lower geometric detail than the nanite's target for twice as many frames more than PS5.
So if when PS5's IO gets pushed the most (when the character is flying through the ruins) some of the assets swap to higher levels of detail as they aproach the camera 1-2 frames later than they should have, that will happen in 2-4 frames in XBSX.
Not the end of the world in my opinion.
Considering the engine is still in development, there are a lot of things it may be lacking still.
Maybe, their streaming is not as polished as it needs to be to not cause stutters and freezing, so they can't run it confidently on hardware that doesn't outperform its requirements 100% of the time.
Maybe they don't have their smooth LOD swapping figured out yet, so those swaps would be more poppy, distracting, and easy to spot (not a good first impression to their -it just works™- system)
In those cases, a PS5 devkit is the safest bet to make a public showing TODAY, as in TODAY that is the machine where you get the most reliable streaming from.
Also, PS5's HW compression uses a more generalized data compression sheme that may provide friendlier prototyping. As I understand XBSX decompressor is texture-centric, so to use it with other data one must encode such data in a texture format (which in essence isn't rocket science) and in a way ends up compression-friendly (that is when things require more testing/refinement). I would guess whatever encodings Nanite uses for geo, they are probably easy to translate into image based formats, it just takes some extra interation time to find the sweet-spot there.
When it comes to PS5 vs PC on Sweeny's comments, as he said "system inegration" It's probably the case that for a dev trying to build a robust high performance engine, they will welcome the ability to go low level when needed, and a console dev-kit is probably the most confortable environment to do that in.
That does not mean that there can't be ways to achieve the same or similar results in other platforms, but when you are still building your engine, the platform of choice will usually gonna be the one where prototyping, testing, debugging, documentation/engineering consulting and general tinkering, is the easiest at. Prototype there first, and then port to the other stuff.
Under those circumstances, it should not be surprising that PS5 ended up being their preferred dev-environment (at least for this demo, for now, and acording to T.S.)
In the future, it might be that with XBSX optimised compression, they end up finding equal or even higher performance there than on PS. They might end up leveraging their extra compute to achieve even higher compression ratios too, thus stressing raw I/O speed less. All is possible as of now. Relax.
Kids can go to bed now, there os no monster under the bed.
Last edited by a moderator: