They're hiding too much stuff in Bloom and Fog, I don't like that, and too many point lights being thrown around willy nilly, not to mention the high amount of Vignetting effect.
Also, I don't like the way they changed the lighting, and lack of self-shadowing on certain mesh, it feels like they tried to convey another atmosphere? Not sure if that is the best way to go about it.
With PRTs or something like Geomeric's solution. Lots of pre-process time but pretty flexible after its all computed.
By the way, Primal Carnage Genesis on PS4 use Enlighten, you can see the logo in the video.
Enlighten compute lightmap on the fly for the GI isn't it ? This still require s a second set of UVs...
The Frostbite 3 for BF3 is using enlighten too as the base of their lighting system (but they pre-compute some lighting information for the static environment). I'm wondering if BF4 still works the same way.
Fortnite uses day and night cycles and dynamically destroyed environments. So I guess that means Fortnite now has a loading screen between day and night and they rebake per day passed to account for the missing buildings and crap resulting in ridiculous load times. OR they use the cascade day and night feature they used in the Jungle GDC demo for UE 3.5, or, something, I don't know. EPIC WHAT ARE YOU DOING, TELL US
No realtime GI has been dropped from the engine. PC and Console.
Andrew Scheidecker who had been the person at Epic developing this left Epic in the middle of last year. And its also extremely computationally expensive.
That isnt too say that UE4 could never have it in the future, but as it stands now, its gone.
No realtime GI has been dropped from the engine. PC and Console.
Andrew Scheidecker who had been the person at Epic developing this left Epic in the middle of last year. And its also extremely computationally expensive.
That isnt too say that UE4 could never have it in the future, but as it stands now, its gone.
No realtime GI has been dropped from the engine. PC and Console.
Andrew Scheidecker who had been the person at Epic developing this left Epic in the middle of last year. And its also extremely computationally expensive.
That isnt too say that UE4 could never have it in the future, but as it stands now, its gone.
If this is true this is going to make me quite sad. Biggest new feature that I was pumped about.
By the way, Primal Carnage Genesis on PS4 use Enlighten, you can see the logo in the video.
Enlighten compute lightmap on the fly for the GI isn't it ? This still require s a second set of UVs...
The Frostbite 3 for BF3 is using enlighten too as the base of their lighting system (but they pre-compute some lighting information for the static environment). I'm wondering if BF4 still works the same way.
I'm sad to see that Voxels are not used anymore.
Enlighten needs a 2nd uv set, but it can generate its own, or you can feed it your own. Its not required to create a 2nd uv set by hand though.
Enlighten is pre-computed in every implementation as far as I know. From talking to the Geomerics guys and using similar solutions before its all pre-compute time and then its pretty flexible after that.
Of course, nowhere near as flexible as an entirely realtime solution like voxel GI.
Enlighten needs a 2nd uv set, but it can generate its own, or you can feed it your own. Its not required to create a 2nd uv set by hand though.
Enlighten is pre-computed in every implementation as far as I know. From talking to the Geomerics guys and using similar solutions before its all pre-compute time and then its pretty flexible after that.
Of course, nowhere near as flexible as an entirely realtime solution like voxel GI.
There seems to be some confusion that GI==dynamiclighting here...and the assumption that without it you have to fall back on lightmaps and baked lights again.
Or maybe I'm the confused one. I can't tell...if anyone is in the know, could you confirm/refute this:
If the new engine is still deferred rendering (and I'd read somewhere it was), or even --mostly-- deferred, then the restriction on the dynamic vs static nature of the lights comes down to the pixel complexity cost...and you wouldn't NEED lightmaps at all.
You just don't get the sexier auto-bouncing-of-light/voxel-lighting-on-moving-objects like the kind you see with the Enlighten tech.
Without the SVOGI it seems LESS likely that you'd need to fiddle with secondary UVs or to precompute a voxel tree(if it's similar at all to enlighten, which required some pretty particular secondary UVs and some hefty precomputing (baking) times) and without SVOGI we STILL would have an engine capable of hundreds/thousands of dynamic lights, even on consoles, with pixel instruction cost being the major thing to look for, performance wise....right?
No, you've got it pretty much right. I'm pretty sure the idea behind the SVOGI at least in UE4 was that it wouldn't require extensive pre-computation, however.
there are a lot of ps4 pc comparison pics going on here but I cant find anyone saying why it looks so different on the different platforms? have they just tweaked lighting angles and atmospheric settings now that they have released the ps4 video?
No realtime GI has been dropped from the engine. PC and Console.
Andrew Scheidecker who had been the person at Epic developing this left Epic in the middle of last year. And its also extremely computationally expensive.
That isnt too say that UE4 could never have it in the future, but as it stands now, its gone.
That can't be right, I got a response from Zombie Studios on their Youtube channel that they were implementing UE4's realtime GI in their latest builds of Daylight.
I'd like to get an official statement from Epic themselves.
There seems to be some confusion that GI==dynamiclighting here...and the assumption that without it you have to fall back on lightmaps and baked lights again.
Or maybe I'm the confused one. I can't tell...if anyone is in the know, could you confirm/refute this:
If the new engine is still deferred rendering (and I'd read somewhere it was), or even --mostly-- deferred, then the restriction on the dynamic vs static nature of the lights comes down to the pixel complexity cost...and you wouldn't NEED lightmaps at all.
You just don't get the sexier auto-bouncing-of-light/voxel-lighting-on-moving-objects like the kind you see with the Enlighten tech.
Am I mixing things up?
Lightmaps never realy were about the number of lights.
they were about baked shadows and fancy GI-bouncing.
so yes; no GI = back to baked lightmaps and all this last-gen stuff.
if they realy dropped the voxel GI-stuff i hope they atleast create a solution for easier implementation of enlighten.
That can't be right, I got a response from Zombie Studios on their Youtube channel that they were implementing UE4's realtime GI in their latest builds of Daylight.
I'd like to get an official statement from Epic themselves.
There is nothing that stops you from implenting voxel cone radiosity into your engine, its an entirely realtime affect so you can in theory throw it into UE3, UE4, Unity, etc.
Voxel GI isn't a technique that Epic invented or holds the patents to or anything like that as far as I am aware, so UE4 not shipping with it is not really that big of a deal. More than anything, Epic not shipping it with UE4 means its not fast enough for the current hardware cycle (keep in mind all the extra stuff you need to do when we're talking actual games and not simple tech demos, ai, pathfinding, animation, sound, physics, etc).
There is nothing that stops you from implenting voxel cone radiosity into your engine, its an entirely realtime affect so you can in theory throw it into UE3, UE4, Unity, etc.
This video is from some random dude who threw it into unity.
So really, if people are upset about UE4 not shipping with it, just add it in yourself (or find a programmer who is willing to do it).
BTW, just to give credit where credit is due, that random dude posts quite frequently on polycount as commander_keen. He's also made some really cool realtime GI systems for unity before like one that is based on the same system that Crytek uses in Cryengine 3, LPVs:
It just goes to further prove EarthQuake's point, though, that this stuff can be implemented by anyone. So, until we get official word from Epic that isn't vaguely worded like what we are mulling over now, its not confirmed. I happen to think that it made the cut, but even if it doesn't, I don't think there is all that much reason to fret, since their replacement will no doubt be much better than what we have had for this gen. Even offline lighting has advanced significatly.
And in any case, there is allwasy the potential for future or third party implementations of SVOGI.
Lightmaps never realy were about the number of lights.
False! In UE3, dynamic lighting was pretty expensive as everything used (what would now be considered) a fairly primitive forward renderer. UT3, Gears of War, and a large number of earlier UE3 titles (2009 and earlier) didn't use lightmass and didn't benefit from a GI solution at all.
BTW, just to give credit where credit is due, that random dude posts quite frequently on polycount as commander_keen. He's also made some really cool realtime GI systems for unity before like one that is based on the same system that Crytek uses in Cryengine 3, LPVs:
Ah yeah my bad, I knew that but forgot it was him, even better though that was implemented by a polycounter!
Lightmaps never realy were about the number of lights.
they were about baked shadows and fancy GI-bouncing.
so yes; no GI = back to baked lightmaps and all this last-gen stuff.
if they realy dropped the voxel GI-stuff i hope they atleast create a solution for easier implementation of enlighten.
That's where I think people are getting mixed up..Ambersee's a bit more technical than I am, so he can correct me if I'm misleading you here, but there are two sets of things that people are talking about in here and they don't overlap the way people are saying in this thread:
1:
Forward-rendered dynamic lights in UE3 (which heavily impacted draw calls and vert counts, iirc) VERSUS Deferred Dynamic lights in UE4
----AND---
2:
Baked radiosity/GI/lightmass in UE3 VERSUS this-now-abandoned Voxel-GI in UE4.
Dropping the Voxel-GI doesn't mean UE4 has also dropped the deferred dynamic lights...or deferred rendering..
With deferred rendering UE4 would, presumably, behave more like the Metro 2033 or Crysis engines. That is: no limit (except pixel instruction complexity) to the way you use the lights (animated, light functioned to all hell, changing with time of day, etc) as it's all dynamic anyway. It's just not dynamically *BOUNCING* light. You'd have to fake that yourself with hand placed lights (but they would not be static/baked).
Given the workflow common these days with deferred renderers, this would mean that a lightmap's role would be delegated to being purely a secondary bounced AO/GI map (perhaps as a supplement to all the dynamic lights in case you don't want to use SSAO)..or, more likely, just something they keep around for mobile games, web games, and other low-spec purposes.
I mean, there's plenty of good incentive for Epic to strip away lightmaps altogether as there's a ton of vert memory and texture memory savings to be had there and it's probably a painful thing to keep supporting with all these upgrades to the renderer.
If they're keeping lightmaps, I doubt that all Epic's graphics guys are entirely thrilled with the decision. And even then, if they're keeping the system, I'd be a bit surprised if it's still in high fashion this time 2 years from now.
But then lightmaps don't really mix with lots of dynamic lighting, right? Cause I would think that having lots of lights doing all sorts of crazy things would conflict with what you've baked. Or you could skip baking and just place dynamic lights where logically there would be a bounce light.
Also, what about something similar to Marmoset's HDR skylights with shadows? Will that be possible?
Yeah, in the past that was my experience with deferred renderers, Bigjohn--you just skip the baked stuff altogether --or you use it for VERY generic 'soft shadows in the corners' type of stuff...either way, you certainly don't lean on baked shadows for anything significant when you have "unlimited" dynamic lights.
Also, and this is just me personally but, being able to do crazy things with lights--or more importantly with the geometry itself (like, lots more dynamic geometry stuff) is much more compelling to me than baked shadows have ever been.
There is nothing that stops you from implenting voxel cone radiosity into your engine, its an entirely realtime affect so you can in theory throw it into UE3, UE4, Unity, etc.
Sorry but this is a bit of a simplification. There is multiple levels of implementation, features, and performance related. While I don't know how much UDK and Unity allow you to mess with engine internals, as long as an effect is not first class resident inside the core technology, you will always suffer a bit.
Most demos of the implementations done by 3rd party are static scenes, or small scenes.
If it was "simple" to pull off, don't you think they would have done it for PS4 as well? After all the PS4 hw specs are not too bad, and will be above average what most people have (especially given all the low-level access you have in consoles).
That doesn't mean you can't do it, but getting something like the whole Elemental demo going, is imo a different story.
Sorry but this is a bit of a simplification. There is multiple levels of implementation, features, and performance related. While I don't know how much UDK and Unity allow you to mess with engine internals, as long as an effect is not first class resident inside the core technology, you will always suffer a bit.
Most demos of the implementations done by 3rd party are static scenes, or small scenes.
If it was "simple" to pull off, don't you think they would have done it for PS4 as well? After all the PS4 hw specs are not too bad, and will be above average what most people have (especially given all the low-level access you have in consoles).
That doesn't mean you can't do it, but getting something like the whole Elemental demo going, is imo a different story.
Oh absolutely, I didn't mean to imply that it was easy to just throw it in, or that it was easy to get it running at a realistic framerate that would allow it to run on PS4, etc (the fact that Epic isn't including it for the PS4 build is very telling as far as performance goes).
Its also not something you can just enable or disable on your project either. You pretty much have to use it, or have to use something entirely different (lightmass, enlighten, etc). Once you've taken the time to implement one of these other solutions for lower end systems that can't run a Voxel GI solution, it makes very little sense to drop all that content just to go with a realtime GI solution for high end machines. So there absolutely is a lot that goes into it from an actual project development standpoint.
My main point was that it is a realtime effect that is well documented can be added by pretty much any skilled programer to a capable engine with enough access to the source. Is that incorrect?
That sounds like it makes sense to me, EQ. While UDK doesn't allow source access at all, full licensees of UE3/4 would have access to the renderer and thus could hijack it to do almost whatever they wanted.
Course, it probably wouldn't be just ANY skilled programmer...it would probably have to be someone well-versed in graphics stuff specifically.
It also sparked my curiosity about the future of companies like Blur Studio or any third party company mainly specialized in video game cinematics.
We're still ahead in quite a lot of stuff... AA and shading fidelity, hair, cloth, all kinds of VFX stuff, crowds, general scene complexity, matte painting integration etc.
Also, most of these AAA companies like Epic, Crytek, Dice and Naughty Dog haven't relied on CG for quite a while anyway; whereas the usual clients are most of the time a bit behind the curve in asset quality and engine capability.
Fully dynamic lighting and precomputed lighting are just two tools in our UE4 toolbox. We have games being made like Fortnite that are using fully dynamic lighting, no lighting build times, and the game has full flexibility to change what it desires at runtime. In the case of Fortnite, this is used to great effect with building and harvesting of resources. We don't yet have a solution for dynamic GI in the fully dynamic lighting path, this is something we hope to address in the future.
On the other hand, using precomputed lighting where you don't need dynamicness frees up a lot of processing power. The infiltrator demo that we released at GDC leverages this heavily. In short: we would have had to scale down Infiltrator massively without precomputing some of the lighting. There are over 1000 lights in some of the scenes, and about half of those cast shadows. Dynamic shadows have a huge cost on graphics hardware, but precomputed shadows are very cheap. Our general purpose reflection method (Reflection Environment) also relies on pre-captured probes. By having the general purpose reflection method be cost efficient, we were able to spend the extra GPU time on Screen Space Reflections, which provides extra detail where it is available (due to screenspace limitations). https://www.youtube.com/watch?v=-bLOi3mo9NE (watch in HD)
Now there are some workflow costs to precomputed lighting (creating lightmap UVs, build time), and this is something we hope to improve significantly in the future.
Precomputed lighting is also really useful for scaling down, to low end PC, 60fps, mobile, etc.
In summary: UE4 supports multiple tiers of lighting options, and games can use what suits them best. Fully dynamic lighting provides maximum interactivity, editor workflow and game design flexibility, precomputed lighting provides maximum quality and performance.
Let me know if you have any specific questions and I'll do my best to answer them."
Great to get thy all cleared up
now someone correct me if I'm wrong, I could use a ton of dynamic lights now and "fake" GI? I could control those lights via kismet and simulate GI in a day/night cycle?
biofrost - If its fully deferred, then yes, that's a workflow could you do in theory. But whether or not you'd be able to get it to look good on consoles depends on how efficient the instruction counts are in UE4.
For this up and coming generation of consoles any single pixel might -still- be limited to only a few hundred instructions (average) per pixel on the screen -- and that will include materials+FOX+lights+fog+postFX. In past deferred rendering solutions I've seen various light types cost anywhere from 30-70 instructions each...so, on low spec machines or on consoles you might be limited to only a couple of lights per pixel(or using simpler materials on your larger enviro objects, or dropping some postFX stuff, etc). You might just not have the instruction count for too many non-essential detail lights.
Cutting edge GPUs can push that number average-instruction-count up to like...1000+ and not bat an eye...and for your portfolio you could go hogwild, but this next generation of consoles aren't rumored to be all that beastly..
Most likely, but it would be a ballache to set up on a scene of any real size or complexity.
That is also very true--with prefabs you could expedite that somewhat... but it'd not be something you'd want to do everywhere in a large open world.
You could also use a lightfunction that used a gradient map that changed over time as the light's color/intensity, thus getting the same effect only reusable quickly. Course, adding materials to a light is a pretty straightforward addition to the instruction cost.
Well, it would depend on implementation of course. If the new dynamic lights rely on materials to define their falloff then they essentially already --are-- light functions (of a sort), behind the scenes, and it would just take some work to properly stack the additional light-function material.
But I've seen that exact scenario in the past (with UE3-turned-deferred, too) so I know it's DOABLE...but yeah, depends on what Epic prioritizes.
I wish tehre were more editor footage. I would love to see the whole engine presentation even in a off screen quality. Hopefuly Epic will release soething from their GDC presenation soon. I'm dying to see more in editor stuff. UE4 looks great so far even without SVOGI
Fully dynamic lighting and precomputed lighting are just two tools in our UE4 toolbox. We have games being made like Fortnite that are using fully dynamic lighting, no lighting build times, and the game has full flexibility to change what it desires at runtime. In the case of Fortnite, this is used to great effect with building and harvesting of resources. We don't yet have a solution for dynamic GI in the fully dynamic lighting path, this is something we hope to address in the future.
This statement seems to contradict itself. When they initially said fully dynamic lighting with precomputed lighting, I assumed that this is to do with GI (isn't any basic lighting done in real-time? It would be pointless to have to bake something that doesn't have GI unless its to do with only baking shadows).
Then he had to throw in the statement afterwards "we don't yet have a solution for dynamic GI".
Dynamic GI is not the same thing as dynamic lighting.
You can go back a page or so and see where myself and a few others were talking about it, but it comes down to deferred versus forward rendering. You have GI in the baked path because lightmass pre-calculates it. In the dynamic path, you'd need something like Enlighten or lightprobes, etc.--THAT'S the part they don't have. You';d have to fake it with hand placed lights, or by animating a skylight or etc.
Both paths have their uses, and their intended platforms.
dynamic GI was very lightly dismissed considering it could've been the one big gamechanger,
dynamic lightning in its current form can never achieve the amazing looks of prebaked lightmaps, and lightmaps could never replace the dynamic factor of dynamic lighting.
GI would've been the best of two worlds and it was the thing that made their first demo look so amazing.
Especially interesting since fortnite was exactly the kind of title that could use a realtime GI sollution.
Replies
It looked about 10 or 15 fps on some points.
Any body noticed ?
http://imgur.com/a/cuzjS#0
And for those that missed the article about SVOGI:
http://www.eurogamer.net/articles/digitalfoundry-gdc-2013-unreal-engine-4
They're hiding too much stuff in Bloom and Fog, I don't like that, and too many point lights being thrown around willy nilly, not to mention the high amount of Vignetting effect.
Also, I don't like the way they changed the lighting, and lack of self-shadowing on certain mesh, it feels like they tried to convey another atmosphere? Not sure if that is the best way to go about it.
Enlighten compute lightmap on the fly for the GI isn't it ? This still require s a second set of UVs...
The Frostbite 3 for BF3 is using enlighten too as the base of their lighting system (but they pre-compute some lighting information for the static environment). I'm wondering if BF4 still works the same way.
I'm sad to see that Voxels are not used anymore.
[ame="
Console: baked lights
PC: realtime GI
Is that correct?
No realtime GI has been dropped from the engine. PC and Console.
Andrew Scheidecker who had been the person at Epic developing this left Epic in the middle of last year. And its also extremely computationally expensive.
That isnt too say that UE4 could never have it in the future, but as it stands now, its gone.
If this is true this is going to make me quite sad. Biggest new feature that I was pumped about.
Enlighten needs a 2nd uv set, but it can generate its own, or you can feed it your own. Its not required to create a 2nd uv set by hand though.
Enlighten is pre-computed in every implementation as far as I know. From talking to the Geomerics guys and using similar solutions before its all pre-compute time and then its pretty flexible after that.
Of course, nowhere near as flexible as an entirely realtime solution like voxel GI.
There is no public source understand why you keep asking - its pretty obvious if you watch any ue4 demo released by licensees.
amd has moved their voxel technology to cryengine.
What do you mean by this?
Wasn't svogi developed by Nvidia?
In any case, there's no evidence of GI in Fortnite from the footage show thus far.
Or maybe I'm the confused one. I can't tell...if anyone is in the know, could you confirm/refute this:
If the new engine is still deferred rendering (and I'd read somewhere it was), or even --mostly-- deferred, then the restriction on the dynamic vs static nature of the lights comes down to the pixel complexity cost...and you wouldn't NEED lightmaps at all.
You just don't get the sexier auto-bouncing-of-light/voxel-lighting-on-moving-objects like the kind you see with the Enlighten tech.
Without the SVOGI it seems LESS likely that you'd need to fiddle with secondary UVs or to precompute a voxel tree(if it's similar at all to enlighten, which required some pretty particular secondary UVs and some hefty precomputing (baking) times) and without SVOGI we STILL would have an engine capable of hundreds/thousands of dynamic lights, even on consoles, with pixel instruction cost being the major thing to look for, performance wise....right?
Am I mixing things up?
That can't be right, I got a response from Zombie Studios on their Youtube channel that they were implementing UE4's realtime GI in their latest builds of Daylight.
I'd like to get an official statement from Epic themselves.
Lightmaps never realy were about the number of lights.
they were about baked shadows and fancy GI-bouncing.
so yes; no GI = back to baked lightmaps and all this last-gen stuff.
if they realy dropped the voxel GI-stuff i hope they atleast create a solution for easier implementation of enlighten.
There is nothing that stops you from implenting voxel cone radiosity into your engine, its an entirely realtime affect so you can in theory throw it into UE3, UE4, Unity, etc.
Check it: [ame="
This video is from some random dude who threw it into unity.
So really, if people are upset about UE4 not shipping with it, just add it in yourself (or find a programmer who is willing to do it).
http://maverick.inria.fr/Publications/2011/CNSGE11b/GIVoxels-pg2011-authors.pdf - whitepaper
playable demo: http://www.altdevblogaday.com/2013/01/31/implementing-voxel-cone-tracing/
Voxel GI isn't a technique that Epic invented or holds the patents to or anything like that as far as I am aware, so UE4 not shipping with it is not really that big of a deal. More than anything, Epic not shipping it with UE4 means its not fast enough for the current hardware cycle (keep in mind all the extra stuff you need to do when we're talking actual games and not simple tech demos, ai, pathfinding, animation, sound, physics, etc).
BTW, just to give credit where credit is due, that random dude posts quite frequently on polycount as commander_keen. He's also made some really cool realtime GI systems for unity before like one that is based on the same system that Crytek uses in Cryengine 3, LPVs:
[ame="
It just goes to further prove EarthQuake's point, though, that this stuff can be implemented by anyone. So, until we get official word from Epic that isn't vaguely worded like what we are mulling over now, its not confirmed. I happen to think that it made the cut, but even if it doesn't, I don't think there is all that much reason to fret, since their replacement will no doubt be much better than what we have had for this gen. Even offline lighting has advanced significatly.
And in any case, there is allwasy the potential for future or third party implementations of SVOGI.
I guess we'll find out soon, eh?
False! In UE3, dynamic lighting was pretty expensive as everything used (what would now be considered) a fairly primitive forward renderer. UT3, Gears of War, and a large number of earlier UE3 titles (2009 and earlier) didn't use lightmass and didn't benefit from a GI solution at all.
Ah yeah my bad, I knew that but forgot it was him, even better though that was implemented by a polycounter!
That's where I think people are getting mixed up..Ambersee's a bit more technical than I am, so he can correct me if I'm misleading you here, but there are two sets of things that people are talking about in here and they don't overlap the way people are saying in this thread:
1:
Forward-rendered dynamic lights in UE3 (which heavily impacted draw calls and vert counts, iirc) VERSUS Deferred Dynamic lights in UE4
----AND---
2:
Baked radiosity/GI/lightmass in UE3 VERSUS this-now-abandoned Voxel-GI in UE4.
Dropping the Voxel-GI doesn't mean UE4 has also dropped the deferred dynamic lights...or deferred rendering..
With deferred rendering UE4 would, presumably, behave more like the Metro 2033 or Crysis engines. That is: no limit (except pixel instruction complexity) to the way you use the lights (animated, light functioned to all hell, changing with time of day, etc) as it's all dynamic anyway. It's just not dynamically *BOUNCING* light. You'd have to fake that yourself with hand placed lights (but they would not be static/baked).
Given the workflow common these days with deferred renderers, this would mean that a lightmap's role would be delegated to being purely a secondary bounced AO/GI map (perhaps as a supplement to all the dynamic lights in case you don't want to use SSAO)..or, more likely, just something they keep around for mobile games, web games, and other low-spec purposes.
I mean, there's plenty of good incentive for Epic to strip away lightmaps altogether as there's a ton of vert memory and texture memory savings to be had there and it's probably a painful thing to keep supporting with all these upgrades to the renderer.
If they're keeping lightmaps, I doubt that all Epic's graphics guys are entirely thrilled with the decision. And even then, if they're keeping the system, I'd be a bit surprised if it's still in high fashion this time 2 years from now.
Also, what about something similar to Marmoset's HDR skylights with shadows? Will that be possible?
Also, and this is just me personally but, being able to do crazy things with lights--or more importantly with the geometry itself (like, lots more dynamic geometry stuff) is much more compelling to me than baked shadows have ever been.
Sorry but this is a bit of a simplification. There is multiple levels of implementation, features, and performance related. While I don't know how much UDK and Unity allow you to mess with engine internals, as long as an effect is not first class resident inside the core technology, you will always suffer a bit.
Most demos of the implementations done by 3rd party are static scenes, or small scenes.
If it was "simple" to pull off, don't you think they would have done it for PS4 as well? After all the PS4 hw specs are not too bad, and will be above average what most people have (especially given all the low-level access you have in consoles).
That doesn't mean you can't do it, but getting something like the whole Elemental demo going, is imo a different story.
Oh absolutely, I didn't mean to imply that it was easy to just throw it in, or that it was easy to get it running at a realistic framerate that would allow it to run on PS4, etc (the fact that Epic isn't including it for the PS4 build is very telling as far as performance goes).
Its also not something you can just enable or disable on your project either. You pretty much have to use it, or have to use something entirely different (lightmass, enlighten, etc). Once you've taken the time to implement one of these other solutions for lower end systems that can't run a Voxel GI solution, it makes very little sense to drop all that content just to go with a realtime GI solution for high end machines. So there absolutely is a lot that goes into it from an actual project development standpoint.
My main point was that it is a realtime effect that is well documented can be added by pretty much any skilled programer to a capable engine with enough access to the source. Is that incorrect?
Course, it probably wouldn't be just ANY skilled programmer...it would probably have to be someone well-versed in graphics stuff specifically.
We're still ahead in quite a lot of stuff... AA and shading fidelity, hair, cloth, all kinds of VFX stuff, crowds, general scene complexity, matte painting integration etc.
Also, most of these AAA companies like Epic, Crytek, Dice and Naughty Dog haven't relied on CG for quite a while anyway; whereas the usual clients are most of the time a bit behind the curve in asset quality and engine capability.
It does make stuff a lot more interesting though.
http://forums.epicgames.com/threads/950908-UE4-will-use-Lightmass-for-its-lighting-system!/page6
"Hey guys, rendering team lead from Epic here.
Fully dynamic lighting and precomputed lighting are just two tools in our UE4 toolbox. We have games being made like Fortnite that are using fully dynamic lighting, no lighting build times, and the game has full flexibility to change what it desires at runtime. In the case of Fortnite, this is used to great effect with building and harvesting of resources. We don't yet have a solution for dynamic GI in the fully dynamic lighting path, this is something we hope to address in the future.
On the other hand, using precomputed lighting where you don't need dynamicness frees up a lot of processing power. The infiltrator demo that we released at GDC leverages this heavily. In short: we would have had to scale down Infiltrator massively without precomputing some of the lighting. There are over 1000 lights in some of the scenes, and about half of those cast shadows. Dynamic shadows have a huge cost on graphics hardware, but precomputed shadows are very cheap. Our general purpose reflection method (Reflection Environment) also relies on pre-captured probes. By having the general purpose reflection method be cost efficient, we were able to spend the extra GPU time on Screen Space Reflections, which provides extra detail where it is available (due to screenspace limitations).
https://www.youtube.com/watch?v=-bLOi3mo9NE (watch in HD)
Now there are some workflow costs to precomputed lighting (creating lightmap UVs, build time), and this is something we hope to improve significantly in the future.
Precomputed lighting is also really useful for scaling down, to low end PC, 60fps, mobile, etc.
In summary: UE4 supports multiple tiers of lighting options, and games can use what suits them best. Fully dynamic lighting provides maximum interactivity, editor workflow and game design flexibility, precomputed lighting provides maximum quality and performance.
Let me know if you have any specific questions and I'll do my best to answer them."
now someone correct me if I'm wrong, I could use a ton of dynamic lights now and "fake" GI? I could control those lights via kismet and simulate GI in a day/night cycle?
biofrost - If its fully deferred, then yes, that's a workflow could you do in theory. But whether or not you'd be able to get it to look good on consoles depends on how efficient the instruction counts are in UE4.
For this up and coming generation of consoles any single pixel might -still- be limited to only a few hundred instructions (average) per pixel on the screen -- and that will include materials+FOX+lights+fog+postFX. In past deferred rendering solutions I've seen various light types cost anywhere from 30-70 instructions each...so, on low spec machines or on consoles you might be limited to only a couple of lights per pixel(or using simpler materials on your larger enviro objects, or dropping some postFX stuff, etc). You might just not have the instruction count for too many non-essential detail lights.
Cutting edge GPUs can push that number average-instruction-count up to like...1000+ and not bat an eye...and for your portfolio you could go hogwild, but this next generation of consoles aren't rumored to be all that beastly..
That is also very true--with prefabs you could expedite that somewhat... but it'd not be something you'd want to do everywhere in a large open world.
You could also use a lightfunction that used a gradient map that changed over time as the light's color/intensity, thus getting the same effect only reusable quickly. Course, adding materials to a light is a pretty straightforward addition to the instruction cost.
But I've seen that exact scenario in the past (with UE3-turned-deferred, too) so I know it's DOABLE...but yeah, depends on what Epic prioritizes.
http://www.gametrailers.com/full-episodes/oty460/next-tech-the-power-behind-unreal-engine-4
Are...are they doing instanced based reflection with lobes? What is this madness?! I-I-they-he-we-...
Seriously, more information cannot come soon enough.
Can you link me to some info on what your talking about?
This statement seems to contradict itself. When they initially said fully dynamic lighting with precomputed lighting, I assumed that this is to do with GI (isn't any basic lighting done in real-time? It would be pointless to have to bake something that doesn't have GI unless its to do with only baking shadows).
Then he had to throw in the statement afterwards "we don't yet have a solution for dynamic GI".
btw, light probes were introduced in Unity 4:
http://docs.unity3d.com/Documentation/Manual/LightProbes.html
Dynamic GI is not the same thing as dynamic lighting.
You can go back a page or so and see where myself and a few others were talking about it, but it comes down to deferred versus forward rendering. You have GI in the baked path because lightmass pre-calculates it. In the dynamic path, you'd need something like Enlighten or lightprobes, etc.--THAT'S the part they don't have. You';d have to fake it with hand placed lights, or by animating a skylight or etc.
Both paths have their uses, and their intended platforms.
Now if only they had dynamic NAVGEN....!
dynamic lightning in its current form can never achieve the amazing looks of prebaked lightmaps, and lightmaps could never replace the dynamic factor of dynamic lighting.
GI would've been the best of two worlds and it was the thing that made their first demo look so amazing.
Especially interesting since fortnite was exactly the kind of title that could use a realtime GI sollution.