Volumetric Light Shafts requires some attention ASAP.

Well, guys from Ninja Theory decided not to wait native ue4 volumetrics and made their own implementation (nvidia version maybe)

Epic aren’t developing Gears.

The idea was that feature request from big developer has better chance to be included in main branch of engine (on other hand - big developer has enough resources to implement it).

It should become pretty standard, a lot of games are using it now, only a handful used it in the last generation

Time they start listening to the community, >600 votes and 2 years on the backlog is enough. Time to get it done Epic…
A world-class graphics engine need volumetric effects that are not just screen spaced.
I’ll wait a couple of month and after that i’m jumping ship to Cryengine…

Why? Yes, Epic’s been slow to implement some features, most notably realtime GI and volumetric effects, even though those are the two most wanted features in the entire engine according to the votes, but Unreal isn’t just a graphics engine. Games have been faking light shafts for decades, in some of the content packs on the launcher available for free, Epic even has one of their attempts to fake it. Is it really worth all the time and effort learning a new engine over it?

For every feature the CryENGINE does right, with the engine actually having both realtime GI and volumetric effects right out of the box, there are just as many things that the engine lacks that Unreal does really well. Personally, I would rather use the tool that makes my life easier in other aspects and have the visual effects come when they’re ready than abandon everything for it. They were out of the backlog for a bit as it is, so someone’s clearly interested in getting it done, it’s just not one of the priorities Epic has as a company right now so it got pushed back temporarily.

Like someone in the thread said, a lot of games actually need volumetric fog / light, and especially this is true in 2016. Sure you can do some stuff with faking light shafts, but that means you have to fill every level with hand placed light shafts, and if the lighting conditions changes (intensity, direction, occlusion, color), you have to re-place them etc, matching them with actual shadows isnt very fun for example and time can be much better spent. Sure you fully understand what dynamic volumetric light encompasses if you are recommending light shafts? Some effects, for example how would you accomplish light rays hitting a rotating fan with static light shafts? Would you rotate them? what if i add another fan? Things get out of hand very quickly so there’s no question you need real engine support. Maybe the problem is that UE4 uses shadow maps instead of shadow volumes, which could have been leveraged to generate light volumes more easily.

Here’s a good example of what i want to see in UE4, Volumetric Lighting Test Project - YouTube
Although I’m impressed with how much Epic adds to each iteration of UE4, their priorities are quite weird at times, and having waited for so long for this sadly i’m starting to doubt this will ever be added…

Can you give an example? What gameplay function do light shafts serve?

First off, if Epic -does- add in volumetric light shafts, it’s unlikely to be fast enough to use on every single light as you suggest. At most I can see it working on 5-6 lights at once, which is more than any artist would need anyway.


Then you make it a single blueprint and have it automatically update for every fan in the level.

Right, what you want isn’t in question, only why you want it so badly. Light shafts are already “good enough” for the directional lights in the engine for most situations, and I don’t really see the push for it in every type of light. They’re an effect you don’t want to use too much to begin with, otherwise it quickly becomes cliche and loses its impact in a scene. Volumetric fog isn’t really a ‘need’ so much as a ‘want’, which is why Epic’s been so slow to do something about it.

What I meant was, if another fan was added in line with the other, then what you are proposing would not work anymore.
What I showed you in the video also isnt possible with static light shafts. So enough of this, before light mass / dynamic shadows were added were you recommending people to paint their own shadow textures, too?

Exactly, graphical components are not needed to produce a playable game, which is why they are conveniently always backlogged for more “important” things, honestly speaking priority always seem to be on helping non-programmers with AI , behavior trees, navigation and other tasks that are easily made in code. Nothing wrong with that, but if Epic continues to downplay the development need of new graphics capabilities to the engine by saying “not really needed to make a game” then in a couple of years they will have another Unity engine on their hands and the actual AAA studios who are looking for a truly next-gen graphics engine will find little use of all built-in game-play components and might choose another engine that is up to spec in the graphics department. Of course only Epic knows , but they can’t have the cake and eat it, too.

Epic if you are reading this, maybe integrating NVIDIA’s solution would be a viable option:

Although something more robustly integrated, perhaps as a new switch on the atmospheric fog volume (maybe a list of the volume contributing lights) would be preferred.

A Epic dev states that it was moved to the backlog due to the forward renderer, Search through the 4.13 preview thread.

That’s sort of good news, the forward renderer had more votes I guess I can be democratic and appreciate that they are listening to the community at least.

Still find it a bit annoying that random unrequested “WANT” features such as below gets added before serious graphic requests that has been on trello with lots of votes for two years.

For example new in 4.13: (don’t get me wrong, my project is also VR, but this is just ‘cool but unnecessary’).

  • Foliage Editing in VR allows you to use motion controllers to spray down foliage instances. Pressure sensitivity on the trigger is supported, and you can hold the ‘Modifier’ button to erase foliage.
    Some features (lasso tool and select tool) are still unavailable.
  • Mesh Painting in VR allows you to use motion controllers to paint on textures and mesh vertices. Pressure sensitivity on the trigger is supported, and you can hold the ‘Modifier’ button to erase.
    To use this feature, open the “Modes” window in VR, then click the “Mesh Paint” tab.

I’m just struggling to find the real use case that -demands- this be an in-engine feature instead of faking it like every other game prior to 2015. Even being a 3d artist myself, I’m trying to think of a situation where I would really, absolutely need a dynamic, moving light, with heavy fog to get light shafts like that to begin with, with objects moving around the scene, and the only thing I can even think of would be something like a rave. It’s extremely situational and honestly not useful for the vast majority of scenes.

To be clear, I’m not saying it shouldn’t be done, just that you’re vastly overstating the importance of this particular rendering feature.

As someone who actually -has- used older editors where you have to fake everything, yes. Your job as a 3d artist is to take the tools you have available to you and make something beautiful with it, and when you want to do something as simple as a lightshaft coming from a fan and struggle to do it when so many other games have pulled that -exact- thing off without any problems, even with the UE3/UDK, it may be time to rethink your approach.

So far you’ve presented two situations where you would want to use it. The first one I can’t see being useful in 99% of games in production, the second one so commonly faked that it’s one of the first things a shader programmer learns how to do. While I’m sure there -are- situations where the feature would be useful, it would make for a much more compelling argument to bring to the table if you had a situation you could present where you can say, “Here you are, a feature that a lot of games in production can use, and this is why it would work better than traditionally available techniques, or maybe even where traditionally available techniques wouldn’t work in the first place.” Because right now, you’re trying to build a case on a situation where this wouldn’t work with -either- the material editor -or- blueprints.

Well you just summed up the problem in a nutshell there. All those features you just mentioned that they’re focusing on first are ones that help more people to produce higher quality games at a faster pace than you can with the competition using readily available tools already in the engine. The biggest problem Epic has right now is that the UE4 is an insanely complex and capable engine, but there are very few people who know how to utilize every engine feature properly.

Thankfully, they aren’t the same people that would be working on the rendering side of things.

Instead, you have an entirely separate rendering team, so you are -not- dividing up the team and stopping them from working on volumetric lighting just by having them write better AI documentation. Different fields and professions entirely. Instead, Epic’s rendering team has been working on engine optimizations to make things run faster, as well as adding in DX12 and Vulkan support to the engine. Now, as I said, volumetric lighting can be an expensive effect. By getting the rest of the engine to run faster, it gives you more breathing room to start adding more effects like that.

Epic’s problem with the UE4 and dynamic lighting isn’t the lack of features, at least that’s not the main problem, the main problem is the massive performance hit that dynamic lighting brings to the table. High end hardware struggles to perform well in the engine in a dynamically lit scene, and they’ve been adding things like cached shadows in 4.13 to address these problems. So while I’m with you, and while I would want volumetric lighting (and realtime gi on dynamic lights), I can at least see why they’re taking their time with it.

How does the team that works on VR features affect the graphics that is handled by the graphics team?
There are different “teams” that work on different aspects, There may be people who interact and or work with the different “teams”/sections.

This is kinda like asking why the engine designer did not improve the seats of a sprots car, they are two different areas that do not overlap.


Good reply. I actually agree with most of what you write.

It’s true that they have different teams, but the balance of these teams seem to have shifted a little bit in the wrong direction, surely core graphics programmers are hard to find. Like you say, it’s unlikely that all of these game-play components / features will ever be properly used due to quite limited documentation (yes, the lazy new generation need to be fed by examples and tutorials). I appreciate what they have done with the extremely complex area of animation blending etc, this is something you definitely don’t want to write on your own while at the same time the complexity can be quite overwhelming for a lot of of new users.

Anyway, if the reason this is taking time is that they want to do it properly, then perhaps it’s worth the time. Let’s hope thats the reason. Honestly i think it would be a good idea to be more transparent with the roadmap on Trello, when features are backlogged perhaps something can be written on why and whats the new plan, I find that we are all too often put in the dark, would it really be so hard to provide a comment when Trello updates are made?

It’s fine if its expensive, it can easily be turned on only to high spec machines and so fourth. With the increasing amount of VR features being added, Epic should realize we need less screen-spaced effects and more in actual 3D, and this is a very good example of the latter.

I dont agree with your notion on how everything can and should be done by spending hours hand placing and painting in details. I know that games can look good with limited tech, but then you need to throw a lot of time on manual labor instead, there’s nothing like a free lunch. Stuff like shadow, light and fog is exactly what needs to be done procedurally in modern engines if we are to be able to lift the overall quality of productions without massively increasing the amount of artists working on a project. Just look at how much tools like Substance Painter have saved, a single artist can now texture tons of assets while you are still hand painting on yours in Photoshop a week later. Good tools create freedom for small studios and save money for larger. There are things that will likely never be done procedurally, so let artists focus on that instead of light effects that of course should be done physically, procedurally in-engine.

Being quite senior and having attended a lot of Siggraphs; if you are worried about ‘massive performance hits’, I can promise you that the same thing have been said about virtually every new algorithm through out the times of computer graphics. Trust that modern hardware will pickup if theres demand, and I honestly dont think dynamic lighting will be a big performance hit on modern hardware in a couple of years. Until then there are good ways of maintaining a good frame rate anyway. Algorithmically speaking, decent volumetric lighting isnt very much different from stencil buffering shadow volumes, which was used all the way back in Doom 3. Only different is that you have light volumes instead, shaded by depth in an additive shader.

Sorry for the length, but i wanted to make a statement on the importance for procedurality vs hand-tinkering in game engines such as UE4.


Any news on this? …

I believe at one point they were working on it but it got delayed so it’s kind of on the backburner for now.