Press play to start listening
There is a certain tension in real-time graphics today between Unreal Engine 5’s technical aspirations and the commercial imperatives of the mobile market, where interactive entertainment has made its home. According to Epic’s performance guidelines for mobile, which reference Sensor Tower’s 2025 State of Mobile Gaming report, the numbers are telling: mobile represents 83% of all players and 55% of gaming revenue overall, with mid-core games responsible for 56% of that income.
And then there are the tools that give UE5 its look. Lumen, Nanite, Virtual Shadow Maps, and the new MegaLights were put in place by Epic for “next-generation consoles and high-end visualizations” rather than the thermally limited system-on-chip found in a pocket. For a studio developing cross-platform work, it is therefore a matter of strategy to know exactly how UE5 lighting will perform on mobile. One has to be clear on what is and isn’t supported and the cost of those trade-offs in terms of battery life, memory bandwidth, and milliseconds.
Forward or deferred: The architectural divide on mobile
When it comes to mobile lighting, the shading path is the primary decision and one with the most far-reaching consequences; it will dictate the course of all that follows. UE5 provides two mobile renderers (and an experimental one for desktop) that can be put in place with the r.Mobile.ShadingPath console variable.
Epic’s documentation for mobile rendering describes forward shading as the way to handle material interactions with light and shadow at draw time. It is the default mode on mobile for good reason, offering the broadest hardware compatibility and what they call the “fastest baseline performance.” But there is a structural price to pay. With materials having to carry their own light and shadow code, forward shading has its limits when it comes to dynamic reflections and shadows. The heavier shader compilation can also lead to more hitches and memory use than you would see with a deferred approach.
Mobile deferred shading works on an entirely different principle. It separates the process into a geometry pass to put material attributes in the GBuffer and a subsequent lighting pass to retrieve them. The difference in efficiency is stark. Epic puts forward a case with a simple material: under mobile forward, it requires 147 instructions and 2 samplers, whereas mobile deferred needs only 34 instructions and 0 samplers at all since the lighting and shading instructions are superfluous.
On top of that, deferred eases the burden on CPU graphics state management. There is no need to bind shadow or reflection textures with every draw call, which keeps the Render Hardware Interface thread from running into conflicts with the others.
You could say the mobile deferred renderer is only viable inasmuch as it makes use of tile-based rendering, the hallmark of a mobile GPU. In place of the full-screen GBuffer that a desktop unit would set aside in slow system memory, the mobile approach stores its intermediate lighting data in on-chip tile memory.
There is a portability hazard to be had, however, given how the mechanism is splintered throughout the hardware ecosystem. Epic has put on record the variety of approaches: iOS relies on something akin to framebuffer_fetch, Android Vulkan on subpasses, and Adreno on the framebuffer_fetch extension. Mali and PowerVRs are another matter, needing PLS extensions for pixel local storage.
Then there are immediate-mode GPUs, which have no choice but to put the GBuffer in system memory and see any advantage in memory usage disappear. Ticking the box for “mobile deferred” is thus not a simple matter; it means dealing with four separate code paths that perform in materially different ways.
That reliance on tile memory is what makes bandwidth, rather than pure compute, the usual limiting factor on mobile. Take Imagination’s advice for their PowerVR tile-based deferred architecture: do not neglect to clear a render target or the GPU will be compelled to pull old data from external memory, which is costly.
A depth pre-pass is pointless too since Hidden Surface Removal in the hardware will discard occluded pixels anyway. They are equally insistent on texture compression as a means to conserve battery and boost performance by reducing runtime bandwidth. It is a lesson that holds true for mobile GPUs in general; one is often paying for lighting in terms of thermal headroom and memory traffic instead of floating-point throughput, turning on its head the sort of optimization you might be used to from desktop work.
Non-negotiable rules of the static lighting regime
Precomputed lightmaps are still the go-to solution for most mobile shipping titles when it comes to the question of how to put in the lighting. That is by design; the engine’s guardrails see to it. Epic is quite blunt on the matter: should a project be using precomputed lighting, deferred shading will be limited to the Unlit and DefaultLit models.
“We strongly advise that you use forward shading instead,” they say. It is the heart of the mobile lighting problem. The renderer, which is the most economical for dynamic work, is the very one Epic puts its foot down on for the kind of baked-lighting workflow that mobile games are built around. One cannot just opt for the faster renderer; it is a matter of reconciling rendering architecture with lighting strategy before art production gets underway.
There are further constraints once a course is set. You will not find multi-sample anti-aliasing in mobile deferred since the GBuffer has no room to give. Lit decals do not work with static lighting either, as the extra buffer required is simply not feasible on a mobile device given the memory limitations.
Even where deferred decals are possible, the octahedron normal encoding employed to save GBuffer space means there is no way to blend or tinker with normals, an authoring limitation that has a tangible effect on surface detail. Then there is the matter of translucency.
A material like glass or water will have to be set to Surface ForwardShading because the pass reverts to forward shading regardless of being in deferred mode. In practice, mobile lighting is a hybrid affair rather than a straight pipeline, with the renderer making quiet switches from one material to the next. Those who do not make a habit of understanding these ins and outs tend to run into trouble down the line.
Then there is the forward path, which puts a hard budget on dynamic lights. The UE forward renderer will cull reflection captures and lights to a frustum-space grid; for stationary ones, it packs their dynamic shadows into the channels of a screen-space shadow mask, making use of the four overlapping stationary lights that are permitted. One should not mistake that four-light limit for an option so much as an architectural constraint with bearing on level design.
The forward renderer has its own merits to offset this. Forgoing intermediate buffers allows for multi-sample anti-aliasing, a means of sharpening the image and saving on GPU resources in a way temporal anti-aliasing cannot. In the space next to mobile, the forward renderer is still the way to go.
Meta’s Quest documentation makes clear that forward shading is what is called for in Quest development, and indeed is a prerequisite for the 4x MSAA they put forward for all their devices. It is only natural given the bandwidth considerations at play: a standalone VR headset on mobile-grade Snapdragon silicon is subject to the same rules as a phone.
Shadows: The virtual shadow map problem
There is no area where UE5’s console-oriented design runs into mobile limitations with more force than in the realm of shadowing. With the release of 5.0, Virtual Shadow Maps (VSM) were made the standard for directional shadows and are by their nature tied to Nanite. Epic makes it plain in their documentation that Nanite will not work with a host of Stationary Light shadowing methods; one has to make do with Movable Lights or VSMs.
The way VSMs are built is to put aside a virtual 16k-by-16k map and break it down into pages, rendering them on an as-needed basis after a depth-buffer analysis. What is left over is cached from one frame to the next, provided moving objects or light do not come along and invalidate it. That caching is the whole point of the performance model, yet it is a delicate thing.
Epic has been candid about this fragility. An engineering retrospective on Fortnite Battle Royale Chapter 4 puts it in perspective. Where they could let tech demos such as Lumen in the Land of Nanite or The Matrix Awakens depend on shadow map page caching for good results, Fortnite was hampered by a pair of obstacles: the sun never stops moving, and there is plenty of animated deformation to be had in the form of trees.
Throttling the updates was not an option, as it would create too many artifacts at the edges of the pages, so the engineers had to resort to custom solutions like reprojecting lookups to a base pose. And for good reason: according to Epic, any geometry subject to skeletal or World Position Offset animation will nullify your cache every single frame. For the kind of open-world mobile game that relies on animated foliage, VSM is something of a trap.
The disparity in cost between a shadow that is cached and one that is not is considerable. Profiling on the PS5 shows a local VSM in full invalidation will run you 0.4 to 0.8 ms against a mere 0.05 ms if it is cached. Run the same through a non-Nanite path in 5.7, and the per-page expense is 1.6 times what Nanite demands. On mobile hardware with nowhere near the throughput of a PS5, those figures can spell trouble for the frame rate unless one is very strict with the cache.
A technical arXiv review notes the trade-off: while VSM can give you better soft shadows and hold 75 FPS on an RTX 3080 with 30% less memory, the computational overhead is a hard limit for lower-end systems. In short, you get the quality from VSM, but only if you have the discipline to manage the caching, something dynamic mobile content is wont to undermine.
Lumen: The frontier of global illumination on mobile
There is no technology that mobile practitioners covet more than Lumen, nor one that is more difficult to put in their hands. From an architectural standpoint, Lumen works by tracing rays against a low-resolution Surface Cache it keeps in reserve; this is a card-based parameterization of the scene’s surfaces, with a default of 12 cards to a mesh. The system will use signed distance fields for software ray tracing or make use of a GPU BVH if the hardware allows.
Epic leaves no room for ambiguity as to what Lumen is meant to do. Its main shipping target is large open worlds at 60 FPS on next-gen consoles. At Epic’s scalability level, that translates to about 8 ms at an internal 1080p resolution. On a mobile device, however, an 8-millisecond allowance for global illumination is a considerable portion of a frame already tasked with geometry, UI, shadows, and gameplay in a 33 ms (30 FPS) or 16 ms (60 FPS) time slot, and that is before any thermal throttling brings sustained performance down from peak benchmarks.
The support matrix is telling in its frankness. According to Epic’s documentation, while experimental Lumen is available in UE 5.4 and later, it is restricted to high-end Androids with Vulkan Shader Model 5 compatibility running the desktop renderer. iOS, tvOS, and iPadOS are out of the question entirely. That is a notable omission for a platform with such a dominant revenue share. Then there is the matter of the desktop renderer on mobile, which, as Epic puts it, has “significant performance costs.”
Those in the field have been just as circumspect. A thorough technical dissection by an independent practitioner found most mobile hardware simply lacks the compute throughput for Lumen. For that reason, Epic does not officially put full Lumen on mobile, preferring to see the forward or deferred renderer used with baked lighting and reflection captures.
The limitations one encounters with Lumen are of an inherent nature, not mere happenstance. The engine has to contend with thin geometry, transparency, and the like in mirror-laden spaces; this is a byproduct of its approach to casting a single reflection ray per pixel after having first traced screen-space rays before it resorts to sturdier techniques.
Then there is the matter of lighting updates being spread out over several frames. That results in a propagation delay of a frame or two which is all the more noticeable on mobile hardware where the frame rate is lower.
Epic has put on record that emissive detail has a floor: “there’s a limit to how small and bright emissive areas can be before they cause noise artifacts.” Such things are not bugs in need of a fix, but rather what you have to accept as the price for making real-time global illumination feasible.
MegaLights: A New Take on the Many-Light Budget
Epic has put forward MegaLights as the latest major advance, and with good reason. Launched in UE 5.5, it is described by Epic as an entirely new way of handling direct lighting, one that gives artists the freedom to work with orders of magnitude more dynamic and shadowed area lights than was previously possible.
What makes it work is a stochastic method at its core. For each pixel, MegaLights will trace a set number of rays to key light sources; through temporal feedback and importance sampling, it determines which are the most consequential for any given screen tile. This results in a cost curve unlike anything else. To put it in terms Epic has laid out: while deferred shading holds steady on quality but sees GPU costs mount with every added light, MegaLights keeps performance flat even if the quality wanes as you increase the complexity at a pixel.
The proof was on display at Unreal Fest Seattle 2024. There, Epic showed the system powering more than 1,000 shadow-casting lights in real time on an unmodified PlayStation 5. Wyeth Johnson, senior director, made the case that this is a game changer for direct lighting and shadows in the same vein that Nanite has been for triangles or Lumen for global illumination.
What makes this discussion of interest is the question of MegaLights’ viability on mobile, an area where one can find some truly novel evidence. In a recent integration case study put out by Arm’s engineers, they have shown how to bring MegaLights to the Mali-G1, their top GPU, via a Lumilings demo. According to Arm, the technology is capable of handling over 190 dynamic point lights with ray-traced visibility and shadow casting on the Mali-G1, which is about five times the performance you would get from deferred shading in an equivalent scene.
It was not a matter of simple implementation; the work entailed considerable engine modification. While MegaLights makes use of the forward renderer’s clustered light grid, it demands a global linked list in place of the per-cell lists that are standard on Android and confined to eight lights. Arm points out that forgoing such an alteration would result in the kind of frame-to-frame flickering caused by varying light subsets.
Then there is the matter of official backing. Arm is clear that Unreal Engine has no formal support for MegaLights on mobile at present, so what was done here was on a custom UE 5.7 branch. For the average studio, MegaLights on mobile is not something to be ticked off a list. It is a proven option for those with the resources to fork the engine, though one should bear in mind the CPU-side BVH build costs; console developers have put those at 3 to 5 ms when dealing with 200 or more dynamic objects in a scene.
The Snapdragon Inflection: How Silicon is Catching Up
One could say the hardware trajectory has put a new bend in the constraint curve. Case in point: at Unreal Fest 2023, engineers from Snapdragon Studios put on a show with Adreno GPUs running ray-traced soft shadows and Lumen global illumination over Vulkan. Arm has since followed suit by putting out learning paths to get hardware ray tracing for Lumen up and running on Android.
But the defining moment was in January 2026. Qualcomm unveiled ProjectOne, a real-time cinematic put together with UE 5.4 content that made use of Nanite, Lumen, Virtual Shadow Maps and ChaosCloth. Rendered at 30 FPS on the Snapdragon 8 Elite Gen 5, it was a display of the full “next-gen” lighting stack that up until now belonged to living-room hardware.
With the creation of the Unreal x Snapdragon Developer Alliance, it is clear platform holders are looking at UE5 mobile lighting as a strategic pipeline worth their investment rather than some box to be ticked for compatibility.
Then again, one should not read too much into such demonstrations. A polished 30 FPS piece on top-tier silicon is an indication of what is possible at the ceiling, not a fair reflection of the median device. The demands of UE5 are considerable even on the desktop; there is a general agreement among practitioners that to run Lumen without a fallback on anything short of an RTX 3060 is to court an unplayable experience.
Epic is right to stress in its guidance that mobile performance “varies wildly.” There is a chasm of multiples between a Snapdragon 8 Elite and the low-end Android found across much of the world’s installed base. Any lighting pipeline that is only proven on a flagship will not hold water with the bulk of the addressable market.
Case study
To see how shipping titles put a practical end to the matter, one need only look at case studies from games with a few hundred million players. There is no better modern illustration than Kuro Games’ Wuthering Waves. The cross-platform open-world RPG is the work of more than 500 people and, in a telling detail, it runs on a very particular build of UE4.26 instead of UE5.
Masahiko Nakamura of Indie-us Games has put forward a technical-artist’s view that this was a calculated move. For the studio, an upgrade to 5.x would be “essentially impossible” without undoing years of custom work; version changes have to be done in stages. So they back-ported what they needed from UE5 into UE4. Solon Li, the CEO, was forthright about the limitations of a static-lighting regime for a live-service world: “Baked lighting often falls short” when you have dynamic weather and an open environment. If he were to make the switch to UE5, Lumen would be his first order of business.
What the engineers did in the meantime is revealing. Kuro put its resources into a proprietary lightmap solution instead of taking Lumen as is. An examination of the Engine.ini file shows a MagicDawn plugin has been integrated, one that stems from research into UV-space lightmap compression that yields an 83% cut in storage while boosting PSNR. You will also find custom mesh batching and PSO/shader-caching plugins there. It is a hallmark of the top-tier mobile UE operations from the big studios: they do not simply go with the stock lighting defaults but engineer around them.
Then there is Fortnite, which is the antithesis of that structural advantage. Epic’s VSM retrospective bears this out: as their flagship title, it has the luxury of working with the engine team to address unusual shadow-caching issues through custom engineering that then gets folded back into the engine. It is an institutional edge an outside studio would be hard put to match and serves as a case in point for how the mobile lighting one sees in published games is often a function of engine access most do not have.
One can see a third pattern with Arm’s Lumilings demo. Here a silicon vendor has forked the engine to put its hardware capabilities to the test, offering a reference implementation for running hundreds of dynamic lights on a mobile GPU.
In VR the fourth type emerges; Meta’s figures from sample projects are telling, with 13 of 19 official examples set up for forward shading. It is proof that even a platform holder making the most of mobile-class silicon will tend to take the conservative, bandwidth-friendly route.
What follows are some strategic takeaways for technical leaders drawn from the data
One can draw a few firm conclusions. To start, the choice of renderer is ultimately a product matter and not one for the rendering team to decide on its own. Consider the iOS Lumen exclusion or the MSAA-versus-deferred trade-off; these and the like put an end to whole swaths of art direction.
For that reason, studios would be well advised to set their static versus dynamic lighting posture and shading path prior to any scaling of art production. Trying to retrofit a new lighting strategy onto a shipped library of content is simply too costly.
Secondly, there is the need to have a fallback tier in place from the outset. Both Epic and our own analysis make it clear that if you do not provide a low-end option and instead push a high-end lighting path, the result on inferior hardware will be unplayable. The per-device profiles and Quality Switch material expression are there to allow a project to span from baked-lightmap LDR to dynamic global illumination. Any mature mobile pipeline will make use of them as opposed to shipping with only one configuration.
Thirdly, shadow caching should be viewed as a design constraint of the first order, not some afterthought at runtime. VSM invalidation due to moving lights or World Position Offset can run an order of magnitude more than what is cached. That makes the handling of animated foliage or a dynamic time-of-day a performance issue right from the art-direction stage. Even the engine’s creators at Epic have had to come up with novel ways to protect caching in Fortnite under such circumstances.
As a fourth point, one should be profiling on the target silicon rather than the workstation. The mobile best practices put forth by Epic make it clear why: you have to benchmark the actual device. A desktop dev machine is no substitute for understanding the tile-based and thermally throttled nature of a mobile GPU that is bound by bandwidth. In the end, it is sustained thermal performance that will dictate your shipping frame rates, not what a peak benchmark might show.
Finally, there is the matter of the Snapdragon and MegaLights inflection. View it as an indication of where things are headed, not as something you can rely on in the present. There is a real and quickening path from the UE 5.4 experimental Lumen to the 30 FPS ProjectOne cinematic or Arm’s 190-light Lumilings demo, and with the Unreal x Snapdragon alliance in place, the ceiling is only going to get higher.
Yet MegaLights has no official mobile backing and Lumen is still off limits to iOS; for the average device, baked lightmaps, forward shading and four dynamic lights remain the norm. The sensible approach is to build a lighting pipeline with a floor that ships well today, while leaving room at the top for when the hardware and Epic’s support are in place, instead of making tomorrow’s silicon the make-or-break for the game.
