I have a problem with baking lightmaps for large objects in my scene.
Changing the lightmap scale of the renderer doesn’t help. When setting everything to “baked” and building my lightmaps, the process gets stuck at “7/11 Light Transport 1 job”.
I’m not even sure if anything happens from there on. It takes forever and my iMac starts to heat up.
I attached a small test project with only one object.
Maybe someone can help me out here?
Got this slow lightmapping problem then one huge mesh (floor ~50x20m) affect (with his GI) many smaller meshes - compile time is insane slow (4+ hrs on 4.7Ghz Core i5 2500K). After splitting this large mesh in 26 parts - lightmap compile time drops to 15-17 minutes. Bad way to work, but that’s all i’ve got to speed up this process…
Yes, i’ve noticed the same thing. If i split up the big object into smaller ones it works.
There are visible artifacts though.
I’m gonna have a lot of big object (along with smaller ones) in my scene, so splitting up every big object is gonna be an insane amount of work.
same issue… medium level, big meshes… what would be finished in 15-20 mins with Beast seems to be going on forever with Enlighten (as in 10 hours later and not finished, says 7/11 Light Transport)
Same for me, splitting it up speeds up the baking but increases the draw-calls, this GI thing would be pretty nice if it didn’t take so much to bake, plus it often has artifacts when its done
There’s no need to split the object (unless you have got a poor shadow resolution).
To reduce the time process for huge objects you should create a specific Lightmap parameter for it. To do that:
. On the Project panel: → create → Lightmap Parameters.
. Rename the Parameter
. Set the Resolution to 0.01 on inspector.
. On the Lighting Panel with the object selected → on Object tab → Select your parameter in Advance Parameters
. Build
Generally Enlighten doesn’t really like huge meshes (as in: a single mesh that occupies a lot of texels) and indeed the Light Transport stage seems to suffer the most these days. Splitting up meshes into smaller parts (so that parts of the original geometry can just be culled when not in the view frustum) is a good idea not only for the GPU, but also for the parallelization of the precompute stage.
That said, please submit bug reports when you see precompute times that are unreasonably slow. We would especially appreciate projects where a scene has all the geometry as one mesh and another one where geometry has been split into mutiple meshes and the precompute is noticeably faster.
Thats a kind of info that belongs into the manual!
Trying to light map a 700 by 800 unit flat plane takes ages that way without splitting it up.
I hope Unity and Enlighten find a nice way that the user do not have to do she splitting itself (manual splitting on unity terrain is not possible that way).
Thanks. My i7-CPU was running at 93% @~138F degrees. I just put an end to that with your suggestion. My map is 7500x750x7500, it’s an all outdoors terrain, so with Windows>Lighting>Lightmaps, 0 - non-directional lightmaps(No Lightmaps) stopped the: Create Geometry/Layout Systems/Clustering/Visibility/Light Transport process completely.
Berkut can you plz explain this with more detail? Or someone who understood how to implement this?
I succeeded in adding “Lightmap Parameters” where the scene is kept (which I hope is what was implied here) but I didn’t find how to implement this setting on the actual lighting of the map, also couldn’t rename it either.
At least I found the “continues baking” option in the advanced lighting option and unchecked it , now the cpu load which was computing 53 assets all the time has stopped and cpu is happy.
Where to find the advanced lighting option:
On main unity window
Click window menu (It’s the drop down menu before help on unity 5.01)
Choose “Lighting”
On the new window that pops up - at the window bottom you’ll see “Continues baking” check box
I picked up, World Steamer, at the Asset Store but I haven’t really worked with it yet. I have one huge Island map, and have produced an OUT OF MEMORY ERROR, somehow. On a PC, looking at the crash in Task Manger it was using up more than 100,000 MB dump. That said, I don’t use the fancy lighting yet, too tricky, all real time, heavy on the GPU/CPU but I’m still working with the basics. Build crash, build crash, save once save often and always keep a backup of previous work. That’s my best noob advice. Just hammer and tongs a bunch of small projects until a couple of things start making sense. Every bodies games are different genres, different platforms, different audiences. So take lots of notes, start a blog, make some videos, and build a ton of half baked games. See what you like to build, and what you can build and go from there. That’s about as friendly as it gets. Take a jump over to http://www.onegameamonth.com/ It’s not all Unity, but it’s a bunch of indies making what they can with what they have. Take care, Scott.
I found that if you go into Window>Lighting>Objects>Terrain and turn terrain static off, it fixes the problem, however the lighting will go a little bit weird but you could simply re tweak it again.Another solution i’ve seen people mentioning is making sure there are no plane meshes over the scale of 16,16,16 because for some reason that can also crash it. Baked lighting can also be a big issue so if possible change them to real time. hope this helps!
Exqueeze me, but may we understand why that is? Why is Enlighten (STILL) so severely scale bound? Share with us the thought process and alleviate the mountain of frustration. Just think “what would Valve do?”.
Should we just take that as Unity’s current tech only being able to bake small scenes and being unusable in open world scenarios?
If you make a “large” mesh’s scale in lightmap 0.001, it can either not be enough for usable shadows, either it will still be too large and take forever or not finish baking at all, so, unusable.
If you don’t explain yourselves, and also don’t solve it, then I’m just going to think “well id tech 5 has Megatexture for any and all geometry, what do you have? Cute pretty realtime GI for small stuff?”. Sorry for the venting, had to do it.
Progressive light transport simulations aspire a physically-based, consistent rendering to obtain visually appealing illumination effects, depth and realism. Thereby, the handling of large scenes is a difficult problem, as in typical scene subdivision approaches the parallel processing requires frequent synchronization due to the bouncing of light throughout the scene. In practice, however, only few object parts noticeably contribute to the radiance observable in the image, whereas large areas play only a minor role. Web Designing Training in Chennai | PHP Training in Chennai
I’m having the same problem as the thread starter.
So after one year, we are still at the same point?
That’s pretty bad, if you ask me.
And as Tudor wrote, the whole purpose of GI is to have a realistic ENVIRONMENT, read: LARGE MESHES.
You know, GI is launched to light ENTIRE MAPS, and of course you do not build entire maps out of small parts, as you would raise the number of drawcalls to impossible levels.
If I knew this, I would have stuck with Unity4, of which I own a license.
I think you should fall back and reintroduce Beast, if you can’t make this thing work, and I’m pretty sure EVERYBODY in the community will agree with this, put apart people that make small games with small maps, probably only for mobile games.
hope this helps!