I’m new to the game world having been a high poly 3D artist for 20+ years. I am loving it! New challenges, instant gratification, and working on content for VR is an amazing new challenge.
Something I’m wondering about and haven’t yet been able to find anything solid on is large or complex scenery. I’m producing a series of technical tests in various engines to see where we want to go (“we” is an open-source collective working on behalf of the UK Government to ultimately assist various sectors begin their VR journey with no financial outlay, the UK Government will provide) and Unreal is winning hands down. However something that we are struggling with are scenes that contain a lot of instances. The lighting fails to build after a certain point even though in terms of poly count of material complexity they aren’t very complex.
Looking at games like Battlefield 1 or anything from Crytek ahas me wondering how these complex levels are created. I’m not looking for detailed answers, I’m happy to read books and watch videos and talk to people. We even have budget to talk to people.
An example would be a fairly small level, which I’m happy to share, say 1km square. It is one landscape mesh with a simple two-layer blend material on it using 2k textures (only albedo and normal). In that I’ll put in some static meshes and a series on foliage instances. It quickly goes form seconds to build to minutes to hours to getting to 0.72% and after 72 hours still being 0.72%. When I look at our test scenes and those that Epic show we shouldn’t have these issues! So we are doing things wrong, we just can’t work out what.
We even downloaded the GDC 2015 Kite scene content and created a small scene using nothing but that content, and after placing grass and some trees and the cliffs - bam. Another failed scene. I’ve tried everything Google reveals including turning off all shadows entirely.
So my question is, for scenes using more than the cube brush, what is the process? Again, happy to read anything I’m pointed at and if anyone is happy to meet (UK based) to share their opinions we have budget. Everything we find and create will be open source though, so only share if you are happy for it to be given back to the community.
The issue there is the amount of memory usage, large scenes, especially with foliage will use a ton of memory. While playing a game it will only load the things that need to be visible, so things like foliage are set up so that you only see the stuff that’s closest to you. For building lighting it has to load all assets and have enough memory to have all lightmaps in memory at the same time.
Big open world games can’t do that since it’s too much data, so they use some type of dynamic solution–the Kite demo for example uses entirely dynamic lighting so it doesn’t require building the lighting beforehand. The problem though with that is that you don’t get as nice of lighting, mainly because it lacks the nice bounce lighting (Global Illumination) that you can get with the baked lighting. A lot of games use some kind of simplified version of dynamic GI, but moving entirely to a dynamic GI system is the dream. The issue is getting good enough quality while also getting a good framerate. There’s lots of different systems out there, for example with UE4 you can use something called Light Propagation Volumes (LPV) but it is a bit limited in features and doesn’t have great performance and not very good quality either, but for some games it provides that little bit of bounce lighting that helps make a game more realistic. There’s also VXGI from Nvidia, which is available in a separate branch of the UE4 source if you want to try it out, it’s much more complete but isn’t super fast. Cryengine has SVOTI, but it’s still got some of the performance issues and other problems that dynamic GI systems have like light leaking.
Unity and Frostbite use a lighting system called Enlighten, which allows for high quality dynamic GI however it has a lot of drawbacks–it has to be built ahead of time so you still have the issues of memory and having to spend hours building a level (usually also slower than what you can do with the UE4 baked lighting system). And after that the only thing that’s actually dynamic is the lights, which you can move and change just fine, but no moving meshes can have dynamic GI and anything that doesn’t exist in the level at the time of building doesn’t get dynamic GI either.
Baked lighting for large scenes is hard, as Darthviper107 has said.
I have managed to bake lighting for a scene around 1km^2, but it took 2-3 rooms worth of computers at my university hooked up to the swarm agent to get it to work (we’re talking ~40 i5 4690k CPUs each with 16-32GB of RAM), and even then it took an unreasonable amount of time (several hours for a lighting bake with 1 bounce - not ideal).
It works, but the Swarm Agent stalls for most of it (if i remember correctly, it stalled at ~1-5%, then would suddenly be ‘finished’ a couple of hours later, then would take a further ~30 minutes to import it all back in to the host machine, all while being mostly unresponsive).
I would still recommend baked lighting over real-time (especially for VR), and if you wanted to go with the baked lighting method your best bet would be to break the scene up in to smaller levels and bake them out separately, then use World Composition to assemble your world, much like a traditional puzzle.
Yep, it’s hard, that’s why we at https://www.cloudbaker.art/ provide with machines with 144GB GB precisely to handle large scenes or scenes with a lot of big lightmaps, the only caveat is to have decent upload speeds and good download speeds.