After I build lighting for my level (and it imports fine) I can’t save it. It stops at 57% and then - after a while - proceeds to crash.
The circumstances
I have about 200.000 grass objects as foliage. When I remove those, lighting builds fine (and is 15 times faster!). [I can not tell lightmass to disregard the grass.][1] When the grass is not deleted beforehand, lighting building takes way longer, the results are imported to the engine fine and I can look at them. However I can’t save the map.
While saving the map, those files are created. One file is created, filled up until it reaches about 2GB in size and then the next begins. Once the fourth file is “full”, the engine crashes. Whenever I save the map without lighting built or with lighting build, but without grass, the map takes up a size of 100MB, so maybe the issue has to do with this.
Can you post your dxdiag here so I can take a look? This can be found by going to your pc start menu and type cmd in the searchbar. Start the command prompt program and type in dxdiag. You can save this as a .txt and upload it here. Additionally do you have any distance culling set up on your foliage?
Hi ,
I uploaded the DxDiag.txt as an attachment.
However it caught my eye that “Intel HD Graphics 4000” is specified as Display Device. However, I have to graphics cards and the one I use for UE4 (GTX 660M) is mentioned much further down.
As for foliage: Yes, distance culling is set up for every type of foliage (trees, bushes, grass).
Do you have LODs set up for all of your foliage? We added static lighting for foliage meshes in 4.6, which saw an expected spike in rendering time when foliage was used. Additionally, it would be good to double check and make sure that the engine is not using the HD 4000 and is definitely pulling its resources from the GTX 660M. I doubt this is the root cause, however it is best to double check and be certain.
No it does not, however one of my coworkers just brought up an interesting thought. Can you check your disk space on your harddrive to determine how much is available to you. We’ve had some users in the past who ran into a similar error and the problem was a lack of harddrive space available.
My main drive has about 13GB left.
So when I built the lightmaps I closely watched the status of the drive. When it crashed, the drive had about 5GB left.
While I doubt this is the cause, I’ll clone the project and try building it on my other drive with more than enough space. Could take some time, however.
Try opening a blank project, then adding just a few instances of foliage and build lighting, does it crash at this point or is it only when you have a large amount of foliage present?
I experimented a little and it only happens with large amounts of foliage. In my specific experiment: 1 landscape and about 130.000 instances of grass foliage.
I built the lightmap a few times now and it seems like the problem is connected to the .tmp-files in the “Saved” folder I mentioned in the beginning.
When I try to save the map, I can watch the file growing in size. If it stays under 2GB, it gets deleted after saving is done and everything works fine. If it keeps growing and surpasses the 2GB limit, the engine crashes and neither deletes the .tmp file nor saves the map.
Are you using 4.6.1? If so, can you try to do this on 4.7 preview. There have been some significant updates to foliage and foliage lighting in the preview.
I’m a student and - after three months of subscription - signed up for the student developer pack on GitHub on Dec 1st. Sadly, they’ve been taking their time to process the request.
Since I’ve still hopes for GitHub to get to my request, I’d rather avoid re-subscribing at the moment.
“Right now we’re a bit backed up with Student Developer Pack requests so it may take some time before your educational discount request will be seen to. Have patience and we’ll get to yours as soon as we can.”
But back on topic: Can you reproduce the problem? Maybe if you could reproduce it, it’d make bugfinding and -fixing easier for you?
Ok, I tested it on 4.7 preview 3 to see if this crash occurs. Given the specs of my pc I determined to increase the amount of foliage to 560,000 to ensure that, if a crash would occur that it absolutely would happen. The machine did not crash, though it did end up using all 32gb of ram and slowed my computer to a grinding halt for long periods of time (I just got it to a point where I could move about again), but it did not crash. Given that you are working on a laptop with 12gb of RAM, I believe that the reason it is crashing is simply too much data for the machine to handle with the current foliage lighting that is in engine. My computer only lasted through the process I put it through because it has 32 gb and a gtx 750 video card, any less and it probably would have crashed from sheer data being transferred through lightmass. I would recommend drastically reducing the amount of foliage you are using to less than 130,000. If anything less than that works that is simply the physical limit of your current machine. If you absolutely must have 130,000+ foliage in your level, I would highly recommend reverting to 4.5.1 (if you have a version of your project available pre-4.6.0, as projects worked on in later builds are not backwards compatible with earlier engine versions) as static lighting did not build on foliage pre 4.6.
I did a double check and found that it was mentioned in the 4.6 release notes that the new lighting is ideal for small to medium levels, however it does not scale well with larger levels due to memory requirements, you can find more information on this here:
you mention to downgrade to a previous engine version to disallow the baking of foliage. But how does it look for the future? The current situation is definitely unacceptable for larger Projects. As mentioned in this Threadanswers.unrealengine.com/questions/153924/turning-off-static-shadow-receiving-for-foliage.html , we need a Solution to tell lightmass to ignore specific kinds of foliage etc. Does Epic already have some internal task for this, or could you open one?
While I don’t have any additional info currently, that is a fantastic idea and I have entered a feature request, UE-10390, to be considered by our development staff. Thank you for your request!