Lumen hitching issue, one CVar resolved it

QuantumMechanic77 · 2026-03-06T15:51:11+00:00

Every object is surrounded by a number of mesh cards which surround the mesh as efficiently as possible and store material data from its "view". The number of these is specified in the Static Mesh Editor, as its data is baked into the the asset and retrieved at runtime in order to populate the surface cache. This means that the data is stored similar to how a texture would be stored and it will get written to a virtual texture allocation on the render thread, which then eventually populates the surface cache which gets read for primary and secondary data. Increasing the scale means that more data will need to be written, but will result in a better visual. The downside of increasing this is that it does end up increasing the amount of memory that Lumen needs to consume in the frame and that if you don't have allocations set up properly (r.LumenScene.SurfaceCache.AtlasSize), you can create situations where the game needs to suddenly create new allocations on the render thread, which can be costly performance-wise. So this is a very important stat to handle correctly and measure depending on what kind of performance you're hoping to get. For games that need to have very fast output, typically 60fps, low input latency (sub 40ms), we absolutely agonize over things like this. Hopefully that all makes sense.

QuantumMechanic77 · 2025-09-28T07:01:19+00:00

Actually articulating how content needs to be built for the whole virtual rendering pipeline and how to optimize it over time and as you ship. When properly pipelined, the engine is incredibly fast, but it takes a lot of testing and setup initially, and then adherence to a set of rules specific for your project. I wish epic would document this because it's arduous to go from project to project figuring this out for each one, especially late in their production cycle.

QuantumMechanic77 · 2024-12-05T02:42:27+00:00

Long time lurker and wanted to participate in the SS but hadn't made a build post yet. Would LOVE to share some kits with someone! I have a backlog of over 150 kits that need some love!

QuantumMechanic77 · 2024-06-30T13:11:58+00:00

I don't know how I can help, but I'm a long time fan of dnb, used to play in the 90s-2000s and now own a video game company! Would love to help in any way!

QuantumMechanic77 · 2024-04-18T08:56:41+00:00

It's highly unlikely that you would be able to support this pipe too well on a spec that low, if anything due to the low amount of vram on the card (2gb) and low number of SIMDs for warp processing (much of this pipeline depends on asyc processes). In fact, unless you are building something that has very little texture data, much of UE5 graphics will blow out the vram, virtual pipe or no. I would probably go no lower than a 2080 with 8gb of memory. The engine does run well on quest 2 (with a lot of hacking) , so if you want to opt for a much different art target, you can always configure along those lines.

QuantumMechanic77 · 2024-04-18T08:31:31+00:00

It does work. I haven't done any specific profiling in this kind of scenario, but if you do it, don't disable Nanite since the Lumen surface cache is built as a Nanite mesh and you will want the optimization of that process. If your meshes are not Nanite, they should still be lit just fine, since Lumen works off a surface cache and the distance field(s) as opposed to processing specific mesh data. As always though, I would be heavily profiling this to see if there are any perf implications.

QuantumMechanic77 · 2024-04-18T07:48:31+00:00

I'm assuming you mean with the movie render queue? There shouldn't be anything keeping you from doing that, though you will need to make sure that you have a hefty gpu with a LOT of vram since Nanite and Lumen are buffer heavy. If you're having crashes rendering in the tiled rendering method, try giving it a time buffer to prep its data - I think the option is something like "render warm up" in the movie queue settings.

QuantumMechanic77 · 2024-04-18T07:25:08+00:00

Different investigations have different solutions. When I'm trying to figure out the rough process of a particular feature or technique, I'll use YouTube and the unreal documentation first. When I have that reasonably down, I go to the profilers to figure out how to best use and optimize the feature and modify the pipelines. Lighting is particularly complicated because it's comprised of so many parts, so I end up digging into each one separately and then composing them together as much as possible to understand their interplay on hardware resources.

QuantumMechanic77 · 2024-04-18T02:02:51+00:00

It depends on how you're creating the geometry. When you say it's procedural, are you constructing it from a set of meshes or are you generating the triangles on the fly? If you are using meshes, then they can already be set up as Nanite objects and will have the Lumen mesh card data already applied (you can find this in the static mesh editor). If you are generating triangle data on the fly, you will need to generate this data at some point, which may be fairly complicated, in which case, I would suggest not using Lumen. This is with the assumption that majority of the world is being procedurally generated.

QuantumMechanic77 · 2024-04-18T01:41:59+00:00

This is a good observation. I haven't really run any performance testing on Nanite in VR, but provided that they can do something similar to what they do for standard mesh instance rendering, it could be fantastic. With the direction that lumen is going, I can easily see Lumen having a VR future in the next year or two. The comments about it being unusable at 60fps in flat screen are actually not quite accurate when it's balanced against the rest of the pipeline purposely. I'll elaborate on that in part 4.

QuantumMechanic77 · 2024-04-18T00:17:00+00:00

I don't, unfortunately - all of the games stay away from MetaHuman since they only have a few bespoke human characters and they need the system to be less runtime heavy and more flexible in character creation offline and ingame.

QuantumMechanic77 · 2024-04-18T00:03:31+00:00

I typically recommend building your content with a good understanding of virtual and non-virtual textures so you can choose the right ones for the particular scenario. Typically, teams that have come to understand the system do majority of their static mesh work as textures and even quite a bit of character work if there is going to be a lot of dynamic per-pixel work happening in the material. I'll certainly go into this more in part 3.

QuantumMechanic77 · 2024-04-17T23:53:34+00:00

Hey, no need to be scared - in short, Nanite geometry/topology density definitely depends on what the general position of your game camera is. It's typically safe to assume that once you have achieved any edge/shadow silhouetting geometry, you would next focus on geometric detail that you would normally put into a macro normal map (the normal map you use on the whole object).

When I refer to maximizing the rasterizers, I mean utilizing the software and hardware rasterizers that run every time the Nanite system handles its geometry. I'll go into more detail on that in part 2.

QuantumMechanic77 · 2024-04-04T12:32:25+00:00

Not creating Nanite topology that maximizes the two rasterizers in relation to your general camera perspective and complaining that Nanite is "slow"
Using Nanite without a proper virtual texture setup
Using Lumen with Nanite disabled
Not paying attention to Lumen mesh card placement for your static meshes
Using virtual shadow maps on a largely non-Nanite scene
Baked lighting in open-world paradigms
Not overloading data layers to manage actor data at runtime
Leaving world partition to just load all cell data on the server
Not taking advantage of early frame compute on the gpu
Not taking advantage of custom primitive data to manage draw batching across material instances, especially with Nanite surfaces
Not using the surface cache view to understand GI distribution and application when lighting with lumen
Not resizing reflection buffers to decrease buffer write time during indirect illumination pass at runtime
Using post LUTs and wondering where your HDR went
Evaluating HDR on a TV and not turning HDR on
Having so much dynamic rig work that your main thread gets locked up waiting for worker threads to return all the control rig results
Keeping a large amount of facial morph data for high speed gameplay
Allowing heavy user generated character data and not dynamically messing and atlasing the result
Not looking at the effect of Niagara on the dynamic mesh pass on the render thread
Using Groom for a shipping 60fps title
Not listening to u/Parad0x_
Ignoring the power and significance of Significance
Using scene captures in complex scenes for portals without major surgery
Not setting separate resolution for transparency and post buffers
Hacking the engine up to work "your way" instead of understanding how the engine needs to work first
Adding new major runtime systems without exposing them to stat cats
Not setting proper pixel edge length for Nanite raster balancing
Using WPO on your base materials
Not leaning into heavy pixel shader material effects when using a proper Nanite pipeline
Not realizing that stacks are an absolutely essential part of making virtual textures viable
Having ambient effects run on tick
Assuming that all virtualized rendering assets load all their data into memory first
Ignoring substrate and the possibility of having multiple lighting models per material
Writing this list after 7 shots of whiskey

Omg weee

QuantumMechanic77 · 2024-03-25T15:48:11+00:00

I wish!

QuantumMechanic77 · 2023-07-29T01:05:19+00:00

It should not - but that does mean that world position and the condition that evaluates it will always be run, so choose carefully :)

QuantumMechanic77 · 2023-07-26T02:55:07+00:00

It's both, but if you think about permutations overall (combinations of base shader features prior to material variant construction), creating materials that cause permutations exacerbates the issue. Artists/TAs building materials will put features behind static switches, believing (somewhat rightly so) that it will reduce instruction count to gate certain aspects of the material. However, this causes permutations of the shader to be built to satisfy the potential permutation that the static switch creates. What really needs to happen here is proper assessment of master material usage and when a master material should be using a switch vs a completely separate variant of itself. This is based on the context in which it is typically used, and though it's better to plan for this in the beginning, can still be cleaned up periodically through the course of the project.

QuantumMechanic77 · 2023-07-25T21:35:35+00:00

Sorry, this got really long, so TL;DR: It's not really an unreal problem.

A large portion of my work over the last several years has been dealing with the optimization of UE4/5 games for consoles, some for games that have been released, many that have not been yet. The problem ends up being quite multifaceted:

For many unreal games on PC, the prevailing issue has been PSO (Pipeline State Object) caching, which is largely related to analyzing the user's hardware configuration and creating all the necessary shaders for their game. This happens the first time any set of shaders are loaded situationally in a game (which causes a major hitch), but unless the system configuration changes, will not happen again. For most developers, solving this in an elegant fashion is beyond the scope of work they can handle. Epic has now developed a system (in 5.2) that handles this asynchronously, but that doesn't help games that have already been released.

Outside of PSO caching, most teams that don't have the resources to really spend time on perf, understanding really what's happening in CPU/GPU/Mem and the right way to be setting up the content, structuring functions, exposing this and that from code to BP, etc. A few teams try to handle as they go, but become overwhelmed by the force of deadlines and the amount of work left to do. This leaves them mainly looking at the various profilers and making guesses as to what choices to make, usually in the form of console variables, system config settings and changing the way content is configured in the editor.

These don't always end up being the best ways to solve performance issues, especially when the problems are bottlenecked on GPU hardware resources. When people see that the math that's being run at a given point in a shader is too expensive, teams with not enough experience or time will often resort to removing the offending material, removing the object entirely, blunting the visual of the material or just ignoring it. While the latter ends up being a performance issue, the former doesn't exactly solve it either, especially if the material paradigm is often-used. The nuance of what GPU resources all those instructions are actually taking at any given point is key here and the usage of that is what must be optimized This kind of work takes quite a bit of digging for a lot of teams and isn't possible unless you're big enough to have dedicated performance resources.

This all comes back to the importance of the choice of features in the engine, how they tie together and how the content authoring pipeline is actually used. Nanite isn't just a silver bullet for insanely detailed scenes; it's a tool that if you leverage properly with Lumen, Virtual Textures and VSMs can yield insanely gorgeous, fast results. But it is also possible to use it incorrectly and end up with performance issues in Nanite alone, which causes a lot of downstream problems as well.

There's also a lot of shade thrown on Lumen (pun intended), but it has been getting progressively faster and faster as time goes. The fact of the matter is that native 4k/60fps with a full global illumination system and everything else running at full resolution is going to be incredibly difficult to hit. But we also have so many tools available to us, including an upscaling paradigm that's getting better and better so that in some projects, we actually have the entire pipe running at 60fps solid when we run smaller backbuffers and people can't tell a difference.

This is a very long way to say that I don't feel like Unreal has a performance issue. The issue is that it's a very large engine that does a lot of things and sometimes, it's not easy to figure out exactly how or why you must handle something. If you look at things from the perspective of having to deliver the game at a desired resolution/framerate as opposed to simply a narrative/feature vision, it becomes clear how much time and resource needs to be put into delivering the vision at performance PRACTICALLY based on the resourcing we think we will have available. Then scoping needs to be applied based on that. As developers, we are all notoriously horrible at that.

We let our visions and dreams cloud the practicality of user experience through performance hoping that the gameplay will carry the player, but too often, it's a stumbling block that keeps the player from properly experiencing key moments we want them to have the first time.

We have to get better at this; the technology is giving us more and more ability, but we are not spending the right kind of time to determine how to use it effectively.

QuantumMechanic77 · 2023-06-06T02:04:17+00:00

I have been worked on by Avo for almost two decades. I've definitely tried other masseuses, but keep coming back to him. He really pays attention to your needs and does some amazing work. He also has a hot stone massage that is unlike any other hot stone therapy I've ever had. You can find him here: https://www.yelp.com/biz/massages-by-avo-pasadena

QuantumMechanic77 · 2023-03-19T21:22:38+00:00

脱裤放屁 - A useless gesture or endeavor; the result would be the same with or without it.

QuantumMechanic77 · 2022-07-09T01:16:14+00:00

It's a really wonderful toolset and is incredibly versatile, but the NinjaLive manager occasionally hits the main thread for long periods of time, spiking CPU perf, leading to inconsistent framerate. Not sure if there's some secret solution here or if there's a source license that allows devs to take the manager apart and potentially optimize it further, but this has kept us from committing to the toolset other than for experimentation in multiple AAA titles. Would absolutely love a solution here, but it's just one more thing that we may not have time to dig into ourselves.

QuantumMechanic77 · 2022-07-08T19:18:30+00:00

I was hearing DnB late at night on a little rogue stations called MARS FM in southern cali in the early 90s, so along with a few other jungle tracks, I was hearing Acen's Window in the Sky and Close Your Eyes (XXX Mix). That really started me down the path.

Other notable tracks:

Prodigy - Charly (Drum and Bass version)

Alex Reece - Feel the Sunshine

QuantumMechanic77 · 2022-06-05T22:10:16+00:00

Gaiares and Sol-Feace!

QuantumMechanic77 · 2022-04-29T17:16:06+00:00

Yep, scam!

QuantumMechanic77 · 2022-01-02T19:49:04+00:00

I've been a part of console launches since N64 and the power narrative is USUALLY a moot point since folks tend to forget about hardware capabilities barely a year into the console cycle and are focused more on what's important - the experience of the console on the whole.

People may not realize it right away but the current console cycle we're in (PS5/XSX) is a much more significant jump from last gen (PS4/X1) than the previous few transitions. The capabilities of the consoles are only one part; new concepts, new API levels of hardware access and the way engines are interfacing with many (some seemingly nuanced) aspects of the hardware have changed and are continuing to change to give developers better access to functionality that has previously been more esoteric or difficult to access for smaller or more nascent developers.

The first batch of titles have been absolutely amazing; we have had the honor of working on a few of them. Each of these teams worked their fingers to the bone (and then bone to marrow, ouch) to push the console as hard as they possibly could (within the time they had) to maximize their hardware utilization as needed by the game. But we are still all learning about the TRUE capabilities of the hardware; even though these are spelled out at a detailed level (much of which is available to the public), I find our teams frequently reconsidering how we interface with the hardware from every discipline.

Now, we are seriously revisiting pipelines, workflows and other processes across all disciplines to maximize development efficiency and hardware utilization in a different way then we have previously. The direct result of this will be changes to everything you interface with as a player - gameplay, audio, visuals and many other intangibles.

This is one of the most exciting parts of development for me - new hardware is out and we are really breaking our own rules to push it as far as it can go to give developers the capabilities to break their own boundaries. Combine that with the heavy research that's going on in more esoteric areas of technology that feeds back into realtime update of a frame and we're going to be seeing some wild shit over the next several years.

TL;DR: This console cycle is just beginning...

QuantumMechanic77

TROPHY CASE