Unreal 5.5 is a big deal [video]
youtube.com
youtube.com
Unreal 5.5 changes: https://dev.epicgames.com/documentation/en-us/unreal-engine/...
Page on MegaLights, which appear to be the focus of the video: https://dev.epicgames.com/documentation/en-us/unreal-engine/...
Key quote from the above:
MegaLights is a stochastic direct lighting technique, which solves direct lighting though importance sampling of lights. It traces a fixed number of rays per pixel towards important light sources. If a light source is hit by a ray then that light’s contribution is added to the current pixel.
This approach has a few important implications:
Direct lighting is handled by a single pass in an unified manner, replacing multiple existing Deferred Renderer shadowing and shading techniques.
MegaLights not only reduce the cost of shadowing, but also reduce the cost of the shading itself.
MegaLights has a constant performance overhead, but quality may decrease as lighting complexity increases at a given pixel.
I don't want them to, just seems like the circle of life.
I love Godot for game dev, but it's not the full stack package, and last time I checked it wasn't great for 3D, but it's basically the best you have short of modding Doom.
RPG Maker and Adventure Game Studio corner the market on a niche genre of pixel-art RPGs and point-and-clicks if you want to stay 2D.
It's expensive to build a new engine from scratch, especially when Unreal says it can cross-build to PC, Xbox, PS4/PS5, Switch, Mobile, etc.
The problem is that making a generic does-anything engine means it can't be optimal, and more and more these days studios are using the engine but don't understand how to optimise within it. So now you're downloading shader caches from Steam because you can pull a pre-compiled shader across the network faster than it will build at runtime, and you still expect the game to run smooth as butter.
I build shit for the web, and this is the exact trade-off you make when you, say, choose Rails for your server over a more hands-on setup. I can spin up web apps in Rails with my eyes closed, it's that easy, but the performance has a high floor.
There are still a lot of engines. Plenty of people are starting to incorporate Godot, Unity hasn't disappeared, and companies build and leverage their own engines all the time.
The main reason Epic Games is so big is Fortnite, not Unreal Engine. They're still incredibly focused on that metaverse play.
Unity took all the buckets outside, burned them, then demanded money from all their customers. I've not seen new projects using them, because stakeholders are concerned about surprise expenses down the line.
Source: I work in the games industry.
I personally would consider AAA to be indicative of the game's overall budget, but without looking up the develo
Once they have captured both the engine and distribution market share, the anti-consumer policies will begin.
In the long run, I remain highly pessimistic and suspicious regarding Epic's long term strategy.
Reading the link below, the best I can surmise is that they shifted the prioritization from following a lightsource through all the different interactions it has, to the opposite of identifying, per pixel, how each pixel is illuminated via a prioritization scheme for light sources, including any nearby pixels. So it's a per-pixel approximation that results in a something far more accurate than the prior 'declared brute force' approach? Each pixel gets 2-5 inbound rays that have the highest impact.
How did I do?
https://dev.epicgames.com/documentation/en-us/unreal-engine/...
1. For each light, setup a virtual camera at the light and 1a. For each mesh, rasterize depth to a texture for that light (the shadow map) 2. For each mesh, rasterize material properties and depth to a texture for the main camera 3. For each pixel on screen 3a. For each light in the pixel's bin: sample the shadow map several times to determine if the pixel is in the light's shadow, and if not, apply the lighting for that light
By contrast, megalights:
1. For each mesh, rasterize material properties and depth to a texture for the main camera 2. For each pixel, pick a random light influenced by how close it is, how bright it is, etc 3. For each pixel, raytrace to the light. If you hit another object before the light, then you're in shadow. If not, the light is visible and affecting the point, so write the light to the direct light texture. 4. For each pixel, denoise the direct light texture by essentially blending spatially (with nearby pixels) and temporally (with pixels from the previous frame's direct light texture). 5. For each pixel, sampling the material properties and the denoised direct lighting texture, apply the lighting to the pixel and write out the final result.
The rasterized method is:
* Expensive - having to culling + rasterize every mesh per light means you can only have a few shadow casting lights * Expensive a second time - Each pixel needs to loop over all the lights in its bin * Expensive yet again - It's a lot of memory usage to store all those shadow map textures * Expensive a fourth time - To get good results, you need multiple samples of the shadow map per pixel, which is a lot of texture reads. * Poor quality - Shadow maps are a discrete approximation of shadows. Even with multiple samples, you'll often have poor quality and even artifacts unless you have either artists or a very complicated system to tweak shadow biases and cascades.
Megalights (stochastic light sampling), by contrast:
* Have a higher base overhead - ray tracing is expensive! * Scale much better - With a fixed number of rays per pixel (usually 0.5, 1, or 2), the time and memory cost at a given resolution depends mostly on the BVH complexity used for accelerating raytraces (if the random sampling is done correctly, Nvidia research shows that this can be surprisingly slow if you're not careful). Forget having only a couple shadow casting lights, now you can have thousands! * Looks much better, with much less work - No more adjusting biases or cascades or shadow sampling patterns. There's no need since raytracing is a fully continuous representation of visibiliyy between two points, unlike shadow maps. You can also integrate proper transparencies, refractions, reflections, volumetrics, emissive meshes or textures, IES light profiles, etc with raytracing, unlike rasterization. * Has different failure modes - With rasterization, too many lights or too complicated lighting will kill performance, but not quality. With megalights, performance will be fine, but you'll end up with too much noise for the denoiser to handle, which will look bad.
With megalights, could you for each pixel, pick multiple random lights to increase accuracy?
> With megalights, could you for each pixel, pick multiple random lights to increase accuracy?
You could, and megalights probably does. That's what I meant by 0.5-2 rays. Each ray you pick a different light source.
The problem is that you usually needs thousands of rays for good results in a single frame, and even a single ray more is very expensive.
Hence the reason people go as low as 0.5 per pixel (i.e. rendering at half resolution and then upscaling), and rely so much on a spatiotemporal denoiser, among other techniques.
The main example I can think of is the "yellow paint" discourse w.r.t to games like Resident Evil 4 remake Final Fantasy 7: Rebirth. Freya Holmer has a really great thread on the latter: https://x.com/FreyaHolmer/status/1756276112462627119
To be clear, I don't think the push towards realism is at odds with having a stylish and readable game. But the more dimensions you're dealing with (greater complexity in lighting models, materials etc.) the more difficult it gets to tie everything together into something cohesive.
While there are a few newer games I do enjoy, as far as I can tell, the bleeding edge features aren't needed to create what I find enjoyable about them. For me, I think the issue is that, outside rare exceptions, beyond a certain point increasing fidelity doesn't add value to game play. Admittedly, this is my own subjective assessment. Although I'm not in the game industry, I also worry that the increasing breadth and complexity of SOTA engines requires increasingly specialized knowledge and skill sets to leverage thus raising the bar out of reach of the smaller developers who often create the new games I do enjoy. It would be reassuring to hear from smaller and indie game developers who've found the new engine features in recent UE versions to be both accessible on small-team time budgets and enabling of significant new game play value.
Outside of gaming, I think newer capabilities like using SOTA engines for real-time virtual sets during film production are more creatively exciting because they can enable big budget story-telling on smaller and indie budgets.
City Skylines 2 is a good accessible example (even though it's made with Unity). Via mods, editing a single property takes several hours to make it look amazing. Time is spent adding texture decals, doodads, importing new textures, and playing around with the texture geometry (e.g. adjusting the grassy area size).
It seems like this depth of detail requires exponential time investment on the devs part. Small wonder CS2 launched with very few building options?
1st) What an amazing piece of technology this tool is.
2nd) How many years I would probably have to spend to learn all the ins and outs of that program from scratch.
> results still look Unreal.
Maybe its the NAME :)
I think a lot of it is artistic choice.
Demo here:
What's to stop Epic Games from building their own?
Is this a lot of effort to build and maintain? Seems like they could easily pull something out of Apple's playbook and leave you with a lot of tech debt.
Not trying to insult or belittle, just really curious about the line you're walking and your thinking about the ecosystem you're in.
Does Unreal have something similar?