Unreal Engine 5 Tech Demo, [UE5 Developer Availability 2022-04-05]

Just like RT, Nanite will do wonders for virtual productions (like the work done on the Mando) but as usual the marketing/PR spiel is made to sound like cancer has been cured.

 

nope, 1440p. at higher framerate


53:00, he said his notebook could run at 1440p 40fps+, optimization target is 60fps for next-gen

 

It's wrong translation, he clearly mention 40fps is the Lumen scene.

A more proper translation here:
https://forum.beyond3d.com/threads/unreal-engine-5-2021-tech-demo.61740/page-27#post-2126234

 

I'm not sure it is a more proper translation as he says "Did not watch the whole 135min lol."
we need more translations

anyway this is a lot interesting as 970 evo is a PCIE ex.3.0, not even the 4.0

 

I jumped to 53:00 (mentioned by you) and listened. ultragpu and Tabris are correct.

 

adecuated disk placement memtioned could be like Spiderman, assets 200 times duplicated to reduce random accesses time.

 

I think the problem there is actually in the sampling. If the sampling sampled all 1 million (or whatever's visible) trianlges and drew them, it'd look like the normal mapped version, but only the pixel-sized triangles are being drawn ignoring all the variance at the sub pixel level. It could also be an issue with the Quixel scan lacking depth accuracy in the vertices that the normal map captures. In principle, sufficient res geometry won't been normal maps, but of course for games that's not going to be true as they are a far more efficient way to embody that data.

 

This is exactly the type of things Cerny wants to avoid in the future.

 

i didn’t watch the whole thing because a lot of it was not Lumen or Nanite related. But I did watch the more relevant parts, especially at 53:00 mark.

 

Virtualised geometry does that without the need for streaming those assets in full. Virtualised geometry is the same as virtualised textures in intent. It allows you to have a unique objects (texture) per pixel but only storing the sub-mesh/texture that the pixel-data is part of.

 

The engineers in that live cast implied that they avoided high speed SSD partly through careful disk layout. I have no idea what they meant specifically there.

 

Since you mentioned Tutomos, he also said this :

https://www.resetera.com/threads/ti...-awesome-on-both.206223/page-10#post-34178337

So, XSX would run maybe this demo at higher res, but Nanite textures and Lumen lighting tech would be scaled down somehow?

 

Sequential read and maybe duplication of data, back to square one for slow SSD.

 

Like with Spiderman where a bin is duplicated in 200 places in the disk to access it as soon as possible, with SSD I supposse you can make something similar to reduce latency accessing the required data through the flash controller. Thats why the 12 channels Sony's custom flash controller come in handy.

 

And what about the textures?
The statue was also textured with color and variable roughness. Have they applied UVs on those super high models? Or did it just read the color info as a polypaint?
The environment looked highly detailed. The shadows are probably popping out the geometric detail. The quixel example you show above lacks shadows and probably thats why the detail is not as visible. The normal is also a bit over applied hence why the top part of the rock doesnt look very natural (a problem I get often trying to pop some details out with my renders when I have no height maps).

 

Reddit post: Pixels? Triangles? What’s the difference? — How (I think) Nanite renderes a demo with 10¹¹ tris

Spoiler: Reddit Post Inline

I think this explanataiton is the good one for UV. It is long but read everything.

 

a very interesting read. thank you, it is worth the time

 

Just looking to screen grabs from the tech demo, details are ok, but what's about razor edged shadows?
this is a limit of the UE5 itself?

 

On an early devkits too...

 

That makes no sense to me. SSD's access data directly, so position within the NAND won't affect seek time. With HDDs, or spinning disks, you have to move the head to the data with a significant influence on latency, so physically having the data closer by reduces seek times.

There should be zero reason to duplicate data on SSDs, unless I don't understand some underlying intricacies.