Good reminder; that’s something I might forget to check. All sprites in the packed scene draw from two large textures, one which is the actual interface sprites, one which is an atlas of low-res examples of all materials which can be applied to objects in the world… but both are indeed set as VRAM Compressed.
I could only imagine it having to do with something related to how control nodes/3d sprites are handled then (or perhaps even packedscene itself?), but as @normalized said, it’s good to do a methodical check, removing nodes one by one to see if you can find something specific that causes the spike.
That WOULD be a method I would normally use, but we’re talking about a very complex object with a script spanning 833 lines of code just on its own, not counting the scripts attached to some of the child scenes. It would be difficult to remove stuff without the script breaking, though yeah, that would be one of my debugging approaches normally.
If the script itself doesn’t instantiate any parts of the object, then simply removing the script temporarily and then stripping the object of all the nodes could work.
You don’t need to run the script at all. In fact start by eliminating the script.
OR… this object is too complex to begin screwing around with haphazardly, but since I know it’s the instantiation of it which causes the lag spike, what I can do is create a new object and start copy-pasting nodes over without any scripts attached and instantiate that as a test until the lag spike finally appears…
That’s a big job though and I had other things I wanted to work on today so I’m going to leave trying that for tomorrow. I’ll post an update once I’ve had a chance to try that out. Thanks for the input so far, @normalized and @marcythejinx ! 
1 Like
Simply duplicating the scene and removing parts of the duplicate would do more or less the same. Also, source control is always recommended, so you can more easily go back to previous commits if something goes wrong.
1 Like
I’ve never actually learned how to use source control solutions; I have automated daily backups as well as manual backups I do to separate devices every few days. If/when a major disaster happens to the project, I can pull from a backup. I have also learned the hard way to NEVER save the project if any script errors are unresolved.
So was the lag registered by the profiler as a spike?
The instantiate() command called on the packed scene is registered as a 5 ms CPU spike every time, but the lag only occurs the first time and doesn’t register in the profiler at all, neither on the CPU or GPU. 
OK, I found the source of the lag spike, and… this one’s kinda hard to believe but I assure you, after some solid testing, this was it…
…not including a NON-double-sided Label3D in my shader pre-caching object.
My shader pre-caching object has a standard Label3D in it using the same font and everything as any objects in the game which use Label3Ds, and for the most part, they are all set as the default double-sided.
The editing box I showed here has a lot of complexity and some of the Label3Ds are designed to appear without adjustment to face the player, but I still wanted them to read correctly from either side they were aligned to, so there’s two, each rotated 180 degrees away from each other, both of which have their double-sided flag disabled…
…and THIS is what’s causing the initial lag spike during instantiation!
If I add an additional Label3D to my shader pre-caching object which has the double-sided flag cleared, the lag spike I was experiencing disappears entirely!
So yeah… Label3D nodes clearly have different initial processing depending on if they’re set as double-sided or not and that was the source of the lag spike this time around. I would have NEVER guessed that one. 
2 Likes
Glad you figured it out.
I haven’t seen this mentioned much, but I did find some cases of people having some performance issues with Label3D, haven’t looked into these in depth but it might be worth noting:
- Godot: How to Fix Label3D Performance Issues
- Label causing a lag spike when loaded into the scene initially.
If this is a consistent issue it might be worth filing an issue on Godot’s Github repo.
1 Like
So it is because of shaders after all.
Maybe…? The thing is, it happens on instantiate() with Label3D objects, as opposed to when the Label3D actually enters the scenetree and appears on screen. Whatever the case, it’s an internal thing tripping this up and it was just most-convenient to stick an initial load of both kinds of Label3Ds, one double-sided and one not, into my shader pre-cache object.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.