[Really Important]Loading Level Streaming After Package take too much time


I need your help to resolve a problem that I have with the Node : “Load Streaming Level”
When I play on the editor, the level load and works fine in few ms. But after packaging my game, the loading time take 354.3 sec


I have a the logs if needed :
[link text][2]

This is very important because I have to ship it this thursday

Thank you very much for your help !

Hello erodann,

From looking at the log, the main thing that seems to appear is this warning that is repeated many times:

[2016.10.09-02.15.57:360][391]LogSoundVisualization:Warning: Get Amplitude does not work for cooked builds yet.
[2016.10.09-02.15.57:360][391]LogScriptCore:Warning: Attempted to get an item from array CallFunc_GetAmplitude_OutAmplitudes out of bounds [0/0]!

Have you tried removing your implementations of this function to see if it may make a difference?

Hello !

Thank you for your answer but it’s still not working. The plugin to get the Sound vizualisation could be the problem but why did Unreal implement a plugin which doesn’t work in Cooked build ?

If I unplug my blueprint with this special node, it looks the same problem, i’ll try to found other stuff to know why is it broken like unload the plugins …

If you have any idea, let me know :slight_smile:

Please build your game for Development if you haven’t already (as this next step will require it) and try taking a look at this post: Debugging and Optimizing Memory - Unreal Engine

Using memreport may be able to help us find out why this level streaming is taking so long. If you aren’t able to figure anything out yourself while looking at the information it gives, please attach the memreport file here and I’ll take a look.

Ok, it’s a big big file and to be honnest, i don’t find someXthing interessteing in it

by the way, the Texture memory pool is over 1 go and I don’t use the fix in the command to grow it. Do you think that it could be a problem ?

That does seem like it may be related to the problem. Could you try increasing the limit and seeing if that speeds it up? Please be mindful of your GPU’s available VRAM and try not to exceed it, otherwise you may experience some driver crashes from your graphics card.

If that does help, you may need to go through and work on optimizing your textures, as they’re taking up too much memory. Are you using the scalability settings while in the editor to lower the graphical settings? This could be part of the difference between your experience with PIE and your packaged game if so, as the packaged game will always be on the highest settings unless set otherwise.

Hello again

I have try with the Command on the begin play r.streaming.poolsize but it’s doesn’t change. Do I have to change it on the .ini ? The probleme is that this problem need lot of of texture and i’ll be playing on GT1080

It would be best the edit the .ini file. You can find more information about the different .ini settings you can set for texture streaming here: Texture Streaming in Unreal Engine | Unreal Engine 5.1 Documentation

In general practice, it’s better to set values in the .ini rather than with a console command if it’s something that will stay constant throughout play.

Ok i try to change in the ini from 160 → 2048 and nothing change :confused:
I have no idea how to fix it. Do you need something to help you to debug it ?

Thank you very much

The only thing I can think of at the moment to try debugging this would be to make a copy of your level and try deleting a bulk of things from the copy to see if it is the size of it that is causing these extremely long load times. I would ask you to share a copy of the project so I could take a look myself, but I’m assuming this project is massive in size, just by the content alone.

We haven’t heard from you in a while, erodann. I understand that this is past your deadline that mentioned in your original post, but are you still experiencing this issue? If so, was what I suggested in my previous comment of any help? In the meantime, I’ll be marking this issue as resolved for tracking purposes.