This video is more of an explanation/breakdown of the nanite workflow and process. The detailed tutorial will be coming shortly! Want to see more? Join our game's Discord to see behind the scenes streams and the latest updates, as well as get help developing your game! Join the Discord: discord.gg/2JtBP49RzS
What about the memory, storage space cause high res meshes are memory intensive & shader complexity performance high res meshes with complex shaders are demanding for GPUs tell us about your computer specs because majority of average gamers play on mid-range hardware?
@@Mr.Sunshine2023 Meshes shaders are just advance tessellation with procedural geometry generation GPU driven frustrum & culling. So it still doesn't explain the cons of extreme high res meshes the memory usage & complex shaders.
Are there good nanite foliage packs on the store? And why megascans don't do it (not a critique, just wondering why epic don't do it which makes me crazy)
Hey, technical artist here. Do keep in mind that nanite simplifies geometry based on connected meshes, it's what Epic calls "aggregate meshes". The reason this is important is because if you have continuous surfaces nanite will keep reducing the mesh properly at large distances, but if you have a lot separate submeshes nanite will try to keep the mesh boundary which means it will have a harder time reducing the geometry. This is specially important for foliage, a pine tree will underperform compare to a any tree with big leafs, simply because each need can't be reduced further properly
I was thinking about this, this is a case where you would still want to use LODs, but only two - the second one being a 'more blobby' thing that is continuous but still looks good, right? Because from far away, you very quickly lose the ability to see those needles anyway no? Something something, can't see the forest for the trees, can't see the tree for the leaves...
Excellent point! Yeah i had an artist on my discord showing me a pine tree he was trying to make, and I had to show him an alternate way cause you dont want each needle to be moddled. Like in those ones its really just two planes intersecting where the mesh of the planes conform to the shape to mitigate that specific issue you mentioned. Glad this comment got lots of thumbs up!
@@tempchannel17 Don't use LODs, just use Nanite with masked material, which is still a better option than LODs if you already enabled Nanite for everything else. Mixing Nanite and LOD is far worse.
@DallasDrap I can actually provide more data if you are interested, there are more cases where topology plays a role with how well nanite performs, vertex data like UVs, normals, vertex color and so on can create discontinuities in the mesh that will also affect these boundaries, one good way to test is to create two rows of your objects side by side in a length of at least 100m so that you see your mesh at a small size, in one row you can have your unoptimize mesh and in the other you try to create continuous surfaces as best as possible, you will see that even if the target polycount is the same and the end polycount is also the same the rate at which they go to the higher polycount to the lower one is not the same you can all use the max edge global CVar to preview it, by I find it harder to see the "gradient of change" also, keep in mind one of the biggest features of nanite is the fact that cluster can cull each other, so having very small details of geometry like the pin needles doesn't allow them to cull what's being them, which mean you end up with a lot of overdraw, we can actually see this in your video where the darkest parts in the overdraw preview were in the tree logs, because they were big enough to cover clusters being them, so the smaller you go the worst it will perform finally, one point that I find super disingenuous from TI videos is the whole talk about what they call "quad overdraw", while their explanation was fine this whole comparison with nanite is ridiculous considering that nanite uses a software rasterizer that doesn't have "quad overdraw" issues, so the whole point of optimizing meshes for hardware accelerated rasterization makes no sense for nanite, yes, this also means their rasterizer is slower but slower doesn't necessarily means slow, it means what you showed in the graph where the initial overhead for nanite is higher but after a certain point it scales better and don't get me wrong either, nanite is not perfect, don't get me started with shadows and raytracing, nanite has issues, just not the ones that people are pointing out because it doesn't follow traditional conventions
The trouble is that epics began to tell how to work with nanites only in 2024 (!) 4 years after the release of ue5. Seriously - the lecture "nanites for artists" came out in the spring of 2024! Many people don't even know about the existence of these materials!
exactly! haha just another point for my last video, how like, the reasons current UE5 games "suck" or might not be what people wanted or hoped is because we're all like just now figuring this out properly haha
@@DallasDrap Epic's unreal fest 2024 video they just released points to some massive improvements down the line. It sounds like they're working on a fix for the traversal stutters and pretty much every single issue UE5 has rn.
While a very interesting study and rebuttal to the growing Unreal Engine criticism, in my experience lumen has the bigger impact on performance than nanite does. So you only addressed half of the conversation here. Also while your study is interesting, it's hard for me to understand how it would affect my project which does not have foliage at all. I'd like to see more cases. I also want to know what settings you had on and what hardware you use. Did you have any AI upscaling like DLSS active? What model GPU are you running these tests on? What anti aliasing method are you using? How many levels of LOD did you have for the masked material foliage? Etc. Now it may be true that basically every professional developer except for yourself just doesn't know at all how to use the engine. You have a huge opportunity and perhaps a responsibility to create as many UE5 tutorials to finally show devs how to optimize in the engine. But when you show your own game struggling to hit 60 FPS and you brush that off as vague optimization issues in other places, you aren't really putting out the most convincing takedown of the Unreal Engine is unoptimized claim. I'll be convinced that the engine isn't the problem when I play a single Unreal Engine 5 game that runs smoothly. Which at minimum is native 1080p 60fps with no dips.
ah good point! My bad. When I was doing the video I was kinda just flowing with it but you're right! I can maybe post it as a short or something here soon
In theory should have low to none overdraw, because all the foliage is opaque, the overdraw would be caused by UE5 occlusion system not being 100% accurate (tbh no engine have perfect occlusion culling)
@@Bino-hy5bl It's actually a lot of overdraw because nanite doesn't use the standard Occlusion culling system, has it's own one. With pine trees there's massive gaps where geometry isn't occluded and thus needs to be rendered resulting in massive overdraw. As the system stands you'll never be able to draw a pine forest like this without hefty performance cost or ugly artifacting. Broad leaf trees and dense ones fair better as they can occlude other nanite trees geometry better but still not ideal. Far off foliage should still be transitioned to foliage/impostor.
Id say the main performance impact simply comes from the fact that nanite and VSMs require you to use SM6 which itself runs slower than SM5. So like you said, nanite itself isn't necessarily the culprit. Its a mix of how people utilize it as well as the fact that SM6 must be used.
this is exactly why I really like the comment section of these videos, it allows for more in depth comments and discussions, but this is correct! and thank you for pointing that out.
@@DallasDrap I don't know if you're already planning this, but a video covering VSMs should also clarify things further. From what I know there is a way to alter the VSM quality so that it's not super high resolution and you're able to use what you need. But I believe most if not all ways to alter VSM quality are console commands only.
@@thana3270 Yes, it's r.Shadow.Virtual.ResolutionLodBiasDirectional which is in Scalability.ini For Ultra I use -1.3 and for Low -0.3. That's another big boost but also the quality drops. There are other variables for VSM but that's the main one. In my experience the biggest performance hitters are, in order: Collisions VSM Lumen Tick rate Masked Nanite Textures bigger than needed and non-Virtual
This is a fantastic start to what I believe could be a great series of videos and tutorials that brings the discussion (or argument) in a positive direction aimed at educating developers rather than... whatever the latter is. Keep up the great work!
Glad it helped! Im working on a tutorial which includes building nanite foliage as well as tips and tricks for keeping it further optimized. That is coming next! Trying to get it done between tomorrow and monday
Just to add to this, Nanite is designed to render approximately 1 triangle per pixel. That means if you're rendering at 1080p, you're targeting 2 million triangles, and for 4K, you're increasing your triangle count to 8 million. Now, the issue with overdraw, and why @DallasDrap mentioned that Nanite doesn't like it, is because if you're overdrawing, you're effectively rendering more triangles than you need to (i.e. more triangles than your pixel count, and triangles getting rendered over other triangles, which you won't see anyway). It's just something to need to look at if you're using Nanite.
Did you just admit that the thing that was supposed to "kill polygon count" needs to have rough polygon count to function well? I cant be the only one who thinks that this doesnt sound right, can I?
@@Dizintegrator No, I didn't say anything about rough polygon counts, or anything related to how you should structure your polygons. All I said was why you need to keep an eye on overdraw.
@@RazielAU sorry, I must have misunderstood the part where you clearly stated: "... Nanite is designed to render approximately 1 triangle per pixel. That means if you're rendering at 1080p, you're targeting 2 million triangles"
@@Dizintegrator In a nutshell, Nanite takes very high poly meshes, breaks them down into pieces, creates many LODs of each piece and then further breaks it down into more pieces. It all ends up as a graph structure which is far more complicated than I want to get into here. At any viewpoint, the engine can pick a set of these LODs that will roughly map 1 triangle to each pixel. But it does expect that you're going to use Nanite the way it's intended. As a simple analogy, if you have a line-art drawing which needs to be saved with good clarity, you should use PNG, while JPEG will work, it's not intended for that type of content. JPEG aims to store photos with a certain loss in detail to drastically reduce image size, whereas PNG is designed to compress simpler art like line drawings, but again, it can support full photos, it just won't be able to compress it as well. Nanite is exactly the same, if you're going to use it, you need to use it with the content it was designed for, which is dense meshes with a lot of detail. This is for the most part unrelated to what I was saying earlier, which basically boils down to: Epic provides tools to check for overdraw, you should use them to see if you have a problem you may not be aware of.
Also, there was no need to say "the part where you clearly stated", you are being extremely rude. If you actually go back and read what I wrote, what I "clearly stated" was that "Nanite is designed to render approximately 1 triangle per pixel", in other words, the engine/Nanite handles that, which should be super obvious. I never said or implied that you have to reduce your model's triangle count, since again, the engine obviously handles that. But of course, you're going to conveniently quote only a small part of my comment and take that little bit that you've quoted out of context to be rude and start an argument.
One big caveat of the fully modeled Nanite foliage is memory. Even with Nanite compression, fully modeled foliage can and will take up a lot more memory because you're looking at multiple orders of magnitude more vertices and triangles.
can you compare the fps of the masked foliage with nanite turned off to the nanite foliage with nanite on, seems like it'd be a lot more fair of a comparison
can you compare the fps of the masked foliage with nanite turned off see "Threat Interactive Drama Explained - Smart Poly" Jan 15, 2025 it's all about scaling and when it makes most sense to use it. it's like DLSS, 1080p vs 4k. you see the most benefit on 4, when it stretches the fps for the hz on your monitor.
Biggest issue with Nanite, Lumen and other fancy stuff is just the bad gaming experience. PCs have huge variety of different machines and in my opinion, every action PC game should run 720p@60fps on Steam deck without any stuttering and should look good. It will require 9x more powerful GPU to make same running on 4k and that is then about highend machine. We have not seen any Unreal Engine 5 title with Nanite that can handle that. Correct me if i'm wrong.
Thank you brother, I've watched a handful of course and tutorials but barely any them covers the Topic of Optimization, Most of them just focuses on how to make things look good without considering what it cost them Looking forward for you future content man
I wish I could find official UE tutorials certified by Epic. That way, I know I am learning the truth and best practices, instead of random TH-camrs that I have trouble knowing who to trust.
One of the best videos on how to utilize Nanite foliage I have seen. Great job! One thing that always irks me with Unreal Engine videos on TH-cam is when I see the old Unreal Engine logo being used. ;)
I thought Nanite would cause higher VRAM usage, and it definitely seems to be a challenge for players with lower-end GPUs. With the majority of players still on 8GB (35%) or even 6GB (12%), it's becoming a big issue. Nanite's detailed geometry and virtualized assets push VRAM demands higher, which can lead to performance issues, especially for users on older or mid-range GPUs. Right now, only 25% of players have more than 8GB, so it’s a tricky situation for a lot of gamers. Hopefully, future optimizations can help balance this out!
That's definitely not true. What causes higher Vram usage are 8-4k textures that come with Nanite models if you download them from MegaScans. Nanite models are actually lighter on memory (better compression) and they constantly stream in and out meshes or even parts of the meshes that aren't needed (with culling).
Same! And there are workflows to consolidate GPU usage further, but thats one of the reasons why in the video i mention how this workflow isnt for everyone or every project. But this is an important note! One thing i love about the comments is seeing all the details you all remind me i left out, and i mean that sincerely! It helps me to remember and add talking points to future videos
The joke of nanites is that there shouldn't be that many of them on stage for everything to work well. About 100? 200? No more. Nanints work well when there are 10-20 objects that are duplicated 10,000 times. Not when there are 10,000 unique objects on the scene. We need to beat the hands of the level designers for wanting to use all 100% of the assets made in one scene.
@@YarGolubev exactly haha thats another note i was gonna be making in a future video, but yeah, the best way to use it is focus on less objects that have a lot of customization as opposed to a bunch of uniques. Maybe thatll change one day, but not today
Reuse assets. add complex shaders. to mask identical cassettes. Add macrovariation and microdetalization. Transform and scale. (By the way, the question is, do epics want to add the possibility of warp morph for nanite assets? It would make life easier.) Epic Games think that the best way to use their engine is to create PCG. But unfortunately, PCG is not fun yet. For casual users geometric nodes need to be simplified. It is necessary to make macros from nodes - that it would be enough for the user to connect 2-3 nanite assets and add some nunbers of rules for connecting them.
Great video. I was really confused with the use cases of Nanite and thanks for clarifying. I would love a tutorial/explanation for how you would optimize these kinds of meshes for games, specifically the techniques you used in your past and current projects.
Ngl I was at first weirded out by the stache and quirky behaviour in the beginning, but once you locked in and started pouring quality info I got convinced that you might just know what you're talking about. Looking forward to the future videos explaining how to work with nanite. Subscribed.
Thank you. people like you who do these kind of videos save so many projects from being abandoned. I thought its not worth it to work in unreal engine with all its unoptimized core features. But you really helped get past that misconception and show UE5 features in a new light. I think the community would greatly appreciate a series on high level optimization that most people using the engine done know about.
I feel like we are also largely living in a time where people are conditioned to approach things from a negative and critical angle. At minimum I would say that youtube ends up pushing more of those negative titles into the algorithm which seems to have people inventing things to be upset about for content. It could just be because people are more likely to engage with negativity but I would really like to see some course correction on this one because its exhausting.
I would too, and if im being honest, I kinda hate making more of the "clickbait" type thumbnails like this one, however, its what youtube wants right now if you wanna get your videos out :[ Also yeah, there is a lot of negativity out there, im hoping though this video can be somewhat of a bait n switch for those looking for unreal engine hate haha
@@DallasDrap I don't think that anyone really 'hate' unreal. the issue is the users and the non-skilled developers that use it. the same issue that unity had in the past. it lowered the bar of entry for new developers and a lot of shity and ugly games made because of these. and its was never unity to blame. the same issue is now with unreal.
@@rossb5788 I see a lot of hate, but it's usually from gamers that experience badly optimized games or devs that rather blame the engine than their lack of knowledge on this subject. I mean, you can spot them in the other recent Dallas' videos.
This right here made me want to test it myself. Questions: What's the screen resolution? What are your PC specs? Great video, looking forward to one on Lumen.
Screen percentage was 68 for both, basically the default under high settings and im using a 4080. Thats why i did demonstrations for both as ive gotten the "no wonder you have high frame rates" comments, however the bigger point moreso is the difference in performance between the two. I should also probably lay out my specs in the description or mention them in my next video
@@DallasDrap It would help if you tell us the render resolution to get an idea of how the framerates you're showing correlate to similar real-world games in use today. While I agree in this video it's not critical as long as you keep the resolution the same and vary the parameters to show the framerate differences, the degree to which those framerates change with differing things like Nanite vs no-Nanite will be affected by the render resolution as you can start to introduce confounding effects like CPU or GPU bottlenecking which can artificially cap framerates at either end.
I'm on 2080ti as a developer, and I never was able to get decent framerate using nanite (1440p). Now I have a case study I can follow but still, I'm quite sceptic. Going to DX12 from DX11 results in ~20% FPS drop. And I do not believe DLSS bandage really fixes that. I don't like the idea. I do understand, that nanite and Lumen are meant for "next gen', but if next gen needs to rely on DLSS and Frame Gen I believe something is wrong. Still, great video, looking forward for more, gonna check it all out muself. Thanks.
Thanks for such a great video, you really opened my eyes to some details I missed on the whole UE5 discussion. Keep up the great explanations I Look forward to seeing more!
Thanks for making this video. My biggest issue with current UE5 games is either smearing on movement or ... this snowflake-like effect (especially on foliage), the perfect example is at 13:18 (focus on foliage) but imagine seeing it in the actual game. Is there anything I can watch/read to understand more how to fix this? Also, did I understand nanite right? -- In the past, people used low-polly models and always drew everything (as long as it can be on screen and distance settings allow) with a big focus on opaque/masked textures. Nanite is focused more on directly drawing what you SHOULD see on screen. Lets say there is an object behind a tree. Nanite would be focused on drawing individual "pixels" of an object, while previous impl. would draw a whole object on your screen even if it's not fully visible.
What a fantastic wrap up. I am at the point of re-creating my environmentals. I did a study where I made (masked) trees, grass, bushes, ect. I would say high poly. I got good results. Then I massively reduced the polygon count, my fps only slightly improved. After seeing this (and seeing the speed-tree bit(I also have)), I am massively interested in your cases and further videos! Specifically, if my Plantain leaf has a hole, Sounds like i need to cut it out of the model itself. Or how tight should the model be against the material cutout, I think i did see a horizontal grass blade i recognized from Quixel, where the bottom of it was all flattened. This should be fun to figure out. Thank you so much for the break down (and mention of why I should trust you).
this sounds like problems i used to see with Godot, people complaining about how something works without actually looking at how the method was designed to run.
Hey! Fellow Unreal Dev here, loved the video. I think it's really good to see some positivity about the engine and another person outside of Epic mentioning how all of UE5s rendering features need to be used properly and together in order to get the best results. I'm a lighter but am very much looking forward to seeing your future videos to learn more about proper nanite asset creation!
Good video, but you gotta share the hardware you're getting these frame rates in. Because a big issue with Unreal games is that most of them these days seem to require expensive hardware that most people don't have, contrary to games made with classical practices in other engines that give similar levels of fidelity (even if it's a little less, and yet the performance is great). At least comparing the hardware can give us an idea on the performance of Nanite and Unreal in general.
I can't thank you enough for this video! 🙏 I'm about to graduate with a bachelor's degree in computer science and interactive technology and I can tell you speak the truth from experience while others state their opinions. 🥳
Did you watch the recent Epic GDC talk that specifically covers Nanite foliage and over draw and ongoing development in optimisations and solutions to known issues?
Good vid - thanks. I was going to ask if there are any resources on how to do the aforementioned or using something like speed tree to do it, but then you said you were doing one lol. Looking forward to it 😎. I’ve found it difficult learning it, when buying foliage off market places etc, as they are usually quite high poly and heavily masked. One feature that has been helping me a bit, and not sure if it came in with 5.4 or 5.5 (or earlier) is the “pixel programmeable disable distance” for nanite foliage using WPO. Which essentially turns off the masking. So it doesn’t work for all meshes and cards but has helped for a few when at a distance as the change is not noticeable. One of the other things that’s been causing me issues and not sure if its normal or it’s just instancing in general (with TSR), as I’ve found it’s the same with non-nanite foliage spawners, is that when using simple wind the created motion vectors are very expensive. So turning off motion vector creation for meshes with static WPO helps.
I love comments like these, please ask and yee shall receive, I believe that speed tree is one of the many other programs Dallas wants to cover in his future videos. Thank you for your feedback~ 😊
Great video! More of these please 😀 I'm guessing the reason a lot of small devs use a simple nanite retool will be because all the tutorial videos mention it. Due to the grass noise bug, I watched about two dozen videos on this topic and only one mentioned remaking the textures from masks to opaque, but the result was a very strange grass geometry, and thanks to your video, I now know why! 😊
Thanks for the video! BTW, can you explain why in STALKER 2 trees just pops out out of nowhere? Don't they use nanite? How you can achieve that level of LOD horribleness?
I really love your videos, you explained really well questions that i asked long time ago. This is reason why I never got any decent framerate from Nanite and now i got answers. You really did great jbo explaining it.
Thank you for making this video. We've been developing in UE5 since EA and it's been a long and bumpy road, but things have been turning around in the last fes months as we learn how to optimize and dev for Nanite. I have 2 questions/concerns currently for Nanite Foliage that maybe you can address in your next video. :) -Wind and Interaction. How will foliage animate? will it be able to with out smearing? -Memory size. Millions of poly on screen doesn't effect FPS but it does mean massive asset files. We have to reduce nanite meshes through out the game just to stay in a reasonable memory budget. Im assuming high poly pine trees could potentially be 10-100mb or even more. This adds up very quickly if every asset in the game is equally large. Most consumer-level GPUs will max out Vram and crash.
Great video that explains alot of the nitty gritty details of nanite, but it has to be acknowledged that broader awareness of the sub-optimal image quality in games and optimizations developers now perform, and corresponding videos like this which inform them how to fix them, would not have kicked off without channels like threat interactive to get everyone fired up on the topic and provide a deeper-than-surface-level explanation of some lacking aspects of modern games. Like an art teacher once told me "its not because what they did was special, its because they did it first."
Great explanations about the technical details. The issue I see with drawing foliage as an opaque mesh is, you cannot do light transmission anymore. And I think people have gotten used to that, when it comes to the look of high quality foliage in games.. I guess that's why to me personally, the visuals of the old workflow look slightly better. Most real leaves on real trees usually do transmit light, which becomes impossible to achieve when rendering everything as opaque..
Very informative, thanks for the video! - I'm making a small Unreal5 Demo and I have been struggling to understand the Nanite topic. I have to give a try replacing my masked grass with the full modeled one. Waiting for the detailed video on how to do it properly!
After being slightly demotivated last few weeks from reading and hearing about all the bad parts and future of unreal engine, this really made my day! I was even having thoughts of returning to unity. Im looking forward to more content and videos from you, well deserved sub!🎉
Great vid. What nanite foliage packs are you using? One of the other big hurdles these days is finding foliage packs on FAB that are actually fully modeled out geo for Nanite the way you've shown. I've noticed a lot of 'nanite ready' foliage packs on the marketplace actually still use masked materials, but because the creator can 'convert them to nanite with the click of a button' as you've shown, they misinterpret their own assets as being nanite ready.
Yeah same haha so the grass i made, and the trees are from this pack www.fab.com/listings/09ad5f14-aada-400f-af9f-a42610edf760 That being said, even those trees by default have masked materials but you can just change that to opaque and it wont really make any visual difference
I tried to use nanite on some industrial equipment models. It didn't work very well, so I went back to LODs. It seems that nanite is not well-suited to inorganic shapes like machinery. Even modeling sidewalks with things like cracks and expansion joints came out really bad. Nanite was reducing the geometry prematurely and it looked terrible.
I use nanite for hard surface, it's a game changer. probably the best use case, you just model mid-poly with unlimited details, unwrap it and that's your final mesh. what was wrong visually, any screenshots?
I'd suggest tweaking your mesh settings in Unreal, maybe enable preserve area or play with the option I can't remember the name of, it's in the settings
this is the content that threat interactive could have been making, if the focus was a bit less on attacking developers and epic games. Great stuff and im happy to see this more technical breakdown of the problem
This is still incredibly wrong, this video is terribly misleading. "Nanite is now the industry standard for videogames" is a straight up lie, and a very harmful one to the folks which this video is directed at (Newcomer devs and non-devs that are interested in the game industry). While this person might not be as malicious as Threat Interactive with his grifting plan, its still straight up misleading.
@@naruka777 through the lens of unreal engine development, it is all solid info. I don't see why an uninformed layman would run into this content without having at least a bit of an idea what they are doing already
I rarely enable all notifications for a TH-camr's videos, but this video had me hit it. You're like, 1 of 3, out of 500+ subs. Can't wait to see your next video
This is very interesting. Thank you for bringing this up. I wonder why didn't Epic add a warning/error message that tells users to use fully modelled opaque geometry in place of alpha-clipped/blended cards. It seems to be such a simple thing. When Nanite is applied to a material with transparency - show warning that Nanite will perform poorly unless the geometry is fully opaque. Even if this works perfectly though - this tech and pipeline is quite specific and only makes sense for top-budget productions that aim for maximum fidelity, and the hardware demands of such a solution are still going to be very high. Using film-grade models in games to me is just insanity, because all of this geometry needs to be authored and shipped to users. Then it needs to be streamed from disk at runtime. As amazing as the visual results can be, this is still quite specific. So it seems 90% of the games don't want to use Nanite anyway, because unless they go this film-grade geometry route, it's only going to make things slower and heavier for them. Adopting such a workflow for large open worlds is insane, because then you're going to be shipping 200-500 GB packages, and games are going to need a dedicated SSD to run. Not to mention download times. This is really forward-thinking technology but to me it's way ahead of it's time, where storage is not getting that much cheaper fast enough. Imagine being able to only have 2-3 games installed on your 1TB NVMe SSD, each one taking a week to download. I still think Nanite is really meant for film production and it's usage in games is quite experimental. Not to mention the cost of having your artist model every flipping needle on the pine trees. That means more and more assets will have to be bought from assets stores, which means more and more games will look alike. Converging on common film-like fidelity of games seemed exciting to me 10 years ago, but as we're getting closer to it I realize that there's only so much fun in playing games that actually go there. Turns out art direction and style in game graphics has much more impact that I have appreciated.
Finally someone with common sense on gamedev youtube 😂 The engine is offered "as-is"!! It's up to you to make a game with it, not the other way around!
Hey as an Unreal dev - a UE programmer with over 15 years of experience now, but focusing mostly outside of rendering (architecture, multiplayer, optimization, porting) - the hardest part of UE5 is that there is SO MUCH new stuff. And hearing your showcase of the trees, Im finding some things in common. So a senior programmer on UE4 used to focus on the well understood state of the engine, improving upon it, where necessary. You could focus on architecture, implementation of more complex and finnicky details and guiding juniors all at the same time. However, with UE5 there is Mass, Iris, Mover 2.0 etc. etc. that each require considerable learning period even for a senior programmer. We dont have that much time to be the sanity police the project, we dont have that much time to go over work of juniors, we dont have enough time to fine tune settings, we dont have enough time to do the important things, that we would otherwise do. And stake holders only hear how cool everything is from Epic (thats not really the case for the studio I work with though). Some complaints about UE5 that are being highlighted about it are true, however, and Epic has exacerbated the issue, but they have been part of the UE experience for a LONG time. I know a very senior rendering programmer and he has hated rendering pipeline of UE for a long time and that has nothing to do with Nanite or Lumen, just the rigidness. For a more general example whats often lacking with new generation releases is stability and completion state of features and feature parity, because the actual projects from Epic drive whats put into the the engine. They were also putting too much focus on new features, that get finished much later down the line, and sometimes you cant even rely on it. Ask a senior about UE3 and UE4 early major versions (Distance Field Shadows :D). Epic is trying to have their cake and eat it with new complex features, defaults that push new features, but are sensitive to correct applications AND pushing itself into the ex-Unity territory for a more general dev base. In other words: Mass is AWESOME, but you have to understand it and write for it from the ground up. Iris seems like a much needed rework of the VERY dated replication layer. Ditto for Mover 2.0. But seniors dont get enough time to douse all the fires coming from so many new things. Finally, wider user base means more smoke from the same fires, especially, when so many new people scoff at the best practice of understanding and working with UE code: READ THE DAMN CODE. No good, big project can be ever understood by reading the documentation. Documentation of any project like that gives you like 10-20% and youd die from boredom sooner.
OMG thank you! Someone with a sensible take. I keep trying to tell all these people shilling for unreal, but they don't get it. If I have to do something like write my own render passes in mobile LDR simply because things don't work, that's a problem. And even when I go to do something like that, you find that buffers simply are not being populated by unreal when they are supposed to be. So, what good is the rendering pipeline when you need to throw it out and write all this stuff yourself? Don't even get me started about the state of chaos, sheesh!
@lifeartstudios6207 I still consider myself an Unreal shill though, because it still does a lot of things right. I just don't have rose tinted glasses about and don't think that every aspect of Unreal is at the same level of quality. Good that I didn't mention BP, that's when you would end up seeing me as a total hater :D.
@Blackerer I do too, I would rather be using Unreal than anything else. Problem is I'm at the point where I'm basically writing my own game engine because unreal is such a problem to fix. Maybe if they gave me a single stable engine version I could roll with just modifying my own fork of that, but because I'm constantly waiting for them to bring changes down the pipeline I can't exactly make changes on my end that might be really hard to update with theirs.
Well said my guy! Been an Engineer (Now Lead) soon to hit 2 decades with Unreal. I have a video that goes over exactly this point titled your "not" doing it wrong. UE5 has failed to deliver on the promise of what they marketed the tool to be (This doesn't mean I don't appreciate the intention or still love unreal engine). A general purpose engine that will save studios money and reduce dev cost and cycle time.... and you outlined just about everything I also stated which was missing from the video. "The actual issue facing the 9th gen transition and the adoption of UE5". I will also state that Dallas popped by and left a comment and was very supportive of a different viewpoint from maybe a different segment of the industry and welcomed the feedback and conversation. Kudos really! As a studio I can state confidently that the issue internally has been the requirements to hit 8th gen and 9th gen hardware / gpus while dealing with holding your mouth just right for software rasterization while also upsetting UE5 for LOD fallback and dealing with WPO, Material switching and multiple RHIs as well as every system seeming to be busted (both newer and older optimization tools) along the way. The truth is UE5 has made things more difficult and expanded scope and cost.... not the other way around. He outlines alot of this in his video without really going into the tradeoffs or appears not to really understand the actual impact on a game studio's project scope with an example being "You want to be using full modeled geometry" ... Take a step back and really digest the requirements and request here. The time allocation, how this impacts previous gen hardware or lower end gpus you still NEED (its not a want if you want to survive) to support, how do you handle fallback for 8th gen? There is a domino effect for everything that is just simply explained away like "your just wrong".... Modeling time and Engineering time for BOTH methods. I keep going back to "when you know you know" but this is much deeper than alot of these surface level "just do this" type of explanations.
depends what the lower hardware is, on a 10series, maybe not, at least not at max settings without DLSS or something. I'm on a 4080, and we've tested it down to a 2070 and it runs well. Our game is also still very early on which is also an important note. By the time the full game is released, the gtx cards will be like 10+ years old
@@DallasDrap 80 FPS (or 50 in game) on a 4080 is kinda terrible isn't it? You're forcing regular people to use DLSS to have a playable game, which makes image quality suffer a lot.
@@SonicTheCat I see what you're saying, but currently there are still plenty of optimizations to go, and most of that has been focused on our dungeon system for its launch here in the next few months (will be a releasing a demo featuring the dungeon system) and that runs at about 80fps on a 2070 on max settings, we pretty much just need to use the tools we've created for automating the optimization process on the rest of the environments like the town there for example
As a beginner this was good to hear. I've heard the haters, but figured Epic wasn't stupid and that this new feature probably had more to it than just slap it on and call it a day. Your use cases made it clear when nanite is advantageous, instead of just saying "when you have a lot of geometry" in a scene. Subbed and can't wait for your upcoming videos!
We're currently using a mix of nanite-full-mesh foliage and cutout foliage, because it's tricky to get the specific "look" we want with the full mesh approach. And trees moving in the wind are super performance heavy, which I'm told Epic knows about and should be working on. But it doesn't help us NOW, when we need it working. So we did a bypass in the engine and had to do our own "faked" lighting and shadows on trees. (I think Epic recommended cutting WPO wind at a certain distance and possibly using billboards in further distance, but for our use case that didn't look great.)
Thank you for the explanation, this will make my current 20 fps experience more pleasant now that I know it's not the engine's fault. I'm also excited for the devs to properly use these awesome features so I can enjoy the full 40fps experience instead of the current 20fps
Wow, thanks for that review. Looking forward to your Nanite foliage technique tut. Can't wait to start modeling real trees, not that billboard bs, I've been doing for 20 years.
The exact same setting, yet it looks SOOOOOO much better and more realistic, while having better performance. Tho I'm not a foliage artist, and I have barely even started modeling assets, so I don't know if this is actually easier or harder for the artist to create. Very interesting video, thank you for the explanation.
I appreciate your message and coverage however there is a missed opportunity and one it seems the video completely misses… the point. Nanite, vsm and lumen are marketed and offered as a workflow to reduce development time and save on both performance and dev cycle time. However this “goal” has been completely unrealized. No studios can afford to isolate themselves to high end pc and still to this day target multiple platforms. We simply cannot ignore traditional optimization tools and methods. The lift here is NEEDING to encompass BOTH to hit older hardware. I’m not speaking for everyone however this is and has been the case for most studios that have fully adopted UE5. The issue isn’t how these things work it’s the contradictory gymnastics the engine has introduced to be valuable or viable to be the screwdriver to the screw that UE4 was targeting the majority of its generations hardware. The other thing this video completely fails to mention is how many studios have had to take it upon themselves to fix said features, memory leaks, broken older technologies (light baking, landscape tools, chaos) along the way 5.1-5.4. I appreciate your approach and information your sharing however most studios/devs worth their weight in salt know this information. Knowing the newer workflow vs the old does absolutely nothing when its the very gymnastics that you cover that has actually been counter productive to hitting targets and performance because so many traditional methods (precomputed visibility, light baking and the physics thread) have had some major issue in conjunction with the newer tech simply not being up to task at the time of adoption for most of these studios. I don't want to come off the wrong way but simply telling everyone they "ARE DOING IT WRONG" swings so far in the opposite direction of Treat Interactive that I can't really get on board with take on things either..... When you know you know.
Another point here: using full geometry for foliage results in millions of vertices. If you have expensive wind animations with a lot of Pivot Painter hierarchy, that is going to hurt. It also does not scale well because, unlike rasterization, which benefits from culling, you actually need to perform WPO on each vertex. This is because you cannot determine if a vertex is occluded until you calculate its final position. I would still advise against using Nanite for trees (though it’s fine for grass) and recommend going the classic route with billboards if you are not AAA.
I've just finished my testing because I thought, just like you, that WPO would be an issue. My results are pretty clear, if you don't have VSM invalidations, then WPO is basically nothing... I populated a forest with 14k trees, with PP2, tested with both masked Nanite and Full geo Nanite, geo Nanite performed about 1.5x better than masked Nanite. I haven't tested without Nanite at all because I need it in my project for tesselation, and it's usually recommended to have Nanite on everything if you use it at all. I should note that I used the WPO disable distance to disable WPO after about 50m from the camera, and I also tried using the Pixel Programmable disable distance at the same 50m on the masked nanite trees and it didn't help at all.
Great video! =D This is exactly the kind of information I've been looking for, and it's very hard to find. I have a few questions: How do Nanite-optimized games compare to the "old pipeline"? Do we see both fps increase along with fidelity? Do we see improvements in FPS and fidelity across all hardware levels with nanite? Low, mid, and high specs? How does this compare to the old pipeline? Why should we use the unreal-optimized pipeline? What things make it better or worse compared to the "old pipeline"? As a solo dev looking to transition from Unity to Unreal, I would love to see a video that walks through the Unreal-optimized pipeline step by step, to take full advantages of all its tools. And also a video that explains what the pros and drawbacks of tools like nanite, mega-lights and lumen are. To get a better idea if those tools are for me or not.
Excellent! Looking forward to more videos! We can't blame folks for using Nanite "wrong", there wasn't any solid public information on it for years and everyone has just been figuring it out on their own. We also see Nanite improving pretty drastically from 5.0, so we're developing against a moving target (more than other 'stabilized' features). Edit: That said, Nanite still lacks full integration for some systems and tricks we've used for many years and I keep finding more.
Are you planning to make video analysis of performance of UE5 games with terrible performance with explanations and probably even showing possible fixes? I'm specifically interested in Project Borealis Prologue, only way to run it in 60 fps is to lower all settings down and use dlss+frame generation
Thank you for explanation. Can you also tell what needs to be switched off if I don't want to use these features? I'm mostly going to use UE audio engine I don't really interested in making a realistic game.
Maybe you'll say later in the video, but i don't want to forget. How do I know my foliage is nanite foliage? I'm using the megascans stuff, but did the trick with the right click convert to nanite thing.
Hello mr. As a starting dev in unreal (and recently learnt SOME blender things) can i ask you if there is any form of documentation/guides on how to implement nanite and make these complex models for it to use? If I understood correctly the workflow differs at the very beginning of creating project so my guess the entire process feels different? Thank you for the rant.
I saw your TI video and thought it was good but this video made me sub. This is god tier information that I don’t think I’ve read or heard anywhere else. The documentation for UE5 is comically terrible. I use the UE Editor to create digital landscape art for no other reason than tickle the creative side of my brain. Great video, keep it up 🤜🤛
FINALLY! Some information I can get behind... as only a 1 year "dev" I currently have a combination of LOD's and some Nanite... Maybe that's "wrong" to use both? But I did tests on pretty much everything I added to scenes and I found some things worked better with Nanite on, and some better with it off. Now I know why! THANK YOU! I also went down the road [you mentioned] of removing as many triangles from foliage etc etc... As a solo dev I have used a fair amount of assets, but done a lot of work on customizing textures and where possible mesh's. Now I'm going to have to seriously consider modelling my own trees in the Nanite way to take advantage of that.... Anyway... more importantly... videos like this are SOOOO valuable and I appreciate it a ton! As a self taught guy, you don't know what you don't know... a lot of what I know is through extensive testing. So keep these coming please. I would love to know somebody who has the inside track, and videos like this are the next best thing. Information like this is hard to find, even on Epics forum where there seem to be a lot of people with opinions not based on reality.
Thanks for not shouting at the screen about how "bad" a great free to use tool is, and the people using it. Also thanks for showing this, as i have made the masked mistake myself. Now i can optimize even more! My game currently is already smooth, but anything extra i can do is great. Explanation plus workable solution over complaint = wisdom.
I hope you subscribe for more juicy tips~ I know there's not enough educational material out there, but this channels dedicated to informative and solutions. 😊
bro you really get mad from that guy, and I am loving it in a good way :) I have no clue about optimization, just trying to do my first game about virtual museum and find this information golden for my project :)
I was explaining this to another dev friend of mine, but the problem is people will watch that dudes videos, believe it all to be fact, get a job in the industry, end up working on a project with me and i'll end up spending half my time course correcting them instead of getting work done lol
@@DallasDrap I feel your pain man. It's like this in the hardware space too. People can latch on to the wrong information about something from people that just present it confidently, and we have to spend more time un-teaching them that stuff than we do actually working with them on the project.
The biggest argument that the Threat Interactive guy and others have that I understand is the image quality with TSR, TAA, DLAA, DLSS that is almost necessary with Lumen, Nanite. I personally am okay with some jagged edges and noise but devs nowadays are not even letting you disable TAA. I know 90% of people are okay with the temporal effects but I can not stand them. Great for screenshots but in movement it is really bad. Especially in UE4 & 5. As a part-time UE5 user I would like to see a video on solving the image quality and ghosting issue of UE5's AA options while maintaining good performance in a Nanite scene.
Note that TAA can actually be pretty good. Exact implementation and tuning define how bad ghosting is. There's documentation for controlling ghosting, and you can dig far deeper with the source as well.
Thanks for the suggestion! Ill be making a video about that exact issue. To sum it up though here as you wait, a lot of that can be explained with the low frame rates + low screen percentage + low samples = ghosting issues, blurred aliasing and all those problems. The answer to all of which essentially is optimization. If, for example you have a scene running at 90fps this means the frames arent going to have any noticeable stutter or drops which means frame generation wont smear to make it less noticeable, it will also allow for higher samples as well. Basically if the devs fix the optimization issues theyll fix the AA issues
Main purpose of TAA is not exactly only to smooth out jagged edges, you can think of TAA as temporal supesampling. A lot of modern rendering techniques require supersampling to actually look good (from global illumination, volumetrics, reflection, RT, even soft shadows, etc... just to name a few) and they used to be prohibitively expensive for realtime rendering at a sample rate high enough to look good. Here is where TAA comes in, TAA achieves supersampling through time (temporally). TAA accumulates information from previous frames with different recombination techniques of current and past information, since the information keeps accumulating it achieves almost the exact same effect as supersampling. TAA intentionally renders each frame with a subpixel jitter applied, this is done to gather more information around each pixel. In other words TAA allows the prohibitive cost of many rendering effects to be amortized over multiple frames, TAA is not "lazy devs", TAA is an optimization technique. The options are: - Use TAA - Ditch TAA and revert the state of graphics at least 10 years into the past (forget GI, nice soft shadows, reflections, etc...) - Ditch TAA and use actual supersampling which will make modern games magnitudes more expensive to run while keeping the fidelity - Allow players to disable TAA if they want to, the image will look worse but be more stable And TAA has issues, everyone is aware of them, but there are tradeoffs. As many issues as it has it has equally as many benefits. TAA uses motion vectors to basically calculate how each pixel moved from the previous frame to the current... but motion vectors are notoriously difficult to get right with particles, transparent surfaces, dynamic materials, etc... Most artifacting from TAA comes from missing or incorrect motion vectors. There is work being done to make all this better, everyone is aware of the issues, but it's not something that everyone can just ditch because it does have many actual benefits.
@@DallasDrap Exactly right, and to give an example; let's take Red Dead Redemption 2, if I'm running it on optimized graphical settings, which my pc can handle at ~60 fps, I won't notice any TAA problems like ghosting, but if I try bumping my settings to the max which my GTX 1060 can't handle very well, I'll be running the game on ~30 fps, and guess what? I'll start noticing ghosting and shimmering, particularly on foliage and trees as they're waving around. TAA works great, but first make sure your PC can handle the game at reasonable fps. Edit: Ghosting can also be due to your own monitor, some monitors have poor reaction time in comparison to what is happening on screen, so they'll generate ghosting, it particularly happens on VA panels.
Most developers just enable Temporal AA without changing anything to use it properly. UE has flags you can set per actor/material to make the TAA pass behave differently and cause less ghosting for example. Most developers don't even know this. There is also the TSR debug view that nobody uses unfortunatly. TAA itself isn't the problem, it's how the developer use it and optimise it that is the problem.
Well as i get it for now, we are in some sort of a transitional period between development pipelines, or maybe it's just separated pipeline that applies only for photo-realistic graphics at all. For me DLSS\DLAA\Raytracing and maybe even a frame generation is a future, which, no matter how anyone see it, will become a new standart. Even if we take your show case as example, i just can't estimate how long it will takes to recreate with traditional pipeline. To be honest, first time when i saw your video about AA it seems off at that time, but hope you show more technical stuff like this. It's a lot more convincing
Thanks! Yeah, i dont think frame generation, DLSS and all that will be going away, especially the investment Nvidia for example has put into it. But yes, were in a transition period, and right now we're sorta at that peak of the transition. Where when UE5 first came out, we were all still learning it, and even now, i mean we learn new things every day but at least the important bits are becoming increasingly more understood and at an increasingly rapid rate. And like i stated in this video, not every project is going to be using nanite foliage, its not for every project, however i just wanted to make videos like these to demonstrate if you are going to do it, at least do it right haha
Wow, that's a much more knowledgeable video on the topic than the one by that certain (in)famous creator that I happened to watch first. You are sharing your expertise with such composure and charisma. It's a pleasure to watch. I hope this video (and future tutorials) will be shared across game dev studios. Proper training with the tools, or rather the lack of it, is a huge problem in many industries and is often underestimated by "the management". This kind of video is a great way to share good practices; I'm looking forward to more. On a different topic, what titles do UE5 features (like Nanite, Lumen, etc.) right? I played Remnant 2 and Fortnite and, as a gamer, I wasn't happy with the visuals-to-performance ratio for these games...
Black Myth Wukong, Silent Hill 2 remake, Tekken 8, Unrecord (the bodycam game that looks literally photoreal) and many others. Keep in mind games take many years to develop, especially to polish and get ideal performance. Games coming out in Ue5 right now have only had 2 years to use the engine (waaay shorter timeframe than what a typical AAA game usually takes to create), and new massive updates are constantly coming out for UE at the moment. You can port projects from UE 4 to 5 but seems to be a bit of a nightmare especially if you intend to make use of all the new features.
This is a very insightful video. May I ask two questions? First, how can I determine whether foliage uses a mask or not? Specifically, how can I analyze if a particular foliage is suitable for Nanite or not? Second, which grass did you use in case 3? I really loved it! :D
To answer question one, you can look at the "Pixel Programmable" viewmode, anything red either uses masks, transluency or WPO if I remember correctly Question 2 I'm not sure, I personally use MEKA assets for nanite ground foliage
So you compared Nanite with masked meshes to Nanite with unmasked meshes. But you should have compared Nanite to classical LODs. Otherwise we don't know which is better for foliage. For example, Horizon Forbidden West uses a relatively high screen resolution and very highly detailed foliage with classical LODs on a base PS6. We haven't seen whether anything like that with is possible Nanite with Nanite foliage, even when unmasked.
The first example is traditional grass and trees, which I'm sure had LODs. It ran at around 28-30 fps. However, I agree with your sentiment that I'd love to see two developers go head to head in a Nanite vs LOD challenge to see who can make the best performing scene using the same visuals.
No such thing as masked or unmasked meshes. There are LOD based meshes and Nanite meshes. LOD based meshes use masked materials to fake the details and Nanite Meshes shouldn't use masked materials, Nanite meshes should do all the details with more geometry. One of the most used masked materials is alpha mask for transparency and meshes behind transparent materials cannot be culled properly (optimization), which means that Nanite will overdraw too much. If opaque materials are used with Nanite, then Nanite can cull a lot of the geometry because all the pieces of the mesh are tiny and hidden behind the opaque geometry.
Yes, if you hate games that run at 14 fps on a 2000$ rig packaged in 500gb downloads, you're in for a treat because that's precisely what nanites is about. But hey, at least some studio exec with no background in game development can say "our game has more polygons therefore it looks better than other games!"
Nanite is actually great at compression, and there are other areas you can optimize for storage space... You can save on normal maps, maybe use a displacement map on lower poly models. Nanite is actually not a problem in terms of disk size, except if you make really really specific things that it can't compress
One obvious thing why Nanite waste space and memory is everything need to be on high geometry because it works without textures. When using textures, high resolution textures are not needed every object. Another thing is closeups. When using LODs, closeup versions can be loaded only when player pick object in hand in first person view or similar, controlled thing so they can save a lot of VRAM because there is no need to keep many closeup versions in VRAM.
A lot more digestible than that shapiro guy rattling off his script. I could not follow what TI was saying, but this was super easy to follow and I can see the point you're making. Thanks for the content.
1st of all excellent presentation that doesn't get way too technical but gets the point across👏👏👏 2nd of all you want to tell me that if I properly use a tool, then things will be better? Preposterous! A certain someone along with others told me otherwise! Jokes aside this whole thing especially from ppl without credentials, and by credentials I mean ppl actively in the dev process, reminds me of when we were kids and we were seeing TV games like Takeshi's castle etc, and we were thinking to ourselves I can do this sooo much better and faster or whatever. Pointing fingers etc etc is easy, making solutions is harder. Keep up the good work Dallas!
this is really informative! however, i think a lot of people coming into the comments are going to be confused by the title as this is mainly about nanite, while a lot of gamers' concerns that have been stoked by channels like TI are centered around anti-aliasing/upsampling and temporal artifacts. i don't have any experience in development in UE but have struggled with bad AA implementation in a lot of games on the engine, and i hope artifacts and blurriness continue to be reduced with new tech, so i was wondering if you had any plans for videos on this issue
This is most appreciated. If the naysayers will be honest and apply what you are presenting to their process, then perhaps they may rethink their position. Assuming that they are open to the notion that their initial assumptions are wrong. What I really want toknow is, why hasn't Epic directly come out and explained "This is what you need to be doing to get proper results with Nanite..."? If they would quit leaving these core details out of general presentation, then perhaps there would be fewer nay-sayers. I will admit I haven't watched every single presentation they've done, but at the same time, I haven't heard them once come out and say "You need to train yourself to do things totally different from what you've learned before now. If Nanite doesn't like masked textures, then perhaps when converting a mesh to Nanite, it should pop up a warning: "This object is using masked textures which can negatively impact performance. Proceed?" [yes] [no] [hide warning] The only thing that would need to change is a check to see if textures assigned to the model are masked before either completing the conversion or presenting the warning.
I'm a bit confused. In Unreal Engine's presentation "Nanite for Artists GDC 2024" they specifically use this as an example of how not to do it. Nanite wants to retain the boundary of the mesh. The shape and size of the meshes are therefore important. The boundary is quite large on a pine tree, while the area of the silhouette is quite small. Nanite can't reduce the polygons on a pine tree without compromising the boundary, which it won't to and you are therefore left with a to large mesh at far distances. In their presentation Unreal Engine is using a combination of LOD with nanite and billboards for foliage using PCG. Quite bizarrely complex, with the reasoning being that they haven't figure out how to solve nanite foliage yet
If a developer uses Unreal engine they should be MANDATORY trainings to learn how to use it properly. Stalker 2 is such a [...] because of devs not working with it as it should. It has HUGE tree pop ins, fps issues, horrible noise in the lightning...........
Currently in the process of creating my own full geometry foliage. There are not many tutorials covering this full workflow so looking forward to watching yours. Thank you for what you do and keep up your great work!
What about file size and memory constraints? I've been using unreal for years and it's always been hard to find a good balance, especially for large foliage such as trees that aren't half a gig each.
Two things: yes, full geo models take up more space, but you are also ditching the alpha channel (which is usually in the Albedo texture) which DOUBLES the size of the texture. And, as you probably know, textures take up most of the space in a build anyway. My suggestion is to reduce the texture size, especially Normal maps (which can be half the size of Albedo) and ORM/ARM/MRO (which can be a quarter). Channel packing is highly recommended. Also remember that Nanite meshes take up less space than classic meshes. Second thing: storage nowadays is very cheap, even for NVMe. I wouldn't bother too much to keep it drastically down, especially if you gain that much performance. This is not an excuse to avoid optimizing those textures (because Vram is still limited in GPUs) but at the same time is not a big deal as it used to be.
@@OverJumpRallythe alpha channel doesn't "double the size of a texture" 🤨 in an RGBA8888 image the alpha channel is 1/4 of the image size. That being said for foliage specifically with nanite you probably don't even need an albedo, normal, OR roughness map if your grass mesh is using thousands of triangles, you could just color the mesh with vertex colors and use the vertex alpha for roughness, that would definitely offset the increased model size somewhat AND reduce vram usage because there would be fewer textures
@@jlewwis1995almost nobody uses uncompressed textures for environment 3d art assets at least last 20+ years. For compressed tex 2x size for tex with 8bit alpha is correct
@@jlewwis1995 Wrong, the moment you enable the alpha channel in a texture it doubles its size. Try it yourself. It doesn't matter if it's just one channel out of 4. And, yeah, you need Albedo, Normal and Roughness if you are aiming for photorealism. You also need that for SSS.
@OverJumpRally Well this video is about foliage and for stuff like foliage that's mostly a single color or 2 you could easily just paint the color onto the vertices if you're making it for nanite since you're going to be making it with a lot of triangles anyway so might as well use them, like how much color variation is there on a leaf or a blade of grass that you couldnt just select all the vertices and do shift + k in blender to turn them all a green color then hand paint any extra variation, or bake a noise map onto the vertices and tint the result, assuming the poly count is high enough to have good enough vertex resolution. Also because there more vertices than on a traditional masked material mesh you could probably get away with using vertex normals for lighting calculations too. And as for roughness like I said the roughness could be stored in the vertex color alpha channel since you're using opaque materials with nanite but that alpha channel is probably still going to be there in the vertex color information (unless it would otherwise be removed by some mesh optimization when building the game) so once again you're just making use of stuff that's already there Of course for objects that require a particular pattern like signs with text you obviously want to use a texture map for that, but that isn't what this video is about
One topic that is greatly overlooked in optimization discussion is the bounds culling. And the performance gains of packing actors vs loose static mesh components. Actor count matters, and Epic rarely talks about it.
Thank you so much for this. People keep blaming the engine for providing tools to creators, instead of properly blaming the people who are *using* those tools.
Very elucidating content! I'll try the high-poly vegetation as you mentioned, not the masked/LOD version I use. Unreal itself should have more thorough material available on Nanine. Most people I know who experiment with Nanite learned from internet tutorials, most of them very simplistic, as you appointed (select the asset, then right-click to show menu, then click on Nanite, and that's it) and have the same rant you pointed about not gaining that much of FPSs. Let's consider Nanite is still relatively new to most users, especially in concept; it is not activated by default, and certain assets have different ways of activating it. There are some ways to do it more practically (plugins and community forum tips/scripts), but they may convert non-prepped assets, too. The best way to make people really get into it should be Epic itself to create a tutorial scenario for Nanite, then start from landscapes to foliages and model placing. The webpages/videos/pdfs should show what assets are better for Nanite and the procedures to activate them properly, showing the impact on the FPS. Then, best practices should be taught.
This is super interesting. Do you think that UE5 struggles to run on weaker systems because there are things that cryengine for instance does in GPU (like grass models which are static but then have tricks to make them look like moving) and UE5 does not use static maps (not sure if right nomenclature) for the most part but uses the CPU to check position of grass.
yeah, i mean UE5 is still not without its faults and has a long way to go in some regard. The way it handles movement on foliage for example is pretty bad, at least in the computation of it. like if you do it wrong it'll drop you like 20fps haha
@@DallasDrap yeah. I did a test a while ago in game (Remnant 2) not in engine in my 12600k where I had it clocked at 3.5 with 4 cores and then 2.33GHz with 6 cores active. UE5 ran better with six slower cores rather than 4. This was to try and see why performance of UE5 games is generally terrible on the Steam Deck. And why move things that are usually GPU based to the CPU?
@@AcharaStudios if not, i would lose about 20fps XD. With just global WPO it craps all over the framerate. That'll be part of the next video, cause theres a few tricks on making it run well and look good. VSM's for example are still a pain but there's a trick to help with VSM computation ill be showing
@@DallasDrap Oh yes, you can fine-tune VSM update/invalidation rates, as well as have separate static and dynamic VSMs. Good for foliage. Also, WPO can still be culled on the GPU, the shader way, with neat blending, so there's no sharp snapping as it reaches the hard limit from Unreal's CPU culling.
![[What] Do We Need to Render BILLIONS of Polygons in Real-Time - The ULTIMATE Guide to Nanite](http://i.ytimg.com/vi/RRKCqmctxLs/mqdefault.jpg)
This video is more of an explanation/breakdown of the nanite workflow and process. The detailed tutorial will be coming shortly!
Want to see more? Join our game's Discord to see behind the scenes streams and the latest updates, as well as get help developing your game!
Join the Discord: discord.gg/2JtBP49RzS
What about the memory, storage space cause high res meshes are memory intensive & shader complexity performance high res meshes with complex shaders are demanding for GPUs tell us about your computer specs because majority of average gamers play on mid-range hardware?
@@ingamgoduka57if you use real nanite, then you don't need textures to give details into the model, for example normal texture
People are dumb, they think nanite created just because of epics, they build nanite on top of mesh shaders, watch directX mesh shader presentation
@@Mr.Sunshine2023 Meshes shaders are just advance tessellation with procedural geometry generation GPU driven frustrum & culling. So it still doesn't explain the cons of extreme high res meshes the memory usage & complex shaders.
Are there good nanite foliage packs on the store? And why megascans don't do it (not a critique, just wondering why epic don't do it which makes me crazy)
Hey, technical artist here. Do keep in mind that nanite simplifies geometry based on connected meshes, it's what Epic calls "aggregate meshes". The reason this is important is because if you have continuous surfaces nanite will keep reducing the mesh properly at large distances, but if you have a lot separate submeshes nanite will try to keep the mesh boundary which means it will have a harder time reducing the geometry. This is specially important for foliage, a pine tree will underperform compare to a any tree with big leafs, simply because each need can't be reduced further properly
I was thinking about this, this is a case where you would still want to use LODs, but only two - the second one being a 'more blobby' thing that is continuous but still looks good, right?
Because from far away, you very quickly lose the ability to see those needles anyway no?
Something something, can't see the forest for the trees, can't see the tree for the leaves...
Excellent point! Yeah i had an artist on my discord showing me a pine tree he was trying to make, and I had to show him an alternate way cause you dont want each needle to be moddled. Like in those ones its really just two planes intersecting where the mesh of the planes conform to the shape to mitigate that specific issue you mentioned. Glad this comment got lots of thumbs up!
You can increase the Max Edge Length Factor in the mesh to avoid losing such details.
But overall pine trees are heavy to render no matter what!
@@tempchannel17 Don't use LODs, just use Nanite with masked material, which is still a better option than LODs if you already enabled Nanite for everything else.
Mixing Nanite and LOD is far worse.
@DallasDrap I can actually provide more data if you are interested, there are more cases where topology plays a role with how well nanite performs, vertex data like UVs, normals, vertex color and so on can create discontinuities in the mesh that will also affect these boundaries, one good way to test is to create two rows of your objects side by side in a length of at least 100m so that you see your mesh at a small size, in one row you can have your unoptimize mesh and in the other you try to create continuous surfaces as best as possible, you will see that even if the target polycount is the same and the end polycount is also the same the rate at which they go to the higher polycount to the lower one is not the same
you can all use the max edge global CVar to preview it, by I find it harder to see the "gradient of change"
also, keep in mind one of the biggest features of nanite is the fact that cluster can cull each other, so having very small details of geometry like the pin needles doesn't allow them to cull what's being them, which mean you end up with a lot of overdraw, we can actually see this in your video where the darkest parts in the overdraw preview were in the tree logs, because they were big enough to cover clusters being them, so the smaller you go the worst it will perform
finally, one point that I find super disingenuous from TI videos is the whole talk about what they call "quad overdraw", while their explanation was fine this whole comparison with nanite is ridiculous considering that nanite uses a software rasterizer that doesn't have "quad overdraw" issues, so the whole point of optimizing meshes for hardware accelerated rasterization makes no sense for nanite, yes, this also means their rasterizer is slower but slower doesn't necessarily means slow, it means what you showed in the graph where the initial overhead for nanite is higher but after a certain point it scales better
and don't get me wrong either, nanite is not perfect, don't get me started with shadows and raytracing, nanite has issues, just not the ones that people are pointing out because it doesn't follow traditional conventions
I am begging you to make more videos like this. These 20 minutes just flew by, very informative and interesting to watch
He's always thinking of what subject to break down next on his channel. I hope you subscribe for more~ 😊
The trouble is that epics began to tell how to work with nanites only in 2024 (!) 4 years after the release of ue5.
Seriously - the lecture "nanites for artists" came out in the spring of 2024!
Many people don't even know about the existence of these materials!
exactly! haha just another point for my last video, how like, the reasons current UE5 games "suck" or might not be what people wanted or hoped is because we're all like just now figuring this out properly haha
but it seems to only be about foliage...nanite is not just for foliage
@@vladhristev481 Because Nanite on rocks and other meshes doesn't cause as many issues.
@@DallasDrap Epic's unreal fest 2024 video they just released points to some massive improvements down the line. It sounds like they're working on a fix for the traversal stutters and pretty much every single issue UE5 has rn.
@@pctechloonie im watching it right now! haha
you should do a video talking about Lumen and how to use it properly
its coming! haha
@ YES!!
nanite too
with the amount of sizzling everywhere, im pretty sure he hasnt figured it out.
@@DallasDrap You should also do one for MegaLights and Nanite Skeletal Meshes
While a very interesting study and rebuttal to the growing Unreal Engine criticism, in my experience lumen has the bigger impact on performance than nanite does. So you only addressed half of the conversation here. Also while your study is interesting, it's hard for me to understand how it would affect my project which does not have foliage at all. I'd like to see more cases. I also want to know what settings you had on and what hardware you use. Did you have any AI upscaling like DLSS active? What model GPU are you running these tests on? What anti aliasing method are you using? How many levels of LOD did you have for the masked material foliage? Etc.
Now it may be true that basically every professional developer except for yourself just doesn't know at all how to use the engine. You have a huge opportunity and perhaps a responsibility to create as many UE5 tutorials to finally show devs how to optimize in the engine. But when you show your own game struggling to hit 60 FPS and you brush that off as vague optimization issues in other places, you aren't really putting out the most convincing takedown of the Unreal Engine is unoptimized claim. I'll be convinced that the engine isn't the problem when I play a single Unreal Engine 5 game that runs smoothly. Which at minimum is native 1080p 60fps with no dips.
I really wanted to see the overdraw view on case 3
ah good point! My bad. When I was doing the video I was kinda just flowing with it but you're right! I can maybe post it as a short or something here soon
In theory should have low to none overdraw, because all the foliage is opaque, the overdraw would be caused by UE5 occlusion system not being 100% accurate (tbh no engine have perfect occlusion culling)
I wanted to comment the same.
Yeah an overdraw view of the fully nanite scene would be interesting to see.
@@Bino-hy5bl It's actually a lot of overdraw because nanite doesn't use the standard Occlusion culling system, has it's own one. With pine trees there's massive gaps where geometry isn't occluded and thus needs to be rendered resulting in massive overdraw.
As the system stands you'll never be able to draw a pine forest like this without hefty performance cost or ugly artifacting. Broad leaf trees and dense ones fair better as they can occlude other nanite trees geometry better but still not ideal. Far off foliage should still be transitioned to foliage/impostor.
Id say the main performance impact simply comes from the fact that nanite and VSMs require you to use SM6 which itself runs slower than SM5. So like you said, nanite itself isn't necessarily the culprit. Its a mix of how people utilize it as well as the fact that SM6 must be used.
this is exactly why I really like the comment section of these videos, it allows for more in depth comments and discussions, but this is correct! and thank you for pointing that out.
@@DallasDrap I don't know if you're already planning this, but a video covering VSMs should also clarify things further. From what I know there is a way to alter the VSM quality so that it's not super high resolution and you're able to use what you need. But I believe most if not all ways to alter VSM quality are console commands only.
@@thana3270 Yes, it's r.Shadow.Virtual.ResolutionLodBiasDirectional which is in Scalability.ini
For Ultra I use -1.3 and for Low -0.3. That's another big boost but also the quality drops. There are other variables for VSM but that's the main one.
In my experience the biggest performance hitters are, in order:
Collisions
VSM
Lumen
Tick rate
Masked Nanite
Textures bigger than needed and non-Virtual
This is a fantastic start to what I believe could be a great series of videos and tutorials that brings the discussion (or argument) in a positive direction aimed at educating developers rather than... whatever the latter is.
Keep up the great work!
Someone suggested i keep the "youre doing it wrong" sorta tagline and i just might haha but yeah, this is going be a series :)
Your grass and leaves imposter geometry is like 90% transparent. No wonder the performance tanks so much!
Dallas, thank you for showing this workflow! I was a bit confused with some use cases of nanite, especially foliage and this video helps a lot
Glad it helped! Im working on a tutorial which includes building nanite foliage as well as tips and tricks for keeping it further optimized. That is coming next! Trying to get it done between tomorrow and monday
@@DallasDrap Wow! Looking forward to learn some useful workflows from that video
Just to add to this, Nanite is designed to render approximately 1 triangle per pixel. That means if you're rendering at 1080p, you're targeting 2 million triangles, and for 4K, you're increasing your triangle count to 8 million. Now, the issue with overdraw, and why @DallasDrap mentioned that Nanite doesn't like it, is because if you're overdrawing, you're effectively rendering more triangles than you need to (i.e. more triangles than your pixel count, and triangles getting rendered over other triangles, which you won't see anyway). It's just something to need to look at if you're using Nanite.
Did you just admit that the thing that was supposed to "kill polygon count" needs to have rough polygon count to function well?
I cant be the only one who thinks that this doesnt sound right, can I?
@@Dizintegrator No, I didn't say anything about rough polygon counts, or anything related to how you should structure your polygons. All I said was why you need to keep an eye on overdraw.
@@RazielAU sorry, I must have misunderstood the part where you clearly stated:
"... Nanite is designed to render approximately 1 triangle per pixel. That means if you're rendering at 1080p, you're targeting 2 million triangles"
@@Dizintegrator In a nutshell, Nanite takes very high poly meshes, breaks them down into pieces, creates many LODs of each piece and then further breaks it down into more pieces. It all ends up as a graph structure which is far more complicated than I want to get into here. At any viewpoint, the engine can pick a set of these LODs that will roughly map 1 triangle to each pixel. But it does expect that you're going to use Nanite the way it's intended.
As a simple analogy, if you have a line-art drawing which needs to be saved with good clarity, you should use PNG, while JPEG will work, it's not intended for that type of content. JPEG aims to store photos with a certain loss in detail to drastically reduce image size, whereas PNG is designed to compress simpler art like line drawings, but again, it can support full photos, it just won't be able to compress it as well. Nanite is exactly the same, if you're going to use it, you need to use it with the content it was designed for, which is dense meshes with a lot of detail.
This is for the most part unrelated to what I was saying earlier, which basically boils down to: Epic provides tools to check for overdraw, you should use them to see if you have a problem you may not be aware of.
Also, there was no need to say "the part where you clearly stated", you are being extremely rude.
If you actually go back and read what I wrote, what I "clearly stated" was that "Nanite is designed to render approximately 1 triangle per pixel", in other words, the engine/Nanite handles that, which should be super obvious. I never said or implied that you have to reduce your model's triangle count, since again, the engine obviously handles that.
But of course, you're going to conveniently quote only a small part of my comment and take that little bit that you've quoted out of context to be rude and start an argument.
One big caveat of the fully modeled Nanite foliage is memory. Even with Nanite compression, fully modeled foliage can and will take up a lot more memory because you're looking at multiple orders of magnitude more vertices and triangles.
can you compare the fps of the masked foliage with nanite turned off to the nanite foliage with nanite on, seems like it'd be a lot more fair of a comparison
yup yup, im compiling requests and plan on posting a short tomorrow, and ill be sure to include this!
can you compare the fps of the masked foliage with nanite turned off
see "Threat Interactive Drama Explained - Smart Poly" Jan 15, 2025
it's all about scaling and when it makes most sense to use it. it's like DLSS, 1080p vs 4k. you see the most benefit on 4, when it stretches the fps for the hz on your monitor.
@@DallasDrap Could you also display debug times for each steps of the rendering so we can see where the time is lost in each cases ?
Biggest issue with Nanite, Lumen and other fancy stuff is just the bad gaming experience.
PCs have huge variety of different machines and in my opinion, every action PC game should run 720p@60fps on Steam deck without any stuttering and should look good. It will require 9x more powerful GPU to make same running on 4k and that is then about highend machine.
We have not seen any Unreal Engine 5 title with Nanite that can handle that. Correct me if i'm wrong.
Thank you brother, I've watched a handful of course and tutorials but barely any them covers the Topic of Optimization, Most of them just focuses on how to make things look good without considering what it cost them
Looking forward for you future content man
I wish I could find official UE tutorials certified by Epic. That way, I know I am learning the truth and best practices, instead of random TH-camrs that I have trouble knowing who to trust.
best comment
One of the best videos on how to utilize Nanite foliage I have seen. Great job!
One thing that always irks me with Unreal Engine videos on TH-cam is when I see the old Unreal Engine logo being used. ;)
I thought Nanite would cause higher VRAM usage, and it definitely seems to be a challenge for players with lower-end GPUs. With the majority of players still on 8GB (35%) or even 6GB (12%), it's becoming a big issue. Nanite's detailed geometry and virtualized assets push VRAM demands higher, which can lead to performance issues, especially for users on older or mid-range GPUs. Right now, only 25% of players have more than 8GB, so it’s a tricky situation for a lot of gamers. Hopefully, future optimizations can help balance this out!
That's definitely not true. What causes higher Vram usage are 8-4k textures that come with Nanite models if you download them from MegaScans. Nanite models are actually lighter on memory (better compression) and they constantly stream in and out meshes or even parts of the meshes that aren't needed (with culling).
Same! And there are workflows to consolidate GPU usage further, but thats one of the reasons why in the video i mention how this workflow isnt for everyone or every project. But this is an important note! One thing i love about the comments is seeing all the details you all remind me i left out, and i mean that sincerely! It helps me to remember and add talking points to future videos
The joke of nanites is that there shouldn't be that many of them on stage for everything to work well. About 100? 200? No more.
Nanints work well when there are 10-20 objects that are duplicated 10,000 times. Not when there are 10,000 unique objects on the scene.
We need to beat the hands of the level designers for wanting to use all 100% of the assets made in one scene.
@@YarGolubev exactly haha thats another note i was gonna be making in a future video, but yeah, the best way to use it is focus on less objects that have a lot of customization as opposed to a bunch of uniques. Maybe thatll change one day, but not today
Reuse assets. add complex shaders. to mask identical cassettes. Add macrovariation and microdetalization. Transform and scale.
(By the way, the question is, do epics want to add the possibility of warp morph for nanite assets? It would make life easier.)
Epic Games think that the best way to use their engine is to create PCG. But unfortunately, PCG is not fun yet. For casual users geometric nodes need to be simplified. It is necessary to make macros from nodes - that it would be enough for the user to connect 2-3 nanite assets and add some nunbers of rules for connecting them.
Great video. I was really confused with the use cases of Nanite and thanks for clarifying. I would love a tutorial/explanation for how you would optimize these kinds of meshes for games, specifically the techniques you used in your past and current projects.
Ngl I was at first weirded out by the stache and quirky behaviour in the beginning, but once you locked in and started pouring quality info I got convinced that you might just know what you're talking about. Looking forward to the future videos explaining how to work with nanite. Subscribed.
Thank you. people like you who do these kind of videos save so many projects from being abandoned. I thought its not worth it to work in unreal engine with all its unoptimized core features. But you really helped get past that misconception and show UE5 features in a new light. I think the community would greatly appreciate a series on high level optimization that most people using the engine done know about.
Really really helpful video mate! More people should see it, as it debunks a lot of misconceptions about nanite!
Keep up the good work my friend!
I feel like we are also largely living in a time where people are conditioned to approach things from a negative and critical angle. At minimum I would say that youtube ends up pushing more of those negative titles into the algorithm which seems to have people inventing things to be upset about for content. It could just be because people are more likely to engage with negativity but I would really like to see some course correction on this one because its exhausting.
I would too, and if im being honest, I kinda hate making more of the "clickbait" type thumbnails like this one, however, its what youtube wants right now if you wanna get your videos out :[
Also yeah, there is a lot of negativity out there, im hoping though this video can be somewhat of a bait n switch for those looking for unreal engine hate haha
@@DallasDrap I don't think that anyone really 'hate' unreal.
the issue is the users and the non-skilled developers that use it.
the same issue that unity had in the past.
it lowered the bar of entry for new developers and a lot of shity and ugly games made because of these.
and its was never unity to blame.
the same issue is now with unreal.
@@rossb5788 I see a lot of hate, but it's usually from gamers that experience badly optimized games or devs that rather blame the engine than their lack of knowledge on this subject. I mean, you can spot them in the other recent Dallas' videos.
While I agree with the negative sentiments for the sake of contents, I think the critical ones should stay.
On the contrary, we have so much “feelings” above facts in this generation… we could use 100x more skepticism in society
This right here made me want to test it myself. Questions:
What's the screen resolution?
What are your PC specs?
Great video, looking forward to one on Lumen.
Screen percentage was 68 for both, basically the default under high settings and im using a 4080. Thats why i did demonstrations for both as ive gotten the "no wonder you have high frame rates" comments, however the bigger point moreso is the difference in performance between the two.
I should also probably lay out my specs in the description or mention them in my next video
@@DallasDrap It would help if you tell us the render resolution to get an idea of how the framerates you're showing correlate to similar real-world games in use today. While I agree in this video it's not critical as long as you keep the resolution the same and vary the parameters to show the framerate differences, the degree to which those framerates change with differing things like Nanite vs no-Nanite will be affected by the render resolution as you can start to introduce confounding effects like CPU or GPU bottlenecking which can artificially cap framerates at either end.
I'm on 2080ti as a developer, and I never was able to get decent framerate using nanite (1440p). Now I have a case study I can follow but still, I'm quite sceptic. Going to DX12 from DX11 results in ~20% FPS drop. And I do not believe DLSS bandage really fixes that. I don't like the idea. I do understand, that nanite and Lumen are meant for "next gen', but if next gen needs to rely on DLSS and Frame Gen I believe something is wrong. Still, great video, looking forward for more, gonna check it all out muself. Thanks.
Thanks for such a great video, you really opened my eyes to some details I missed on the whole UE5 discussion. Keep up the great explanations I Look forward to seeing more!
Thanks for making this video. My biggest issue with current UE5 games is either smearing on movement or ... this snowflake-like effect (especially on foliage), the perfect example is at 13:18 (focus on foliage) but imagine seeing it in the actual game. Is there anything I can watch/read to understand more how to fix this? Also, did I understand nanite right? -- In the past, people used low-polly models and always drew everything (as long as it can be on screen and distance settings allow) with a big focus on opaque/masked textures. Nanite is focused more on directly drawing what you SHOULD see on screen. Lets say there is an object behind a tree. Nanite would be focused on drawing individual "pixels" of an object, while previous impl. would draw a whole object on your screen even if it's not fully visible.
What a fantastic wrap up.
I am at the point of re-creating my environmentals.
I did a study where I made (masked) trees, grass, bushes, ect. I would say high poly. I got good results.
Then I massively reduced the polygon count, my fps only slightly improved.
After seeing this (and seeing the speed-tree bit(I also have)), I am massively interested in your cases and further videos!
Specifically, if my Plantain leaf has a hole, Sounds like i need to cut it out of the model itself. Or how tight should the model be against the material cutout, I think i did see a horizontal grass blade i recognized from Quixel, where the bottom of it was all flattened. This should be fun to figure out.
Thank you so much for the break down (and mention of why I should trust you).
this sounds like problems i used to see with Godot, people complaining about how something works without actually looking at how the method was designed to run.
Hey! Fellow Unreal Dev here, loved the video. I think it's really good to see some positivity about the engine and another person outside of Epic mentioning how all of UE5s rendering features need to be used properly and together in order to get the best results. I'm a lighter but am very much looking forward to seeing your future videos to learn more about proper nanite asset creation!
Good video, but you gotta share the hardware you're getting these frame rates in. Because a big issue with Unreal games is that most of them these days seem to require expensive hardware that most people don't have, contrary to games made with classical practices in other engines that give similar levels of fidelity (even if it's a little less, and yet the performance is great). At least comparing the hardware can give us an idea on the performance of Nanite and Unreal in general.
There's been a few comments asking about what's in his computer, it will be included in the near future.
I can't thank you enough for this video! 🙏 I'm about to graduate with a bachelor's degree in computer science and interactive technology and I can tell you speak the truth from experience while others state their opinions. 🥳
Great vid
😊 thank you greatly for supporting Dallas educational endeavors! That means allot!
you didnt have to! But i am very thankful you did. I appreciate the support my friend!
Did you watch the recent Epic GDC talk that specifically covers Nanite foliage and over draw and ongoing development in optimisations and solutions to known issues?
i think they did something very similar too
Thanks!
You're too kind~! love to see the support.
You're too kind! Thank you!! More content coming soon. Working hard on making the nanite tutorial something yall will find exciting and informative
Im very interested to hear about the proper workflow with nanite folliage and enviorement, thank you for this video
Good vid - thanks.
I was going to ask if there are any resources on how to do the aforementioned or using something like speed tree to do it, but then you said you were doing one lol. Looking forward to it 😎.
I’ve found it difficult learning it, when buying foliage off market places etc, as they are usually quite high poly and heavily masked. One feature that has been helping me a bit, and not sure if it came in with 5.4 or 5.5 (or earlier) is the “pixel programmeable disable distance” for nanite foliage using WPO. Which essentially turns off the masking. So it doesn’t work for all meshes and cards but has helped for a few when at a distance as the change is not noticeable.
One of the other things that’s been causing me issues and not sure if its normal or it’s just instancing in general (with TSR), as I’ve found it’s the same with non-nanite foliage spawners, is that when using simple wind the created motion vectors are very expensive. So turning off motion vector creation for meshes with static WPO helps.
I love comments like these, please ask and yee shall receive, I believe that speed tree is one of the many other programs Dallas wants to cover in his future videos.
Thank you for your feedback~ 😊
Great video! More of these please 😀
I'm guessing the reason a lot of small devs use a simple nanite retool will be because all the tutorial videos mention it. Due to the grass noise bug, I watched about two dozen videos on this topic and only one mentioned remaking the textures from masks to opaque, but the result was a very strange grass geometry, and thanks to your video, I now know why! 😊
Thanks for the video! BTW, can you explain why in STALKER 2 trees just pops out out of nowhere? Don't they use nanite? How you can achieve that level of LOD horribleness?
I really love your videos, you explained really well questions that i asked long time ago. This is reason why I never got any decent framerate from Nanite and now i got answers. You really did great jbo explaining it.
Thank you for making this video. We've been developing in UE5 since EA and it's been a long and bumpy road, but things have been turning around in the last fes months as we learn how to optimize and dev for Nanite.
I have 2 questions/concerns currently for Nanite Foliage that maybe you can address in your next video. :)
-Wind and Interaction. How will foliage animate? will it be able to with out smearing?
-Memory size. Millions of poly on screen doesn't effect FPS but it does mean massive asset files. We have to reduce nanite meshes through out the game just to stay in a reasonable memory budget. Im assuming high poly pine trees could potentially be 10-100mb or even more. This adds up very quickly if every asset in the game is equally large. Most consumer-level GPUs will max out Vram and crash.
Great video that explains alot of the nitty gritty details of nanite, but it has to be acknowledged that broader awareness of the sub-optimal image quality in games and optimizations developers now perform, and corresponding videos like this which inform them how to fix them, would not have kicked off without channels like threat interactive to get everyone fired up on the topic and provide a deeper-than-surface-level explanation of some lacking aspects of modern games.
Like an art teacher once told me "its not because what they did was special, its because they did it first."
Great explanations about the technical details. The issue I see with drawing foliage as an opaque mesh is, you cannot do light transmission anymore. And I think people have gotten used to that, when it comes to the look of high quality foliage in games.. I guess that's why to me personally, the visuals of the old workflow look slightly better. Most real leaves on real trees usually do transmit light, which becomes impossible to achieve when rendering everything as opaque..
Very informative, thanks for the video! - I'm making a small Unreal5 Demo and I have been struggling to understand the Nanite topic. I have to give a try replacing my masked grass with the full modeled one. Waiting for the detailed video on how to do it properly!
After being slightly demotivated last few weeks from reading and hearing about all the bad parts and future of unreal engine, this really made my day!
I was even having thoughts of returning to unity. Im looking forward to more content and videos from you, well deserved sub!🎉
Thank you for the well thought out, well made video. Idt some people realize how destructive just slinging mud can be.
Great vid. What nanite foliage packs are you using? One of the other big hurdles these days is finding foliage packs on FAB that are actually fully modeled out geo for Nanite the way you've shown. I've noticed a lot of 'nanite ready' foliage packs on the marketplace actually still use masked materials, but because the creator can 'convert them to nanite with the click of a button' as you've shown, they misinterpret their own assets as being nanite ready.
Yeah same haha so the grass i made, and the trees are from this pack www.fab.com/listings/09ad5f14-aada-400f-af9f-a42610edf760
That being said, even those trees by default have masked materials but you can just change that to opaque and it wont really make any visual difference
Great stuff Dallas, nice to see you uploading again
it was quite a long break. ^^;
I tried to use nanite on some industrial equipment models. It didn't work very well, so I went back to LODs. It seems that nanite is not well-suited to inorganic shapes like machinery. Even modeling sidewalks with things like cracks and expansion joints came out really bad. Nanite was reducing the geometry prematurely and it looked terrible.
I use nanite for hard surface, it's a game changer. probably the best use case, you just model mid-poly with unlimited details, unwrap it and that's your final mesh. what was wrong visually, any screenshots?
I'd suggest tweaking your mesh settings in Unreal, maybe enable preserve area or play with the option I can't remember the name of, it's in the settings
this is the content that threat interactive could have been making, if the focus was a bit less on attacking developers and epic games. Great stuff and im happy to see this more technical breakdown of the problem
This is still incredibly wrong, this video is terribly misleading. "Nanite is now the industry standard for videogames" is a straight up lie, and a very harmful one to the folks which this video is directed at (Newcomer devs and non-devs that are interested in the game industry). While this person might not be as malicious as Threat Interactive with his grifting plan, its still straight up misleading.
@@naruka777 through the lens of unreal engine development, it is all solid info. I don't see why an uninformed layman would run into this content without having at least a bit of an idea what they are doing already
True.
If Nanite is industry standard, why Nanite is not implemented on game engines?
I rarely enable all notifications for a TH-camr's videos, but this video had me hit it. You're like, 1 of 3, out of 500+ subs. Can't wait to see your next video
This is very interesting. Thank you for bringing this up. I wonder why didn't Epic add a warning/error message that tells users to use fully modelled opaque geometry in place of alpha-clipped/blended cards. It seems to be such a simple thing. When Nanite is applied to a material with transparency - show warning that Nanite will perform poorly unless the geometry is fully opaque.
Even if this works perfectly though - this tech and pipeline is quite specific and only makes sense for top-budget productions that aim for maximum fidelity, and the hardware demands of such a solution are still going to be very high.
Using film-grade models in games to me is just insanity, because all of this geometry needs to be authored and shipped to users. Then it needs to be streamed from disk at runtime.
As amazing as the visual results can be, this is still quite specific. So it seems 90% of the games don't want to use Nanite anyway, because unless they go this film-grade geometry route, it's only going to make things slower and heavier for them.
Adopting such a workflow for large open worlds is insane, because then you're going to be shipping 200-500 GB packages, and games are going to need a dedicated SSD to run. Not to mention download times.
This is really forward-thinking technology but to me it's way ahead of it's time, where storage is not getting that much cheaper fast enough.
Imagine being able to only have 2-3 games installed on your 1TB NVMe SSD, each one taking a week to download.
I still think Nanite is really meant for film production and it's usage in games is quite experimental.
Not to mention the cost of having your artist model every flipping needle on the pine trees.
That means more and more assets will have to be bought from assets stores, which means more and more games will look alike.
Converging on common film-like fidelity of games seemed exciting to me 10 years ago, but as we're getting closer to it I realize that there's only so much fun in playing games that actually go there.
Turns out art direction and style in game graphics has much more impact that I have appreciated.
Finally someone with common sense on gamedev youtube 😂 The engine is offered "as-is"!! It's up to you to make a game with it, not the other way around!
Hey as an Unreal dev - a UE programmer with over 15 years of experience now, but focusing mostly outside of rendering (architecture, multiplayer, optimization, porting) - the hardest part of UE5 is that there is SO MUCH new stuff. And hearing your showcase of the trees, Im finding some things in common. So a senior programmer on UE4 used to focus on the well understood state of the engine, improving upon it, where necessary. You could focus on architecture, implementation of more complex and finnicky details and guiding juniors all at the same time. However, with UE5 there is Mass, Iris, Mover 2.0 etc. etc. that each require considerable learning period even for a senior programmer. We dont have that much time to be the sanity police the project, we dont have that much time to go over work of juniors, we dont have enough time to fine tune settings, we dont have enough time to do the important things, that we would otherwise do. And stake holders only hear how cool everything is from Epic (thats not really the case for the studio I work with though). Some complaints about UE5 that are being highlighted about it are true, however, and Epic has exacerbated the issue, but they have been part of the UE experience for a LONG time. I know a very senior rendering programmer and he has hated rendering pipeline of UE for a long time and that has nothing to do with Nanite or Lumen, just the rigidness. For a more general example whats often lacking with new generation releases is stability and completion state of features and feature parity, because the actual projects from Epic drive whats put into the the engine. They were also putting too much focus on new features, that get finished much later down the line, and sometimes you cant even rely on it. Ask a senior about UE3 and UE4 early major versions (Distance Field Shadows :D). Epic is trying to have their cake and eat it with new complex features, defaults that push new features, but are sensitive to correct applications AND pushing itself into the ex-Unity territory for a more general dev base.
In other words: Mass is AWESOME, but you have to understand it and write for it from the ground up. Iris seems like a much needed rework of the VERY dated replication layer. Ditto for Mover 2.0. But seniors dont get enough time to douse all the fires coming from so many new things. Finally, wider user base means more smoke from the same fires, especially, when so many new people scoff at the best practice of understanding and working with UE code: READ THE DAMN CODE. No good, big project can be ever understood by reading the documentation. Documentation of any project like that gives you like 10-20% and youd die from boredom sooner.
OMG thank you! Someone with a sensible take. I keep trying to tell all these people shilling for unreal, but they don't get it.
If I have to do something like write my own render passes in mobile LDR simply because things don't work, that's a problem.
And even when I go to do something like that, you find that buffers simply are not being populated by unreal when they are supposed to be.
So, what good is the rendering pipeline when you need to throw it out and write all this stuff yourself?
Don't even get me started about the state of chaos, sheesh!
@lifeartstudios6207 I still consider myself an Unreal shill though, because it still does a lot of things right. I just don't have rose tinted glasses about and don't think that every aspect of Unreal is at the same level of quality. Good that I didn't mention BP, that's when you would end up seeing me as a total hater :D.
@Blackerer I do too, I would rather be using Unreal than anything else. Problem is I'm at the point where I'm basically writing my own game engine because unreal is such a problem to fix.
Maybe if they gave me a single stable engine version I could roll with just modifying my own fork of that, but because I'm constantly waiting for them to bring changes down the pipeline I can't exactly make changes on my end that might be really hard to update with theirs.
@@lifeartstudios Yeh I can imagine that that's how it is on mobile.
Well said my guy! Been an Engineer (Now Lead) soon to hit 2 decades with Unreal. I have a video that goes over exactly this point titled your "not" doing it wrong. UE5 has failed to deliver on the promise of what they marketed the tool to be (This doesn't mean I don't appreciate the intention or still love unreal engine). A general purpose engine that will save studios money and reduce dev cost and cycle time.... and you outlined just about everything I also stated which was missing from the video. "The actual issue facing the 9th gen transition and the adoption of UE5". I will also state that Dallas popped by and left a comment and was very supportive of a different viewpoint from maybe a different segment of the industry and welcomed the feedback and conversation. Kudos really! As a studio I can state confidently that the issue internally has been the requirements to hit 8th gen and 9th gen hardware / gpus while dealing with holding your mouth just right for software rasterization while also upsetting UE5 for LOD fallback and dealing with WPO, Material switching and multiple RHIs as well as every system seeming to be busted (both newer and older optimization tools) along the way. The truth is UE5 has made things more difficult and expanded scope and cost.... not the other way around. He outlines alot of this in his video without really going into the tradeoffs or appears not to really understand the actual impact on a game studio's project scope with an example being "You want to be using full modeled geometry" ... Take a step back and really digest the requirements and request here. The time allocation, how this impacts previous gen hardware or lower end gpus you still NEED (its not a want if you want to survive) to support, how do you handle fallback for 8th gen? There is a domino effect for everything that is just simply explained away like "your just wrong".... Modeling time and Engineering time for BOTH methods. I keep going back to "when you know you know" but this is much deeper than alot of these surface level "just do this" type of explanations.
What’s your hardware specification? Would want to know if it still holds 60fps on lower hardware
depends what the lower hardware is, on a 10series, maybe not, at least not at max settings without DLSS or something. I'm on a 4080, and we've tested it down to a 2070 and it runs well. Our game is also still very early on which is also an important note. By the time the full game is released, the gtx cards will be like 10+ years old
@@DallasDrap also, depends on resolution. it's bit crazy than some expect 4k@60 from 3060.
@@DallasDrap GTX cards you say.
What about RX cards then?
Some people are kinda broke, other live in third-world countries, others still are both.
@@DallasDrap 80 FPS (or 50 in game) on a 4080 is kinda terrible isn't it? You're forcing regular people to use DLSS to have a playable game, which makes image quality suffer a lot.
@@SonicTheCat I see what you're saying, but currently there are still plenty of optimizations to go, and most of that has been focused on our dungeon system for its launch here in the next few months (will be a releasing a demo featuring the dungeon system) and that runs at about 80fps on a 2070 on max settings, we pretty much just need to use the tools we've created for automating the optimization process on the rest of the environments like the town there for example
As a beginner this was good to hear. I've heard the haters, but figured Epic wasn't stupid and that this new feature probably had more to it than just slap it on and call it a day. Your use cases made it clear when nanite is advantageous, instead of just saying "when you have a lot of geometry" in a scene.
Subbed and can't wait for your upcoming videos!
We're currently using a mix of nanite-full-mesh foliage and cutout foliage, because it's tricky to get the specific "look" we want with the full mesh approach. And trees moving in the wind are super performance heavy, which I'm told Epic knows about and should be working on. But it doesn't help us NOW, when we need it working. So we did a bypass in the engine and had to do our own "faked" lighting and shadows on trees. (I think Epic recommended cutting WPO wind at a certain distance and possibly using billboards in further distance, but for our use case that didn't look great.)
Thank you for the explanation, this will make my current 20 fps experience more pleasant now that I know it's not the engine's fault.
I'm also excited for the devs to properly use these awesome features so I can enjoy the full 40fps experience instead of the current 20fps
Wow, thanks for that review. Looking forward to your Nanite foliage technique tut. Can't wait to start modeling real trees, not that billboard bs, I've been doing for 20 years.
The exact same setting, yet it looks SOOOOOO much better and more realistic, while having better performance.
Tho I'm not a foliage artist, and I have barely even started modeling assets, so I don't know if this is actually easier or harder for the artist to create.
Very interesting video, thank you for the explanation.
I appreciate your message and coverage however there is a missed opportunity and one it seems the video completely misses… the point. Nanite, vsm and lumen are marketed and offered as a workflow to reduce development time and save on both performance and dev cycle time. However this “goal” has been completely unrealized. No studios can afford to isolate themselves to high end pc and still to this day target multiple platforms. We simply cannot ignore traditional optimization tools and methods. The lift here is NEEDING to encompass BOTH to hit older hardware. I’m not speaking for everyone however this is and has been the case for most studios that have fully adopted UE5. The issue isn’t how these things work it’s the contradictory gymnastics the engine has introduced to be valuable or viable to be the screwdriver to the screw that UE4 was targeting the majority of its generations hardware. The other thing this video completely fails to mention is how many studios have had to take it upon themselves to fix said features, memory leaks, broken older technologies (light baking, landscape tools, chaos) along the way 5.1-5.4. I appreciate your approach and information your sharing however most studios/devs worth their weight in salt know this information. Knowing the newer workflow vs the old does absolutely nothing when its the very gymnastics that you cover that has actually been counter productive to hitting targets and performance because so many traditional methods (precomputed visibility, light baking and the physics thread) have had some major issue in conjunction with the newer tech simply not being up to task at the time of adoption for most of these studios. I don't want to come off the wrong way but simply telling everyone they "ARE DOING IT WRONG" swings so far in the opposite direction of Treat Interactive that I can't really get on board with take on things either..... When you know you know.
Another point here: using full geometry for foliage results in millions of vertices. If you have expensive wind animations with a lot of Pivot Painter hierarchy, that is going to hurt. It also does not scale well because, unlike rasterization, which benefits from culling, you actually need to perform WPO on each vertex. This is because you cannot determine if a vertex is occluded until you calculate its final position. I would still advise against using Nanite for trees (though it’s fine for grass) and recommend going the classic route with billboards if you are not AAA.
I've just finished my testing because I thought, just like you, that WPO would be an issue. My results are pretty clear, if you don't have VSM invalidations, then WPO is basically nothing... I populated a forest with 14k trees, with PP2, tested with both masked Nanite and Full geo Nanite, geo Nanite performed about 1.5x better than masked Nanite. I haven't tested without Nanite at all because I need it in my project for tesselation, and it's usually recommended to have Nanite on everything if you use it at all.
I should note that I used the WPO disable distance to disable WPO after about 50m from the camera, and I also tried using the Pixel Programmable disable distance at the same 50m on the masked nanite trees and it didn't help at all.
Great video! =D
This is exactly the kind of information I've been looking for, and it's very hard to find.
I have a few questions:
How do Nanite-optimized games compare to the "old pipeline"? Do we see both fps increase along with fidelity?
Do we see improvements in FPS and fidelity across all hardware levels with nanite? Low, mid, and high specs? How does this compare to the old pipeline?
Why should we use the unreal-optimized pipeline? What things make it better or worse compared to the "old pipeline"?
As a solo dev looking to transition from Unity to Unreal, I would love to see a video that walks through the Unreal-optimized pipeline step by step, to take full advantages of all its tools.
And also a video that explains what the pros and drawbacks of tools like nanite, mega-lights and lumen are. To get a better idea if those tools are for me or not.
Excellent! Looking forward to more videos!
We can't blame folks for using Nanite "wrong", there wasn't any solid public information on it for years and everyone has just been figuring it out on their own. We also see Nanite improving pretty drastically from 5.0, so we're developing against a moving target (more than other 'stabilized' features).
Edit: That said, Nanite still lacks full integration for some systems and tricks we've used for many years and I keep finding more.
THE Tom Looman entered the chat! Yay!
ah man, not you too Tom
@@lifeartstudios what's wrong mate?
Are you planning to make video analysis of performance of UE5 games with terrible performance with explanations and probably even showing possible fixes? I'm specifically interested in Project Borealis Prologue, only way to run it in 60 fps is to lower all settings down and use dlss+frame generation
Thank you for explanation. Can you also tell what needs to be switched off if I don't want to use these features? I'm mostly going to use UE audio engine I don't really interested in making a realistic game.
Maybe you'll say later in the video, but i don't want to forget. How do I know my foliage is nanite foliage? I'm using the megascans stuff, but did the trick with the right click convert to nanite thing.
Awsome video! I'm pretty new to Unreal but this was easy to understand and learn from.
That's why I love Dallas teaching methods. He's a well full of information.
Hello mr. As a starting dev in unreal (and recently learnt SOME blender things) can i ask you if there is any form of documentation/guides on how to implement nanite and make these complex models for it to use? If I understood correctly the workflow differs at the very beginning of creating project so my guess the entire process feels different? Thank you for the rant.
I saw your TI video and thought it was good but this video made me sub. This is god tier information that I don’t think I’ve read or heard anywhere else. The documentation for UE5 is comically terrible.
I use the UE Editor to create digital landscape art for no other reason than tickle the creative side of my brain.
Great video, keep it up 🤜🤛
FINALLY! Some information I can get behind... as only a 1 year "dev" I currently have a combination of LOD's and some Nanite... Maybe that's "wrong" to use both? But I did tests on pretty much everything I added to scenes and I found some things worked better with Nanite on, and some better with it off. Now I know why! THANK YOU! I also went down the road [you mentioned] of removing as many triangles from foliage etc etc... As a solo dev I have used a fair amount of assets, but done a lot of work on customizing textures and where possible mesh's. Now I'm going to have to seriously consider modelling my own trees in the Nanite way to take advantage of that.... Anyway... more importantly... videos like this are SOOOO valuable and I appreciate it a ton! As a self taught guy, you don't know what you don't know... a lot of what I know is through extensive testing. So keep these coming please. I would love to know somebody who has the inside track, and videos like this are the next best thing. Information like this is hard to find, even on Epics forum where there seem to be a lot of people with opinions not based on reality.
Great video. I was suspicious at first, but after watching the whole thing, great job.
Thanks for not shouting at the screen about how "bad" a great free to use tool is, and the people using it.
Also thanks for showing this, as i have made the masked mistake myself.
Now i can optimize even more!
My game currently is already smooth, but anything extra i can do is great.
Explanation plus workable solution over complaint = wisdom.
I hope you subscribe for more juicy tips~ I know there's not enough educational material out there, but this channels dedicated to informative and solutions. 😊
bro you really get mad from that guy, and I am loving it in a good way :)
I have no clue about optimization, just trying to do my first game about virtual museum and find this information golden for my project :)
lol, same. ^^
I was explaining this to another dev friend of mine, but the problem is people will watch that dudes videos, believe it all to be fact, get a job in the industry, end up working on a project with me and i'll end up spending half my time course correcting them instead of getting work done lol
@@DallasDrap I feel your pain man. It's like this in the hardware space too. People can latch on to the wrong information about something from people that just present it confidently, and we have to spend more time un-teaching them that stuff than we do actually working with them on the project.
The biggest argument that the Threat Interactive guy and others have that I understand is the image quality with TSR, TAA, DLAA, DLSS that is almost necessary with Lumen, Nanite. I personally am okay with some jagged edges and noise but devs nowadays are not even letting you disable TAA. I know 90% of people are okay with the temporal effects but I can not stand them. Great for screenshots but in movement it is really bad. Especially in UE4 & 5. As a part-time UE5 user I would like to see a video on solving the image quality and ghosting issue of UE5's AA options while maintaining good performance in a Nanite scene.
Note that TAA can actually be pretty good. Exact implementation and tuning define how bad ghosting is. There's documentation for controlling ghosting, and you can dig far deeper with the source as well.
Thanks for the suggestion! Ill be making a video about that exact issue. To sum it up though here as you wait, a lot of that can be explained with the low frame rates + low screen percentage + low samples = ghosting issues, blurred aliasing and all those problems. The answer to all of which essentially is optimization. If, for example you have a scene running at 90fps this means the frames arent going to have any noticeable stutter or drops which means frame generation wont smear to make it less noticeable, it will also allow for higher samples as well.
Basically if the devs fix the optimization issues theyll fix the AA issues
Main purpose of TAA is not exactly only to smooth out jagged edges, you can think of TAA as temporal supesampling.
A lot of modern rendering techniques require supersampling to actually look good (from global illumination, volumetrics, reflection, RT, even soft shadows, etc... just to name a few) and they used to be prohibitively expensive for realtime rendering at a sample rate high enough to look good.
Here is where TAA comes in, TAA achieves supersampling through time (temporally). TAA accumulates information from previous frames with different recombination techniques of current and past information, since the information keeps accumulating it achieves almost the exact same effect as supersampling.
TAA intentionally renders each frame with a subpixel jitter applied, this is done to gather more information around each pixel.
In other words TAA allows the prohibitive cost of many rendering effects to be amortized over multiple frames, TAA is not "lazy devs", TAA is an optimization technique.
The options are:
- Use TAA
- Ditch TAA and revert the state of graphics at least 10 years into the past (forget GI, nice soft shadows, reflections, etc...)
- Ditch TAA and use actual supersampling which will make modern games magnitudes more expensive to run while keeping the fidelity
- Allow players to disable TAA if they want to, the image will look worse but be more stable
And TAA has issues, everyone is aware of them, but there are tradeoffs.
As many issues as it has it has equally as many benefits.
TAA uses motion vectors to basically calculate how each pixel moved from the previous frame to the current... but motion vectors are notoriously difficult to get right with particles, transparent surfaces, dynamic materials, etc...
Most artifacting from TAA comes from missing or incorrect motion vectors.
There is work being done to make all this better, everyone is aware of the issues, but it's not something that everyone can just ditch because it does have many actual benefits.
@@DallasDrap Exactly right, and to give an example; let's take Red Dead Redemption 2, if I'm running it on optimized graphical settings, which my pc can handle at ~60 fps, I won't notice any TAA problems like ghosting, but if I try bumping my settings to the max which my GTX 1060 can't handle very well, I'll be running the game on ~30 fps, and guess what? I'll start noticing ghosting and shimmering, particularly on foliage and trees as they're waving around. TAA works great, but first make sure your PC can handle the game at reasonable fps.
Edit: Ghosting can also be due to your own monitor, some monitors have poor reaction time in comparison to what is happening on screen, so they'll generate ghosting, it particularly happens on VA panels.
Most developers just enable Temporal AA without changing anything to use it properly. UE has flags you can set per actor/material to make the TAA pass behave differently and cause less ghosting for example. Most developers don't even know this. There is also the TSR debug view that nobody uses unfortunatly.
TAA itself isn't the problem, it's how the developer use it and optimise it that is the problem.
Well as i get it for now, we are in some sort of a transitional period between development pipelines, or maybe it's just separated pipeline that applies only for photo-realistic graphics at all. For me DLSS\DLAA\Raytracing and maybe even a frame generation is a future, which, no matter how anyone see it, will become a new standart. Even if we take your show case as example, i just can't estimate how long it will takes to recreate with traditional pipeline.
To be honest, first time when i saw your video about AA it seems off at that time, but hope you show more technical stuff like this. It's a lot more convincing
Thanks! Yeah, i dont think frame generation, DLSS and all that will be going away, especially the investment Nvidia for example has put into it. But yes, were in a transition period, and right now we're sorta at that peak of the transition. Where when UE5 first came out, we were all still learning it, and even now, i mean we learn new things every day but at least the important bits are becoming increasingly more understood and at an increasingly rapid rate.
And like i stated in this video, not every project is going to be using nanite foliage, its not for every project, however i just wanted to make videos like these to demonstrate if you are going to do it, at least do it right haha
Wow, that's a much more knowledgeable video on the topic than the one by that certain (in)famous creator that I happened to watch first. You are sharing your expertise with such composure and charisma. It's a pleasure to watch. I hope this video (and future tutorials) will be shared across game dev studios. Proper training with the tools, or rather the lack of it, is a huge problem in many industries and is often underestimated by "the management". This kind of video is a great way to share good practices; I'm looking forward to more.
On a different topic, what titles do UE5 features (like Nanite, Lumen, etc.) right? I played Remnant 2 and Fortnite and, as a gamer, I wasn't happy with the visuals-to-performance ratio for these games...
Fortnite
Black Myth Wukong, Silent Hill 2 remake, Tekken 8, Unrecord (the bodycam game that looks literally photoreal) and many others. Keep in mind games take many years to develop, especially to polish and get ideal performance. Games coming out in Ue5 right now have only had 2 years to use the engine (waaay shorter timeframe than what a typical AAA game usually takes to create), and new massive updates are constantly coming out for UE at the moment. You can port projects from UE 4 to 5 but seems to be a bit of a nightmare especially if you intend to make use of all the new features.
This is a very insightful video.
May I ask two questions?
First, how can I determine whether foliage uses a mask or not? Specifically, how can I analyze if a particular foliage is suitable for Nanite or not?
Second, which grass did you use in case 3? I really loved it! :D
To answer question one, you can look at the "Pixel Programmable" viewmode, anything red either uses masks, transluency or WPO if I remember correctly
Question 2 I'm not sure, I personally use MEKA assets for nanite ground foliage
@@azaelsergal Thanks man!
Hello, I have a question. what was with all the "artifacting" in example 4. I know it was raining but what caused all the windmill flashing and such?
Thank You for making this video! Kind and caring way you have.
One of the best video explaining why Nanite is such a big deal and how to properly use it. Thank you!!!
So you compared Nanite with masked meshes to Nanite with unmasked meshes. But you should have compared Nanite to classical LODs. Otherwise we don't know which is better for foliage. For example, Horizon Forbidden West uses a relatively high screen resolution and very highly detailed foliage with classical LODs on a base PS6. We haven't seen whether anything like that with is possible Nanite with Nanite foliage, even when unmasked.
base *PS5
Yeah im curious about that too. He also hasnt stated what hardware this was done on.
The first example is traditional grass and trees, which I'm sure had LODs. It ran at around 28-30 fps. However, I agree with your sentiment that I'd love to see two developers go head to head in a Nanite vs LOD challenge to see who can make the best performing scene using the same visuals.
@@JeffCraigTV Yeah but he had nanite enabled on them too, so it wasnt a fair comparisons at all
No such thing as masked or unmasked meshes. There are LOD based meshes and Nanite meshes. LOD based meshes use masked materials to fake the details and Nanite Meshes shouldn't use masked materials, Nanite meshes should do all the details with more geometry.
One of the most used masked materials is alpha mask for transparency and meshes behind transparent materials cannot be culled properly (optimization), which means that Nanite will overdraw too much. If opaque materials are used with Nanite, then Nanite can cull a lot of the geometry because all the pieces of the mesh are tiny and hidden behind the opaque geometry.
Thank you for breaking down and helping me understand
This sounds like a storage nightmare for games every vertex still has to be stored and read from storage
Yes, if you hate games that run at 14 fps on a 2000$ rig packaged in 500gb downloads, you're in for a treat because that's precisely what nanites is about.
But hey, at least some studio exec with no background in game development can say "our game has more polygons therefore it looks better than other games!"
yep. it makes sense from only one very narrow perspective.
@@naruka777what’s the game you are talking about? How many of them exist ?
Nanite is actually great at compression, and there are other areas you can optimize for storage space... You can save on normal maps, maybe use a displacement map on lower poly models. Nanite is actually not a problem in terms of disk size, except if you make really really specific things that it can't compress
One obvious thing why Nanite waste space and memory is everything need to be on high geometry because it works without textures. When using textures, high resolution textures are not needed every object.
Another thing is closeups. When using LODs, closeup versions can be loaded only when player pick object in hand in first person view or similar, controlled thing so they can save a lot of VRAM because there is no need to keep many closeup versions in VRAM.
A lot more digestible than that shapiro guy rattling off his script. I could not follow what TI was saying, but this was super easy to follow and I can see the point you're making. Thanks for the content.
1st of all excellent presentation that doesn't get way too technical but gets the point across👏👏👏
2nd of all you want to tell me that if I properly use a tool, then things will be better? Preposterous! A certain someone along with others told me otherwise!
Jokes aside this whole thing especially from ppl without credentials, and by credentials I mean ppl actively in the dev process, reminds me of when we were kids and we were seeing TV games like Takeshi's castle etc, and we were thinking to ourselves I can do this sooo much better and faster or whatever.
Pointing fingers etc etc is easy, making solutions is harder.
Keep up the good work Dallas!
this is really informative! however, i think a lot of people coming into the comments are going to be confused by the title as this is mainly about nanite, while a lot of gamers' concerns that have been stoked by channels like TI are centered around anti-aliasing/upsampling and temporal artifacts.
i don't have any experience in development in UE but have struggled with bad AA implementation in a lot of games on the engine, and i hope artifacts and blurriness continue to be reduced with new tech, so i was wondering if you had any plans for videos on this issue
Another great video. This is how it’s done. 🎉
This is most appreciated. If the naysayers will be honest and apply what you are presenting to their process, then perhaps they may rethink their position. Assuming that they are open to the notion that their initial assumptions are wrong.
What I really want toknow is, why hasn't Epic directly come out and explained "This is what you need to be doing to get proper results with Nanite..."? If they would quit leaving these core details out of general presentation, then perhaps there would be fewer nay-sayers. I will admit I haven't watched every single presentation they've done, but at the same time, I haven't heard them once come out and say "You need to train yourself to do things totally different from what you've learned before now.
If Nanite doesn't like masked textures, then perhaps when converting a mesh to Nanite, it should pop up a warning:
"This object is using masked textures which can negatively impact performance. Proceed?" [yes] [no] [hide warning]
The only thing that would need to change is a check to see if textures assigned to the model are masked before either completing the conversion or presenting the warning.
I'm a bit confused. In Unreal Engine's presentation "Nanite for Artists GDC 2024" they specifically use this as an example of how not to do it. Nanite wants to retain the boundary of the mesh. The shape and size of the meshes are therefore important. The boundary is quite large on a pine tree, while the area of the silhouette is quite small. Nanite can't reduce the polygons on a pine tree without compromising the boundary, which it won't to and you are therefore left with a to large mesh at far distances. In their presentation Unreal Engine is using a combination of LOD with nanite and billboards for foliage using PCG. Quite bizarrely complex, with the reasoning being that they haven't figure out how to solve nanite foliage yet
I think what they showed was not about performance, but about reducing memory usage.
If a developer uses Unreal engine they should be MANDATORY trainings to learn how to use it properly. Stalker 2 is such a [...] because of devs not working with it as it should. It has HUGE tree pop ins, fps issues, horrible noise in the lightning...........
Currently in the process of creating my own full geometry foliage. There are not many tutorials covering this full workflow so looking forward to watching yours. Thank you for what you do and keep up your great work!
What about file size and memory constraints? I've been using unreal for years and it's always been hard to find a good balance, especially for large foliage such as trees that aren't half a gig each.
Two things: yes, full geo models take up more space, but you are also ditching the alpha channel (which is usually in the Albedo texture) which DOUBLES the size of the texture. And, as you probably know, textures take up most of the space in a build anyway.
My suggestion is to reduce the texture size, especially Normal maps (which can be half the size of Albedo) and ORM/ARM/MRO (which can be a quarter). Channel packing is highly recommended.
Also remember that Nanite meshes take up less space than classic meshes.
Second thing: storage nowadays is very cheap, even for NVMe. I wouldn't bother too much to keep it drastically down, especially if you gain that much performance. This is not an excuse to avoid optimizing those textures (because Vram is still limited in GPUs) but at the same time is not a big deal as it used to be.
@@OverJumpRallythe alpha channel doesn't "double the size of a texture" 🤨 in an RGBA8888 image the alpha channel is 1/4 of the image size. That being said for foliage specifically with nanite you probably don't even need an albedo, normal, OR roughness map if your grass mesh is using thousands of triangles, you could just color the mesh with vertex colors and use the vertex alpha for roughness, that would definitely offset the increased model size somewhat AND reduce vram usage because there would be fewer textures
@@jlewwis1995almost nobody uses uncompressed textures for environment 3d art assets at least last 20+ years. For compressed tex 2x size for tex with 8bit alpha is correct
@@jlewwis1995 Wrong, the moment you enable the alpha channel in a texture it doubles its size. Try it yourself. It doesn't matter if it's just one channel out of 4.
And, yeah, you need Albedo, Normal and Roughness if you are aiming for photorealism. You also need that for SSS.
@OverJumpRally Well this video is about foliage and for stuff like foliage that's mostly a single color or 2 you could easily just paint the color onto the vertices if you're making it for nanite since you're going to be making it with a lot of triangles anyway so might as well use them, like how much color variation is there on a leaf or a blade of grass that you couldnt just select all the vertices and do shift + k in blender to turn them all a green color then hand paint any extra variation, or bake a noise map onto the vertices and tint the result, assuming the poly count is high enough to have good enough vertex resolution. Also because there more vertices than on a traditional masked material mesh you could probably get away with using vertex normals for lighting calculations too. And as for roughness like I said the roughness could be stored in the vertex color alpha channel since you're using opaque materials with nanite but that alpha channel is probably still going to be there in the vertex color information (unless it would otherwise be removed by some mesh optimization when building the game) so once again you're just making use of stuff that's already there
Of course for objects that require a particular pattern like signs with text you obviously want to use a texture map for that, but that isn't what this video is about
One topic that is greatly overlooked in optimization discussion is the bounds culling.
And the performance gains of packing actors vs loose static mesh components.
Actor count matters, and Epic rarely talks about it.
Thank you so much for this. People keep blaming the engine for providing tools to creators, instead of properly blaming the people who are *using* those tools.
Would it be possible for you to provide specs of the machine that those tests were made on? Thank you.
Very interesting insights, thank you!
Very elucidating content! I'll try the high-poly vegetation as you mentioned, not the masked/LOD version I use. Unreal itself should have more thorough material available on Nanine. Most people I know who experiment with Nanite learned from internet tutorials, most of them very simplistic, as you appointed (select the asset, then right-click to show menu, then click on Nanite, and that's it) and have the same rant you pointed about not gaining that much of FPSs. Let's consider Nanite is still relatively new to most users, especially in concept; it is not activated by default, and certain assets have different ways of activating it. There are some ways to do it more practically (plugins and community forum tips/scripts), but they may convert non-prepped assets, too. The best way to make people really get into it should be Epic itself to create a tutorial scenario for Nanite, then start from landscapes to foliages and model placing. The webpages/videos/pdfs should show what assets are better for Nanite and the procedures to activate them properly, showing the impact on the FPS. Then, best practices should be taught.
This is super interesting. Do you think that UE5 struggles to run on weaker systems because there are things that cryengine for instance does in GPU (like grass models which are static but then have tricks to make them look like moving) and UE5 does not use static maps (not sure if right nomenclature) for the most part but uses the CPU to check position of grass.
yeah, i mean UE5 is still not without its faults and has a long way to go in some regard. The way it handles movement on foliage for example is pretty bad, at least in the computation of it. like if you do it wrong it'll drop you like 20fps haha
@@DallasDrap yeah. I did a test a while ago in game (Remnant 2) not in engine in my 12600k where I had it clocked at 3.5 with 4 cores and then 2.33GHz with 6 cores active. UE5 ran better with six slower cores rather than 4. This was to try and see why performance of UE5 games is generally terrible on the Steam Deck. And why move things that are usually GPU based to the CPU?
@@DallasDrap Oh yes, WPO hurts a lot. Glad they introduced some culling measures in 5.2
@@AcharaStudios if not, i would lose about 20fps XD. With just global WPO it craps all over the framerate. That'll be part of the next video, cause theres a few tricks on making it run well and look good. VSM's for example are still a pain but there's a trick to help with VSM computation ill be showing
@@DallasDrap Oh yes, you can fine-tune VSM update/invalidation rates, as well as have separate static and dynamic VSMs. Good for foliage.
Also, WPO can still be culled on the GPU, the shader way, with neat blending, so there's no sharp snapping as it reaches the hard limit from Unreal's CPU culling.
Interesting insight, especially with the graph!
Why didn't you show the overdraw on Case 3?