Nanite seems like the big talking point for me! I thought for a while now that 3D scanned data is going to catch on within games. When Epic announced that they teamed up with Quixel I had a feeling they had something in the pipeline. Will be interesting to see how the other game engines respond.
stupid question (as someone who can't code but interested in learning unreal) do you think the new features and advancements of unreal engine five will also make smaller projects like mobile games easier to make compared to the current unreal engine 4?
Hardware/API wise, the tech available to the consoles is basically the same as nvidia's RTX cards can currently do, feature wise. The only massive technological advantage the consoles have over PC is the incredibly integrated, high speed storage they have, and an OS set to make use of it.
In many ways it's similar to the blazing fast NVME drives pcs can have, but with low level access and again, an OS designed to make the most of it.
u/NooblyGod Honestly it seems like UE5 is in some ways going to just be a large update compared to the normal UE4 ones, they've promised forwards compatability.
As for Lumen and/or Nanite, both very likely rely on API features inherent in DX12 Ultimate, aka mesh shaders for Nanite. Though Lumen I'm less sure about, wouldn't be surprised if it benefits from some kind of RT acceleration in the background.
u/graphicBOMB A huge part of the reason they can push that many triangles is because of Mesh Shading, which is a new DX12 Ultimate feature that the new Ati/AMD gpus in the consoles can do. The nvidia RTX 20XX series is also capable of this. In a huge part it means that a lot of the cpu-bottlenecked aspects of rendering (ie drawcalls.) can be handled entirely on-gpu. Massively speeding everything up.
No threadripper required (remember, the XBSX and PS5 are running Ryzens, not threadrippers.)
When you go to a McDonalds, instead of having 1 super fast, trained cashier dealing with a bunch of customers, you can hire 4 mediocre cashiers and split the customers into 4 lanes.
in the first case, if your super fast, trained cashier has a Karen who demands having more chickie nugs while on the phone taking others for her family, she holds up the line for everyone else behind her. it doesn't matter how good your cashier is - Karen is a bitch and she will hold everyone back until she completes her order.
in the second case, where you have 4 cashiers, even through they're medicore alone, as a team they will process all the customers faster. if one of your cashiers by chance encounters a Karen, it doesn't stop your other cashiers from processing orders.
now think about how this in terms of a McDonalds restaurant - instead of having a mega McDonalds restaurant serving the entirety of New York where you might have a Karen blocking the entrance because she won't respect quarantine rules and wants to get her orders first, which can cause McDonalds to lose a lot of moneym, you have a bunch of smaller McDonalds spread all over New York, so McDonalds continues to process orders all over the city, without the worries of traffic or karens blocking the door.
that actually makes a lot of sense. if they really managed to get a good multithreaded engine it would justify the amounts of insane polygons, compared to other offline or realtime render engines which are still single threaded.
there one key area which unity worked on and that was multithreading allowing them to squeeze more performance out of hardware and since all processors now are multicore a good written multithreaded application is more performant altho unreal 5 turned out to be very very exceptional if we devs have ability to write multithreaded code using blueprints and is simplified then there's no reason to go to another engine