Simple scene takes absurdly long to load

Question

I pinpointed this particular frame when clicking on a scene transitioning button on my main menu which apparently gets stuck for a whopping 13,7 seconds.....? I know the issue is the scene I'm transitioning to rather than any actions prior to it, since it boots in a similarly slow fashion when running it on its own, but I have no clue what could cause this kind of dip in performance. All the scene has is a scroll container with a vertical row of buttons and a background. The only script just has some generic signal functions for darkening the buttons' textures when held down.

Amarette

Answer 1

What are script functions _on_play_pressed and change_scene, shown by the debugger? Post the Control code.

Dixon

Answer 2

They don't have much to do with the issue, since the lag spike appears only when the problem scene enters the tree for the first time. _on_play_pressed uses the same scene transition function i use for other buttons that have to lead to specific scenes and the rest work fine.

I tried building another scene from scratch with the same nodes and elements as the one causing the massive processing time and nothing in the new one seems to be out of the ordinary? I'll continue replicating it tomorrow but I have no idea why the original makes the game shit itself when loading

Amarette

Answer 3

Update:
Turns out the file size for this scene is over 200MB. Why and how though?
The six button textures I'm using are 190KB to 270KB, and the background is slightly larger at 1.3 MB

Amarette

Answer 4

The size of the .tscn file is over 200MB?

Participle

Answer 5

odd. maybe post the code? There's gotta be something up.

Kaikaia

Answer 6

seems like godot thinks they're a problem but I can see why execution would run through those while the code doesn't do much. All good though, what's in the scene?

More specifically: what's in the tscn? Has godot serialised something to it that it shouldn't have, perhaps via 'Local to scene' or some other toggle? Open it in a text editor and take a look!

Dixon

Answer 7

This is all of it. During actual gameplay I'd have each button lead to a different menu but here I was just setting up modulation changes (I didn't want to add a slightly darker sprite for each button when clicked because it's a bit wasteful imo).
Is there a way to go through a tscn file outside of the editor to see what's taking up so much memory? There are no excess nodes/textures/shaders that could lead to this much bloat.

Amarette

Answer 8

Yeah oh my god um....... The original file has nearly 14 THOUSAND lines of text when viewed in notepad and correct if I'm wrong but it seems to have printed every single editor change message and all images as PackedByteArrays?

And in comparison the clone scene I created using the same nodes and assets (didn't directly copy and paste anything) has none of this and only contains 81 lines in txt... Seriously what the hell

Amarette

Answer 9

this might be a time to go to GitHub and maybe ask the coders.

https://github.com/godotengine/godot/issues

Have you tried perhaps rebuilding this scene in an earlier stable version of the engine? I know they're still ironing out kinks in 4.

Kaikaia

Answer 10

Can you use the clone scene and delete the one with the huge .tscn file?

an earlier stable version of the engine

Or use a later 4.x version. I don't think you stated your version.

Participle

Answer 11

Yep, that's what I'm currently doing to bypass this. thankfully it wasn't a hugely detailed scene and I can remake it in a couple minutes either way, so nothing has really been lost. Still wild that something like this can happen out of nowhere without altering any settings in either godot or github (desktop).
Also, I'm using 4.1.1.stable

Amarette

Answer 12

4.1.1.stable

There have been a lot of bug fixes since that version was released.

Participle

Answer 13

Update 2:

Ran into the same bloating issue when reconstructing the new scene, but I also managed to find the specific action which causes the file size to multiply by hundreds.
In the scene each button has three label objects using the same root LabelSettings, however to adjust the font sizes etc. I used Make Unique on two of them. I apparently picked the recursive option on one, which caused the massive jump in memory usage.

Before using Make Unique (Recursive):

And after:

Using recursive generates a PackedByteArray containing over 500 thousand characters, as well as hundreds of rows of cache data

Amarette