Hi. I have some question about Epic’s future plans regarding UE renderer.
So… I have come all the way from Cryengine, which is the engine I mastered pretty nicely. And don’t get me wrong. I love UE and its flexibility. And there are various reasons I changed from Cryengine to Unreal Engine. The only thing that concerns me is renderer in UE. Its performance.
Cryengine is able to draw far, beautiful vegetation, alpha in Cryengine does not effect performance as much as in UE. Cryengine is able to bake everything in real time, where UE takes ages to do that even in editor. Not mentioning real time global illumination.
Is Epic planning on doing something to improve this aspect of UE?
Short answer: Yes.
Any news about this?
what about the long answer? 
can you at least elaborate on that? as far as I know there are 2 things that can lead to thinking of a major renderer upgrade:
- Niagara. the entire thing needed some very deep rendering changes and as far as I know it pretty much led to a different rendering pipeline which is more flexible and efficient. this is from hearsay so I’m not really sure about it though, but if the rest of the rendering would be changed in the same way it could end up being a major renderer upgrade
- DXR/RTX. this one is obvious and of course this requires a pretty major upgrade to the renderer, however it doesn’t necessarily mean that the raster renderer would have any benefit from it at all, i.e. if non-RTX users will see any improvement
IIRC there was also some talk of other renderer changes scheduled to 4.22 and beyond but I don’t have a link to that
Epic is aiming for implementing a Render Graph and recently the base pass was added to it
https://github.com/EpicGames/UnrealEngine/commit/835270e2d0eb195c2d5c7ad8c3924dd8d36a1274
Based on the commits in dev-rendering branch, I’d say UE 4 is getting some sort of rendering graph system similar to what DICE showcased with Frostbite. A really welcome update imo, currently it’s really hard to reason about how the renderer works (at least it is for me).
Also GPU lightmapper should be available to everyone regardless of RTX or not on user machine.
CryEngine is very outdated these days; they’re still stuck on Scaleform and other old things. Not even the makers of Scaleform use it anymore.
If UE4 implements DXR, anyone with a DX12 GPU should be able to use any of the ray tracing features.
Hyped for render graph but also afraid of over expecting from it. Rendering in UE4, as it is now, is exceptionally painful to work with(in the essence of not being able to pack a wide variety of otherwise trivial things into a plugin and doing massive engine builds just for basic changes on the rendering).
In fact, suggestions of OP about UE4 underperforming on the rendering side is partially connected to inflexible rendering pipeline and its acceptance as is for many projects, that would otherwise use more lightweight per-case solutions.
It truly is in many if not all aspects, but for multitudes, including me, their approach to anything rendering-related still sets the standard of simplicity, efficiency and maintainability.
Already done, it’s just not public yet.
Would like to see more flexibility, something like Unity. Writing new shaders is really easy and straightforward there and they work hand-in-hand with the UI of Unity.
Pretty much this. Is a black hole of time to even consider the smallest changes.
Also, hope the indirect global illumination in real time to not depend on a RTX tech, creating another high resource consumption method not usefull in real world scenarios. And instead be based on any of the existing “cheap” method of real time GI. And if possible a production ready one, not only experimental features.
Indeed. Cryengine is outdated in most of cases, and is pain in the butt to work with as it’s extremely unstable. But the rendering performance outclasses that in UE. That’s the only thing missing in UE. Once that at least reaches CE level, UE will be invincible.
The problem with the existing “cheap” methods is that all of them have quite large trade-offs that are oriented to specific kinds of usage. The craziest solutions you see from GDC talks are all from in-house engines and laser-trimmed to each game they are used on.
In my opinion the biggest priority should be making the render and lighting pipeline as extensible as possible without sacrificing efficiency. Because with that in place, several community and marketplace projects will be able to be worked on in parallel versus having one renderer that is very good at one thing only, like CE where outdoor scenes look great but it’s really hard to get indoor scenes to not look dated.
Guys, just a question, when you say “Render graph” do you mean that we can get an access to all the render passes and modify them inside material editor or postprocess material?
Sorry for interrupting.
What did you mean exactly when you said indoors in CE look dated?
Generally in CE, the GI isn’t good enough for clean interior spaces. Sure, with a lot of effort and tweaking, it can be acceptable, but that’s not ideal for a game where you go between indoors and outdoors.
I’m not talking about a dark, dirty, or visually noisy scene where it’s easier to mask or hide lighting detail.
Possibly? “Rendergraph” or “Framegraph” is a term that comes from a very neat paper Dice (EA) made about an upgrade to their Frostbite Engine. Anyway, it’s a bit like a Blueprint in UI, but the underlying thing is for making changes to differing rendering passes. You get to switch out which render passes you want, where and when, in a nice modular UI without a lot of the fuss and possible re-writes you’d go through now.
What else you could do with UE’s implementation is known only by the Devs. But the good news for UE users is months and months ago Epic decided to hire a bunch of new rendering engineers. What they’re doing, or will be doing, IDK. But UE4’s core renderer could use an upgrade that I could go through point by point. But the bigger point might be a re-write of UE4’s core renderer might be cleaner. The code base has grown out of control over poor decisions and code debt, EG did Paper 2d ever really need to exist? Re-writing for Dx12/Vulkan/Metal, and ditching lowest end HW support such as pre-Vulkan/Metal phones (which Epic makes little money off of anyway) might be a better decision than their current, laboriously slow tacking on of a new features while trying to maintain backwards compatibility indefinitely.
Thank you for the explanation! I read somewhere that the lead tech of Arnold render engine is working on some rendering stuff for UE4. I am pretty exited of the potential results of his work on the engine. I have been working on UE4 for 3 years and the old lightmass and the deffered rendering limitations has made my life really difficult.
Last discussion with Epic: No plan to support GPU lightmapper, you can use it but it’s not an Epic project (just project from an Epic employee). I hope they are going to change their mind about it, but apparently they have a lot of work on new things comings about rendering. and Epic policy is “We’re not supporting what’re not using in our projects”. Starting normally a little bit with 4.22 and should be finished few version after. I’m not talking about ray trace. I hope we’re going to say good bye to deferred renderer and have an official communication in few month to talk about it.