I am working for some time on one scene, I am using few stationary lights, landscape and movable dominant light. Light build was always very fast. Today I added one short spline, just testing something and since that lightbuild considerably more time and in the end it get stuck at encoding textures (50%), see attached image. Is that really a bug? One more thing that is maybe worth mention, I was playing around with tessellation material a bit, but it is turned off at the moment.
It seems like it is foliage related, before I was using 4.5.1 and migrated project to 4.6.1… there shouldn´t be any static foliage in scene (grass), is there something that might have changed while migrating and that I should fix?
By no static foliage I mean that pretty much everything is dynamic.
Hi Ravendrake,
I just want to make sure I am following so that I can adequately reproduce this effect on my end. When you did not have a landscape spline, your lighting built without halting at 50% “encoding textures”, but once you added a spline component it no refuses to move forward with building? If you remove the foliage from the level does this error still occur? If so remove the spline mesh, does it still hang on encoding textures?
I am pretty sure it is all foliage related (spline has nothing to do with it). I mean it is related to change in 4.6 where light is baked on foliage, even tho there is no static light in this scene. Is it now baking GI or what? Is there way to turn that new feature off?
How big is the level you are working in? Additionally, what are your texture sizes and lightmap resolution size?
63x63 Quads, 1x1 section per component, 8x8 comp (overall 505x505 landscape). Texture sizes are nothing extreme, textures used on terrain are all 2048x2048 and on grass planes 1024x1024. Light map resolution was set to 64 after patch for grass (looks like it was autoset). Anyway if I delete all grass then it once again build really fast. So just: How do I turn off that new foliage light baking?
Hi ,
Do you have any LOD’s being used? Additionally for your grass planes it would probably be a good idea to drop the size down to 256x256 or even 128x128 if you can. How much foliage are you using on your landscape? Finally, how long were you waiting before stopping the build lighting process, it could be that it was taking a long time simply because it was processing a lot of data at once.
I need pretty detailed grass, I was using around 8k instances at the moment (but planes themselfs are kinda big, probably bit bigger than usually used, covering bit more space than expected). My issues is that everything was fine and fast before 4.6. I was waiting around 30 minutes at preview build quality and recently I managed to complete build with grass, but not sure how long it actually took. Result looks exactly same as in 4.5 but took significantly more time (I was able to build whole level in under minute and half in 4.5.
Hi ,
4.6.0 did introduce lighting for foliage meshes, which is probably a large part of the slowdown you are seeing and is to be expected. Make sure you are using LODs to ensure that the foliage is not all being rendered at the same time, which will help with the lighting build as well.
So I get it there is no way to turn it off? I mean I am not getting better results in anyway, just massive slowdown while building.
Unfortunately no, there is no way to turn it off at present time. If you were experiencing no slowdown during 4.5.1 it may be best to keep your project there until another build comes out that you feel would benefit your project. 4.7 did introduce some significant foliage changes, however I do not know if they will help with lighting builds.
I’m having the same problem on my MAC, Unreal 4.7.3. Stuck on 50% encoding textures.
No matter what I do, every time I click ‘Build’ it re-builds the lighting and re-encodes the textures, which at times looks like it will take hours (literally).
Is there any way I can see the output of these processes ?
And why aren’t the results cached ? Why are they done over and over ?
There is a short cache that is created in your root folder called the deriveddatacache. This data is encoded during the encoding textures process. The output can be viewed by going to World Settings>Lightmass Settings> advanced (dropdown arrow)>Lightmaps. There is a feature request to allow users to cache lightmap data so they can build specific pieces of lighting, however I do not have a timeframe of if or when this would be implemented.
Thanks, . That helps.
I see the DerivedDataCache directory. On my mac it’s /Users/Shared/UnrealEngine/4.7/Engine/DerivedDataCache. However, there’s only one file in there - Compressed.ddp. Is this right ?
My big concern is trying to understand the build / launch process. I have been working with the same demo scene I got off the marketplace and haven’t changed a single thing and yet every time I open it up both lighting is re-built (if I click on Build) and the textures are re-encoded …
It’s just disconcerting … Do you have any advice for trying to understand the asset-to-final-deploy pipeline ? I understand a few bits - like I understand that you need to take each texture and put it into a format that works on your target platform … Though the encoding process also happens when you switch the preview of the world view to HTML 5 / Mobile … And if there’s only one file in DerivedDataCache I suppose it would have to re-encode all the textures for each deploy then ? i.e. the encoded textures used in the world preview are overwritten, meaning there’s only space for one set of encodings for each texture ? Is this the case ?
I guess the best way to understand all of this is the source code … Though I suppose there must be some cues that would help. For example - Can I assume that everything that gets computed from clicking Build ends up in DerivedDataCache ? LightMass seams to be a separate module …
Anyway. Any kind of advice for figuring this stuff out would be very appreciated. Thanks for your time. I’m going to keep doing some digging on my own.
Oh, and regarding my question about the ‘output’ of the encoding textures - I was thinking more in terms of console output. Perhaps the encoding process is stuck at 50 % because of some kind of error that I can’t see on the front-end ? Using the MAC console logger I see the log file is producing messages like
[2015.03.18-18.50.09:529][717]LogTexture:Display: Building textures: LQ_Lightmap_1_25 (DXT1)
(continued)
Though perhaps there’s some way to get more information somewhere else ? Can I turn up the logging level somewhere in the source ?
Thanks again for your time. Regards
Not sure why my reply disappeared :
Thanks, . That helps.
I see the DerivedDataCache directory. On my mac it’s /Users/Shared/UnrealEngine/4.7/Engine/DerivedDataCache. However, there’s only one file in there - Compressed.ddp. Is this right ?
My big concern is trying to understand the build / launch process. I have been working with the same demo scene I got off the marketplace and haven’t changed a single thing and yet every time I open it up both lighting is re-built (if I click on Build) and the textures are re-encoded …
It’s just disconcerting … Do you have any advice for trying to understand the asset-to-final-deploy pipeline ? I understand a few bits - like I understand that you need to take each texture and put it into a format that works on your target platform … Though the encoding process also happens when you switch the preview of the world view to HTML 5 / Mobile … And if there’s only one file in DerivedDataCache I suppose it would have to re-encode all the textures for each deploy then ? i.e. the encoded textures used in the world preview are overwritten, meaning there’s only space for one set of encodings for each texture ? Is this the case ?
I guess the best way to understand all of this is the source code … Though I suppose there must be some cues that would help. For example - Can I assume that everything that gets computed from clicking Build ends up in DerivedDataCache ? LightMass seams to be a separate module …
Anyway. Any kind of advice for figuring this stuff out would be very appreciated. Thanks for your time. I’m going to keep doing some digging on my own.
Oh, and regarding my question about the ‘output’ of the encoding textures - I was thinking more in terms of console output. Perhaps the encoding process is stuck at 50 % because of some kind of error that I can’t see on the front-end ? Using the MAC console logger I see the log file is producing messages like
[2015.03.18-18.50.09:529][717]LogTexture:Display: Building textures: LQ_Lightmap_1_25 (DXT1)
Though perhaps there’s some way to get more information somewhere else ? Can I turn up the logging level somewhere in the source ?
Thanks again for your time. Regards
Since I first started writing the reply over an hour ago till now and it’s still encoding textures. So my first question is regarding why the building is taking place at all. And the other for why it’s so slow on my mac.
For the second I think I might have found a kind of answer in the source code : TextureDerivedData.cpp (where the encoding happens) starts with a, well, namespace called TextureDerivedDataTimings which seems to be to determine what is taking so long … Though I’m not sure where to see it’s output.
Also, regarding the first about why it keeps happening - It looks like in the source the textures are encoded according to both settings and target platform. So I’m not sure why it keeps happening … Will keep digging …
There’s a DumpTimingsCommand on line 77 but it doesn’t look like it gets called anywhere from the source …