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

If the goal is to increase your VRAM capacity without needing to add more VRAM, improving your I/O is one method. The other method is to have less overhead of what you need to store in memory.
Just because things are stored in memory, doesn't mean it gets used. That's the challenge of real time gaming vs a tech demo. A tech demo, everything gets used. A game, a lot of times you're loading stuff a lot of stuff you may not need. If you can reduce the amount of information to exact to just what you need, you can have significantly more savings on capacity.

I/O speed is great too, but if you're doing things the old way and loading in 67Mb texture (8K) and only use 1Mb of it on screen, and the competing system is just loading the 1MB of that 67MB texture, the amount of I/O won't make up the difference in both capacity or in how much you can send over the line. You wasted bandwidth and capacity in doing it in this way.

If you want more capacity the best way is to reduce the overhead in memory. If you can succeed in wins there, I/O speed is the next best thing afterward.

Looking at game like spiderman I suspect efficiency is exactly what current gen has been focusing on. The gdc talks about spiderman are fascinating. They include details about streaming, world building, packaging data etc. It's also probably why sony has chosen to use spiderman as an example when they talk about ps5 streaming.
 
Last edited:
They are adjusting the lod to decimate subpixel triangle doing probably software quad merging.
What do you mean with quad merging? Being restricted to quads means no realtime, usually.

My simplest assumption is this:
They build something like an octree over the high poly meshes (picking octree because of this SVO rumor). Fast enough to claim 'import and display instantly', but not realtime.
They put triangles in the leaf nodes.
They place pixel splats into the internal nodes, which area weighted center and color of texture average. Still fast enough for the claim, even with devil in the details like turning normal variance into roughness.
Store that crap on disk, ready to stream and display at runtime.

At runtime, they use distance to model to see which tree levels are necessary and stream them. Triangles and texture remains untouched at some distance.
Then they traverse the tree and splat nodes that match pixel size, and triangles if close enough. (Just a guess: Traversal state can be cached so need to traverse always only one level either up or down, because distance changes gradually.)

If so, totally simple and easy. Nothing complicated. It is not really the efficientest LOD solution i can think of, but obviously it works.
Do i miss something? (EDIT: I mean, why 'subpixel triangles'? Makes no sense?)
 
Last edited:
from what I've understood fast streaming are used to load/drop/reload/redrop assets, sometimes (or often) the same assets to and from a 10-12 GB gpu-pool, with 6-4 GB CPU-pool that can't be used as "cache" for gpu loading, so they have to rely on fast nvme or velocity tech, but an high end pc have 64-128 GB of main memory to store geometry assets, so I believe that they will take different solution, than the one used for consoles.
Of course the pc solution will be scaled down for pc with 32-16 GB RAM + 6-8-11 GB GRAM, but why Epic schould use the same console approach when PC have not the ram-bottleneck of the console?

I think the answer to this would be found by looking at PC games and dissecting how many of them already use some kind of streaming. if they use some kind of streaming surely they could benefit from orders of magnitude faster streaming? Just imagine what grand theft auto, witcher 3 or many other titles could do given ability to pull a lot more assets on demand.
 
I guess they rely on hidden surface removal a lot.
Reproject previous frame of static / slow geometry, erode Z to avoid false positives, make Z pyramid, cull the trees against that.
Should get rid of most stuff and help with streaming too.
 
I/O speed is great too, but if you're doing things the old way and loading in 67Mb texture (8K) and only use 1Mb of it on screen, and the competing system is just loading the 1MB of that 67MB texture, the amount of I/O won't make up the difference in both capacity or in how much you can send over the line. You wasted bandwidth and capacity in doing it in this way.
Yep. And quite possibly, virtualised geometry could decrease the need for fast streaming. It all depends on how much data needs to be streamed. We're facing a future where maybe Sony picked a solution to current-technology, but moving forwards, engines will move to a different tech. So similarly to 360 being designed to be fast at forward rendering, and then come a cropper with deferred rendering, we might see PS5 better at games that chug through assets conventionally to begin with but then find its speed advantage lost when games don't need anything like as much data because they are super-efficient at reading it.

That's one plausible scenario among quite a few.
 
Oh and something else.....we have different texturing tools but as far as I know, none can handle millions of polygons efficiently to texture.
Sure you can polypaint on Zbrush, but other software like Substance that have dedicated texturing tools?
And what happens with the UVs? We usually have a low poly version to unwrap the UVs so we can add textures. But with a 30million polygon model from Zbrush, how do you effectively unrwap the UVs so that they dont get warped and how do you create the textures for the model?
 
I hope on the PC side of things we are able to use main ram as a buffer. Ram is pretty cheap , I have 32 gigs of main system ram. If an UE5 engine game would use my nvme drive plus 16 gigs of DDR4 that could enable some pretty amazing things I would think.

Bottleneck will likely be the PCIe 3/4 bus, with traffic between NVMe SSD to RAM, and RAM to VRAM. There's always the option of scaling down.
 
There's Radeon SSG. Starting to get expensive methinks. :p On the other hand, 2TB could probably go a long way if people install things appropriately i.e. console ports taking advantage of SSD installed locally vs older games installed elsewhere.
 

Finally a semi-official source.

It’s not just “Fast SSD”. It’s a robust platform for streaming assets in near realtime.

In Cerny’s presentation, he mentioned clearly that the platform can take regular (2 priority level), higher speed SSD in addition to Sony’s 6 priority ones. The system has additional arbitration logic for these off-the-shelf 2-priority SSDs. Because these units can’t prioritize requests in finer granularity, they need to be even higher speed than Sony’s SSD to make up for the difference. Over time, these off-the-shelf SSDs should drop in price.

The end goal is developers can rely on its consistent performance to experiment and rev things relatively quickly. And be assured that there are enough systems out there to run their final products.

EDIT: Like Epic, they can also use the feature to implement nextgen ideas for their games.
 
Last edited:
There's Radeon SSG. Starting to get expensive methinks. :p On the other hand, 2TB could probably go a long way if people install things appropriately i.e. console ports taking advantage of SSD installed locally vs older games installed elsewhere.

Just treat it as a large cache right ? install the game to a regular ssd or nvme drive and have it load into the 1TB or 2TB drive or whatever size that's connected to the video card as your playing
 
Back
Top