Sorry, just have to quickly mention it BUT, there is no realtime lighting solution in UE4 that really works with physically based shading! Yeah you can use LPVs, yeah you can use DFAO. However, none of those features has proper reflection support and PBS is impossible without reflections! Yeah…an outdoor environment with grass and trees might look okay with LPVs, yeah a castle might look ok with DFAO. But still, 90% of whats in Unreal 4s shading model wont work like that. So its (at least in my opinion) not usable at all. There are some tricks (like enabling diffuse from capture) but NOTHING provides the same reflection quality and ballance as lightmass. Cryengine for example was built right from the beginning with compensation for that in mind. Guess thats one of the reasons why it looks way better there compared to a dynamic Unreal 4 scene.
So honestly…saying use LPVs and DFAO is a wate in my opinion. Also, try building a large level with lots of moving foliage and tons of small environment props etc, enable DFAO and tell me how many ms you are losing^^ Last time I checked on our game at the office it was taking 18 (!!!) ms just for DFAO and another 12 for the LPV. Thats insane No one can make a game like that.
PS: If someone wants me to clarify some of these things more, just ask^^ But I dont want to spamm thread with more unnecessary info
Unless you are planning to make level build entirely from metal, polished marble or wood, glossy reflections are not big deal.
Actually overusing those reflections reminds me of days, when people overused HDR…
At his point I’d rather have dynamic lighting solution that solves one thing and solves is well. As of 4.5, DFAO on my scene eats up at least 10ms, which is unacceptable, LPV simply doesn’t work (enabling it eats 15ms).
So I’m left with stationary skylight, which somewhat acceptable and dynamic directional light without GI, which makes scene look quite flat.
I wonder how AO from NVIDIA GI works, would perform compared to DFAO ? On their papers it looks very acceptable (about 3ms), but they don’t say anything about scene size or complexity.
Edit:
I Understrand that DFAO is early in development, but I wonder if using voxels for AO wouldn’t be better, especially since the last voxel lighting in UE4 there have been some advancements in that department.
scene on my PC runs at about 65fps.
On average there is 1.14mln tris and about 2.4k draw calls.
Now let’s make everything dynamic. When I enable all fancy dynamic features (minus LPV, since it seems to be totally broken in 4.5), average FPS in the same scene drops to 40 (!!!).
In anycase I agree that everything can be solved if you just code right solution into engine. But not , can do so.
If engine would allow rendering plugins, which would essentially allow to replace parts of renderer, to another, or extend renderer to opt for using new things, that could solve some problems, by simply publishing right plugins on marketplace. And I dare to say those would be top selling plugins.
Though I still stand, that for fully dynamic lighting (not nessesarly fully dynamic geometry!) with big landscapes, there is quite a lot of work ahead for UE4 to be fully viabale out of box, especially compared to CryEngine.
And Lightmapping is not an option for big outdoors. I can agree that baking sky occlusion makes some sense, but that’s where it ends.
I’m really interested how it would work for big scenes.
There shouldn’t be much memory problem, since only static objects are voxelized, and not entire scene is voxelized only objects in certain range.
I am pretty new to UE4, but I did some lighting rendering tests with static lights last couple of days. I have not test full dynamic. If the difference isn’t huge, I am going full dynamic. No more lightmaps making/tuning & building lights.
The reality is making & tuning lightmaps/lightmass are chores & also not high value work, & take time off of making actual contents.
Haven’t people been doing that for months already? Also, there’s a forum post by Epic saying that they’re are trying to fix lightmaps (good luck, guys), so I don’t think it’s going away any time soon.
No you cant When you use fully dynamic setup, you should do 2 things first: set “force no precomputed lighting” to true and put “AllowStaticLighting=0” into console variables. Those settings prevent you from getting any reflections from either the movable skylight or reflection capture actors. At least in 4.4.3. I remember having builds before December QA where it worked when you disabled reflection environment lightmap mixing but that doesnt work anymore. You have the new option diffuse from capture, but sadly it then applies the diffuse GI from the skylight twice (codefix needed)
What about the ambient cubemaps? You don’t need to generate the cubemaps at runtime (you certainly can’t in CE). If you have a dynamic TOD you could generate the cubemaps at different times of day and interpolate between them throughout the day, Fox Engine style. Well, at least you could try. I know last thing I mentioned is impossible in CE but might be possible in UE4.
How is thread refering to Unreal Engine 4.5 when the latest version I have is 4.4.2 Are they gonna jump a few builds or how? My god, if continues, we will have Unreal Engine 5 in a couple of months ^^
im hoping for skin shader improvement as well, and the most thing i want is something with lightmaps to happen, either remove them or a more simpler solution, like cryeninges.
Just to make the point the Cycles render engine is open source even for commercial use, created by Brecht van lomel who just got persuaded to leave Blender development and go work for Arnold renderer. But the engine in there and ready for use, even for commercial projects at no cost. Dump lightmass, Integrate Cycles!.
Cycles even has a standalone code version now that doesn’t even need Blender to run. It’s a no brainer, As far as im concerned Lightmass should of never even been brought into UE4, it’s the weakest link in the chain of the whole code base right now.
That’s not how versions in software development works. it’s not going to be 4.4.2, 4.4.3, 4.4.4 -> up to 4.5.
First thing to know is that the “.” is not a decimal, it’s a separator.
Each number represent a type of release. The first being the major release, in case 4 as in Unreal Engine 4.
After that comes content patches/larger additions, in case 4.4 and soon 4.5.
The last number is hotfixes. So there won’t be more 4.4.X numbers unless they find something that needs fixing before 4.5.
And after 4.9 we’ll most likely see 4.10 and not 5. Unreal Engine 5 will be released when Epic see fit, not when they “run out of numbers”.
No one can make a game like that.
(codefix needed)