-
Ever wanted an RSS feed of all your favorite gaming news sites? Go check out our new Gaming Headlines feed! Read more about it here.
-
We have made minor adjustments to how the search bar works on ResetEra. You can read about the changes here.
Unreal Engine 5 - Dev Workflow Stream Today 5/26
- Thread starter Rolento
- Start date
How long does the world-switching take on a SSD vs HDD on a production build?
Yep, 1440p.
Will try in a moment.
Guesstimate between 2060 Super and 2070 (XSX closer to the latter).
Wow this is just beauty
Unreal Engine 5, [UE5 Developer Availability 2022-04-05]
The specular reflections are pretty rough as I am seeing right now, but pretty interesting! SDF reflections are the most expensive on smooth surfaces since engine has to cast more cones/rays on mirror surfaces, this is actually opposite to HW RT reflections where the rought reflections are the...forum.beyond3d.com
Runs at native 4k 40 fps on 3080 by ·cukos on B3D
Same thing really or in the same ballpark( without DLSS )
Okay i give up... i forgot that you need to install all SDK's and Visual Studio and all of that to build the project... and i can't do that on my living room rig while controlling everything with a gamepad, cancelled download.
I hope some kind soul without datacaps and other unfortunate bullshit will upload production build somewhere or posts a link if it's already available 😭
This was one of the more interesting quotes from the video:
Sounds like it may be a good alternative to DLSS for AMD in the short term. In, as DF calls it, "Post resolution" era, this feels like a massive boon for distributing processing power elsewhere other than pushing raw pixels. Questions then are:
Sounds like it may be a good alternative to DLSS for AMD in the short term. In, as DF calls it, "Post resolution" era, this feels like a massive boon for distributing processing power elsewhere other than pushing raw pixels. Questions then are:
- Does this work with dynamic resolution scaling?
- Was the demo we were privy to today ran at 1080p?
Excuse me? People on ResetEra told me that the original demo was only possible because of PS5's SSD. Why would someone lie on the internet?
A. It's a UE5 engine feature which will work on any GPU supporting SM5.
B. It won't be out in the "short term" since the UE5 preview is late 2021 and first projects using the engine are unlikely before 2023.
A. What is SM5?
B. Don't hurt me like that :'( . And by short term, I meant an alternative to DLSS for AMD chips before another more efficient or as efficient process competes with it for similar result down the line.
Shader Model 5.0, roughly equal to DX11 GPUs i.e. GF400/500 and RHD 5000/6000 (note the "HD" instead of "RX").
There are already multiple temporal upscaling techniques out there.
Not sure how efficient they are compared to Epics, or DLSS for that matter.. I don't know of any good comparisons, I don't think there are games w/ DLSS that also have other TAAU options.
The big thing about one being built into UE5 would be it would be available for all; whether it compares well against the exact same game using DLSS might be harder to determine.
It can't be stressed enough moving to mesh shaders is allowing for things we use to make fun of when they were being claimed. I don't think anyone saw this as as solution to drawcalls until basically the last year or two.
Youtube is full of videos that get in to, try to find something light it's pretty damn amazing what this or ray tracing can do when wielded in inventive manners.
Gotcha, thank you.
Thank you.
The only upscaling techniques or rather reconstruction methods I am aware of are Checkerboarding in HZD (among many others) and Temporal Injection (most notably by Insomniac in Spider-man).
The Editor loads data into (a shitload of) RAM, not really comparable to a live game situation on a limited RAM pool. There is a reason the editor requires 64 Gigabytes of RAM on PC.
Temporal injection is a similar technique under a different name. UE5's TSR will likely produce very similar results.
lots of devs are turning to make their own TAAU it seems. 4A built their own with Metro Exodus, for example
trying out Lumen, it seems that it's only screen space, which is pretty weak for enclosed environments it seems. also it builds up very slowly on my pc for whatever reason. I have it set to hardware RT since I have a 3060Ti.
Aha! Merci beacoup.
It will be interesting to see how result pans out once the next gen ver. of Exodus are available in retail.
Exactly by iroboto on B3D
Unreal Engine 5, [UE5 Developer Availability 2022-04-05]
pretty harsh performance on a 1070 -- building the project now. lol almost threw up on drone mode, controls exactly like IRL drone, was thinking it was going to respond like a standard ghost camera in a game
forum.beyond3d.com
No Lumen is not fully screen space it use signal distance field raytracing it raytrace on a simplified representation of the scene and screen space raytracing.
I think there are going to be some tough decisions to be made. UE2/3 drove many developers to create their own engines, as the royalty cut Epic was asking at the time was massive and enough to make an otherwise profitable project become unprofitable. For companies at scale like EA, Ubisoft, etc, it made sense to build their own engines. But now, the amount of investment that Epic is able to put into UE due to the success of Fortnite... I have a feeling for companies like EA and UBI to keep up will require a significant investment.
Not only that, but the UE community is just bigger, and hiring for UE talent is going to be easier than hiring for your own custom engine.
This is all just pure speculation on my end, but I've always thought that after UE reduced the royalty fee, over time the bigger third party devs would start to step away from building their own engines. A generational leap like we see with UE5 will accelerate it.
Well... I do wonder if the windows filecache is having an effect here. If there's enough RAM available and the files had been loaded due to a previous run, or editor run, or from a write-cache during installation, you might not be seeing what really happens when data has to come in off the hard drive.
I was seeing the same behaviour on low IO drives, but, when I reduced system RAM to <8GB free (should be no problem if the footprint is 3-4GB), and again used my lowest speed drive (125MB/s), this was the result after a bit of traversal:
With it taking double digit seconds to resolve to normal detail. The same drive was fine with more RAM free, even though the application itself wasn't using more than 3-4GB, so I can only assume the windows file cache was saving the day previously.
(125MB/s might be very low - if someone wants me to test another super-low-IO/RAM situation but with something better, let me know!)
Last edited:
Well... I do wonder if the windows filecache is having an effect here. If there's enough RAM available and the files had been loaded due to a previous run, or editor run, or from a write-cache during installation, you might not be seeing what really happens when data has to come in off the hard drive.
I was seeing the same behaviour on low IO drives, but, when I reduced system RAM to <8GB free (should be no problem if the footprint is 3-4GB), and again used my lowest speed drive (125MB/s), this was the result after a bit of traversal:
With it taking double digit seconds to resolve to normal detail. The same drive was fine with more RAM free, even though the application itself wasn't using more than 3-4GB (there was >20% RAM free), so I can only assume the windows file cache was saving the day previously.
(125MB/s might be very low - if someone wants me to test another super-low-IO/RAM situation but with something better, let me know!)
Ah ok, so magic SSD still required. Got it.
Lumen uses screen space but is not limited to it. Note that your mesh needs to be broken down to simple pieces to work well with Lumen
That is not the editor, it is a production build I compiled myself. It only uses 3~4GB RAM.
I made a video.
I would hope so.
It seems like devs who have to use in-house engines are doomed to less efficient workflows, unless the in-house engines have the ability to adapt like UE4/UE5.
Nah, they're around RTX2080 level if you take optimization into account.
the main difference that comes to mind for me, is that developers that maintain their own engines can focus specifically on the needs of the project, rather than the catch-all generalist approach UE itself maintains, but the question still remains yeah - will it be fast enough AND as good? Chances are...most of the time, no. But it's a hell of a lot cheaper than licensing UE for a bigger title, I'd imagine.
They can't be both around the same card though, given the gap between the consoles.
You can't really make a generalized statement about this anyway. It differs from engine to engine. Some engines and workloads just run better on Nvidia and others run better on AMD. If you use raytracing AMD falls behind for example with the more raytracing the worse they compare against Nvidia. That's why you have games where the 2060 can keep up with the XSX where in others you need a 2080, usually pure raster games.
A 9 Teraflop RDNA1 card the 5700xt beats out an RTX 2070.
Therefore a 10TF RDNA2 PS5 and especially a 12TF RDNA2 Xbox series X would blow a 2070 out of the water.
They're more around an RTX 2080 Super level or more in rasterization.
So after going through the published documentation here's a quick summary on Lumen and RT usage, feel free to correct me if something's wrong:
It is apparent that they've started bolting RT h/w usage to Lumen already but it seem like early days I'd say. And it makes you wonder if at some point we'll see a UE 5.5 where they'll drop DX11 h/w support altogether and what that would mean for all the s/w based conetracing into SDFs and such approaches.
- Lumen does GI and reflections.
- Base quality level is fully shader based and will run on all DX11 capable GPUs.
- GI is done via conetracing into the SDF representation of the scene. Results are cached (in "cards") and accumulated temporally. Seem to be working in near field only with far field falling back to SSGI?
- Can't be accelerated with DXR 1.1 h/w as of now.
- Reflections are done via conetracing (into the SDF representation of the scene?) with significant help from SSR.
- Can't be accelerated with DXR 1.1 h/w as of now.
- GI is done via conetracing into the SDF representation of the scene. Results are cached (in "cards") and accumulated temporally. Seem to be working in near field only with far field falling back to SSGI?
- Advanced quality level taps into RT h/w and thus requires DX12U GPUs.
- RT GI is done by triangle RT in this case, with Nanite meshes being traced against their "proxies" which are simplified meshes (potentially can be 100% of original quality though?). Far field GI is falling back to SSGI too?
- RT reflections aren't implemented in Lumen yet but there's the old option of using RT reflections from UE4 for now. Will likely be added to Lumen in a similar fashion as h/w RT GI later. Will likely use SSR too to help with tracing against Nanite meshes and alpha transparencies (among other things).
- In fact I think that Lumen reflections will basically start requiring RT h/w at some point since it's very likely impossible to produce "ideal" reflections (glass, mirrors, calm water, etc.) with conetracing.
- Base quality level is fully shader based and will run on all DX11 capable GPUs.
- Shadows are done via REALLY LARGE shadow maps (16Kx16K) which are being loaded as needed in 128x128 chunks - which is why they call them Virtual Shadow Maps.
- Such shadow map size takes care of smaller and removed from shadow caster details which shadow maps usually miss. (Not sure that I like this approach as it seems a bit brute force and chosen for compatibility reasons mostly.)
- They use shader based RT to filter VSM penumbras by shooting rays to measure the distance from the light source to the shadow map region.
- Can't be accelerated with DXR 1.1 h/w as of now?
It is apparent that they've started bolting RT h/w usage to Lumen already but it seem like early days I'd say. And it makes you wonder if at some point we'll see a UE 5.5 where they'll drop DX11 h/w support altogether and what that would mean for all the s/w based conetracing into SDFs and such approaches.
Last edited:
OP
OP
Epic Developer Community
The Epic Developer Community offers announcements, tutorials, showcase projects, forums and learning materials. Read about the latest developments.
learn.unrealengine.com
I'm just using built-in primitives and lights to fill out a space rather than imported meshesLumen uses screen space but is not limited to it. Note that your mesh needs to be broken down to simple pieces to work well with Lumen
Well, after several hours with UE5 on 5700xt I can say that Lumen is great. Once the distance fields are generated correctly for the meshes everything works wonderfully. GI is good, precise, with manageable levels on noise. Very-very impressed overall. Overall it's an interesting combination of screen-space effects and scene proxies that it uses. Basically it actually uses 2 scene proxies: the mesh distance fields and a so-called "lumen scene".
Last edited:
Thx seems to be full of good courses!Epic Developer Community
The Epic Developer Community offers announcements, tutorials, showcase projects, forums and learning materials. Read about the latest developments.
