The really is that while currently there is no dynamic G.I, light mapping and light baking are already being done. That can be ported to the old consoles. For PC and high end consoles however, with dynamic G.I added the only downside is that the low end PCs would not have baked G.I if they disable dynamic G.I. Yes a game without both Dynamic G.I and baked G.I looks really bad! you know what other games look bad? all the games that utilize dynamic day/night cycle and are condemned to look bad because of not being able to have Dynamic G.I nor baked G.I, unless it’s a game with a clock that never moves. Imagine open world games with fixed time of day so we can have baked G.I.
But you know what’s interesting? other than Dynamic G.I, 4K and VR are also features that don’t work with old consoles and low end PCs either. But it’s still being worked on because if it was to worry about “old” consoles and “low end” hardware, nothing would advance. And having a game world with dynamic day/night and weathers cycle while supporting light bounces is as cool as playing in VR or 4K @60 FPS.
But really, why games that support dynamic day/night cycle should not have any sort of G.I? is that a lesser than low end PCs not having baked G.I?
If you can bake your lights, you should bake your lights. Nobody’s saying you should completely replace lightmaps with realtime GI by any means, we’re only saying that it should be an option for games that for one reason or the other can’t bake their lights or only do partial bakes. Even with VXGI and LPVs in the engine right now, if I’m making a scene with one of those, I’m not doing 100% realtime lighting, I’m baking down whatever I can because it runs better and if the light isn’t moving then it looks the same.
Realtime GI in this particular case is nothing more challenging to add to the pipeline than a checkbox on the handful of lights you want to have it and letting the system take care of everything. LPVs and VXGI both currently work like this, it’s all automated. There’s no additional time spent by the developer trying to support it or changing the art pipeline to make it work, it’s just instantaneous.
Thats what i’m saying, people should stop to think just black and white… More features and more tools in the engine means more possibilitys and options.
A: Very few projects need maps larger than the currently supported 4km. If you’re making something that needs that kind of size, you likely have a programmer on your team that can do something related to that for you (such as integrating https://github.com/EpicGames/UnrealEngine/pull/2359 ). While it would be greatly appreciated to have origin shifting in multiplayer, and while I have personally been pushing for that as well, it’s just not a that everything can benefit from. Also, on maps that have worlds that large, you need to use dynamic lighting anyway since you aren’t going to bake 20km or whatever of lightmaps, so large world support is largely held back by the current lighting system regardless.
B: Again, this is a system that even fewer games would be able to benefit from. The vast majority of projects wouldn’t be able to benefit from planetary terrain, that’s very specific to one type of game, where dynamic GI can be used for pretty much anything.
1: GI is good for every single scene you can think of, GI in general is just light bounce. Whenever you bake lights, that’s precomputing GI. Dynamic GI in particular is useful for any game with either moving lights (such as a sun, flashlight, a lot of emissive channel lighting, etc) or in a world with too many objects to realistically precompute (such as foliage lighting, or just large worlds in general).
2: Yes, it would. In a space game like Elite Dangerous, as you mentioned, a lot of that game is solely procedural content when the player gets there, meaning you can’t precompute the GI on those areas. Realtime GI would be the only way to get realistic lighting in that or any procedurally driven game. Even in Star Citizen, where a lot of that content is handmade, because of the realtime nature of the CryENGINE, the artists have to manually place a -lot- of bounce lights which largely defeats the point of having dynamic lighting to begin with. It’s not a question of whether or not Star Citizen will integrate SVOTI, only a matter of when.
3: Everything from the 600 series onward I’ve had successful tests with VXGI, although it’s only Maxwell (900 series) and newer that can run it at a good enough speed to use it on top of a fully completed scene. A large part of this is the way even the base UE4 handles dynamic lighting to begin with, hitting 60 FPS with a dynamically lit scene with things like vegetation even without VXGI is a struggle, as evidenced even further by the new SDK that just went onto the launcher as well as the UE4 Kite demo.
You can’t use realtime GI with baked lighting, with LPV you have to completely turn off precomputed lighting. Realtime GI is meant to replace baked lighting, that’s one of the primary advantages since that saves a huge amount of time where you don’t have to make your lightmap UV’s and spend hours building lighting.
Not true, LPVs only affect the lights you tell it to as a whitelist system (often the directional light). You can still precompute the skylight, point lights, and spot lights, combining the two . You do -not- have to turn off precomputed lighting to use LPVs. Realtime GI doesn’t necessarily need to replace baked lighting, it can be used combined with it if you so desire. It’s not the only way to do things of course, but it is an option.
UE4 can’t, you have to disable precomputed lighting to enable LPV. I don’t know of any engine that uses LPV and static lighting at the same time. And I can’t imagine it being possible to make it work properly, even if you have dynamic GI for dynamic objects I don’t think it could properly calculate with static lighting, unless the things using dynamic lighting are very separate and don’t affect each other.
In my current project that’s literally what I’m doing, LPVs/VXGI on the sun and everything else is stationary/static. As long as r.LightPropagationVolume=1 is enabled in ConsoleVariables.ini, it lets you combine the two. Give it a try, it works. Lighting is additive, having both systems combined works perfectly fine.
Then your lighting is wrong, it literally says you have to disable lightmass: .unrealengine.com/latest/INT/Engine/Rendering/LightingAndShadows/LightPropagationVolumes/
Yeah, if you both bake the directional light -and- have LPVs on at the same time it’s wrong since it’s doing the indirect lighting pass twice on that, but if the sun is set to dynamic then it’s fine. Lightmass doesn’t touch the directional light if it’s set to movable, it only does it once there. There’s nothing bad with combining the techniques, it’s just poorly worded on the docs.
If that somehow looks OK, that’s not a good workflow, you still have to do all of your lightmap setup and baking and you also take the performance hit on the lightmap memory for things that aren’t affected by static lighting much and you take a performance hit by using LPV. In any case, that isn’t a solution for the issues of dynamic GI. What people want is to not have to use lightmass at all.
It looks perfectly fine. If a light is set to dynamic, lightmass pretends it doesn’t exist, which plays just fine into the additive nature of lighting. Strange as it might sound, doing something like that doesn’t break any rules of lighting.
It all depends on the uses. If I have a map where there’s hundreds of lights and the only moving light is some sort of TOD on the sun, it’s going to be better by far for me to bake down the extra lights and only have that one light be dynamic with LPVs, as opposed to having every single light contributing to dynamic GI. LPVs don’t support every light type so it’s easier to demonstrate this with VXGI, but with VXGI if I have just the sun affected by it then my scene goes down to maybe 50 fps on my GTX 780. But, if I also enable VXGI on 9 additional spotlights in the scene, it drops down to 15-20 fps. It’s not VXGI’s fault, it’s just not viable to have every single light getting a GI pass on it with the way the system works. Having a hybrid approach to lighting however gets the best of both worlds, you can have as many static/stationary lights as you please and still have GI on anything important that’s movable.
You’re right, it shouldn’t be. Origin rebasing in multiplayer and dynamic GI are two functions that people have asked Epic to work on for years now, and because they’ve been hesitant to work on it now they’re starting to lose customers like that team. I think it’s very telling that the game started out being worked on in the UE4 and the team outright abandoned it for another engine when they saw how long these features were taking to even give consideration to. I sincerely hope this isn’t the start of more teams following in their footsteps.
Well, it’s hard to argue with that. Again, I’m on your side on this, I do want to see this added to the engine. My comment was more on the explanation as to why Epic is likely not focusing on it at the moment more than justification for ignoring it.
Epic clearly has their own direction that they want to go in with the engine. Features are largely only added as of late if Epic actually needs it for their own products and games, which of course is to be expected, even early on when they introduced the Trello board I remember them saying on the livestream that the amount of votes something got wouldn’t necessarily change its priority unless it was an overwhelming majority vote. However, I haven’t ever seen them until that point try to diplomatically reject a community contribution of someone taking one of the two most requested features and doing the work for them. I would be lying if I said it wasn’t upsetting to some degree, my only hope is that they’re working on their own solution and that would be the reasoning behind turning it down.
The troubling takeaway from that comment is
For any other they want to add to the engine, including the 16 bit precision normals and all that, they simply make it an option in the project settings on whether it should be done that way or not. Instead of going that route, the response seems to suggest that until Epic wants to make a game that would directly benefit from it, they won’t add a like that, which is of course not the ideal thing to hear from a company producing an engine that’s supposed to be versatile enough to work for any project.
Epic at least at the moment doesn’t seem to see dynamic GI as a priority at all, with how Paragon’s static lighting was presented it almost seemed like that was their response to saying they want it. I won’t say that runtime changes to landscapes wouldn’t be cool, in fact it would work really well with all of those procedural landscape shaders that keep popping up, but it is a fairly niche . It’s a cool , but still a niche one. I don’t see them considering it until both origin rebasing and GI are taken care of.
Possibly, but I still hold out hope. Epic brought us SVOGI all those years ago, and until now it’s been on Nvidia to progress the technology (VXGI is the result of Nvidia continuing to work on SVOGI) and of course Crytek with SVOTI. The engine was originally built for dynamic lighting, and seeing a return to that focus would benefit both the workflow of designing levels and the games themselves. Prebaking lighting isn’t a universal solution for every single game, and I hope that one day Epic will have a project that needs it so it finally happens. Maybe it’ll happen once Epic gets off the VR bandwagon in another year or two, that seems to be where they’re focusing all of their effort at the moment.
I believe though with VXGI you can have as much emissive lighting as you want so in a lot of cases you could use emissive materials for lighting rather than actual light actors.
Yes, you can. VXGI supports emissive lighting and updates it per frame just in case it’s animated or anything like that. I find though that regular spotlights and such give you more fine control over it when it’s possible to use them. Also of course, if you base your entire scene on nothing but emissive lighting and the player turns off VXGI in the options menu, then that’s the one case where you might start running into some problems since there are no real lights in the scene to take over.
If you want to be able to support both older spec systems and newer ones, honestly just use standard lights the way you normally would for the majority of things. It’ll look the way it normally does for without VXGI on, and for with VXGI on it’ll look even better.
When systems like VXGI become more common, then yeah it’ll be -amazing- to have every single light in the scene dynamic, area lights, with GI on all at once, but for the time being it’s better just to be selective where the effect is used.
After finding out that neither HISMs nor foliage work on mobile, I kind doubt real-time GI should be a priority, when core features don’t work on all platforms Reminds me of Blender development, when exiting core features are incomplete, yet devs trying to put out more new features, just to leave some of them half-***** until God knows when.
No, I just made a system that perform at 10FPS of difference from a normal scene. Something no one GI system can give me. But probably the best GI system I tried is this one http://www.sonicether.com/segi/
Reminds me of Blender development, when exiting core features are incomplete, yet devs trying to put out more new features, just to leave some of them half-***** until God knows when.