Godot: Ability to see how much RAM and VRAM a particular scene utilizes in the Debugger.

[jonbonazza]

If i have, for instance, a tilemap scene that is loaded (via load or preload) but has yet to be instanced,
I am trying to answer the question of what I can expect the memory footprint to be like. How much additional memory is used per instantiation? Im working on a level streaming system and trying to balance memory usage with speed.

I would like the ability to see the resource utilization (in particular the RAM and VRAM usage) of a given scene (perhaps by ID or tree position?) in real time.

[Zylann]

Depends on what you load, I think Godot loads the properties to set and their values, which means resources it references also get loaded. Just nodes aren't created. You could profile it to be sure.

[vnen]

This depends a lot on the scene and the context. As said, referenced resources also get loaded. But if they are already in memory, they won't be loaded again. I don't think there's anyway to predict that.

When you instance you create new nodes, so they'll have their place in memory. The amount depends on which and how many nodes are added.

[eon-s]

If you can change the OP for asking for a way to see the memory footprint of a selected object (by ID?) or tree branch on the debugger, this could be a nice feature request.

[jonbonazza]

@eon-s I will do so in a few when i am on a computer. Can't find a way to do it on the mobile site.

@vnen glad you chimed in because in my testing and in my particular use case, the scenes in question will be TileMap resources loaded via your Tiled plugin.
With these scenes in particular what information is loaded when the resource is loaded and what information is loaded at instantiation?

I did some testing last night and found that in my relatively simple tilemap of 640x480 pixels using 16x16 tiles, each instance took about 5MB of VRAM and a majority of the time from file to full render was spent on instantiation rather than loading. In fact, if i cached the resource and never reloaded it, there was only a mostly negligible increase in speed at which a tilemap became fully rendered.

[vnen]

Instancing takes time likely because it's deserializing/constructing objects. I don't think the actual memory allocation is the problem. If you're doing level streaming, then the instantiation should happen in the background as well.

[jonbonazza]

@vnen
Yea, I guess I'm mixing two topics here, so apologies for that. At any rate, before I take things back on topic, I thought that I would point out that doing the loading AND instantiation off the main thread yielded this: https://www.youtube.com/watch?v=24GKJjwE6DA (which is how I was doing it originally). You'll notice that instancing is slow and builds up overtime. Interestingly enough, if I do the loading off the main thread, but do the instancing ON the main thread, I got this: https://www.youtube.com/watch?v=l74hjrm39_k

In the latter case, the instancing is practically instant. The latter is ideal and how I will stick with it, but would still be interesting to understand why it works out that way. Cheers!

[AndreaCatania]

In the VRAM is allocated all information required to show that object. In case of a mesh for example the VRAM contains all points, indices, normals, tangets, etc... These info are also stored inside the object itself. Ideally by checking the size of a mesh you can know how much VRAN it will take.

[Calinou]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!