• Godot Help

  • Where do the various textures in the Debug Video Ram Monitor come from?

But if I reduce the screen size in project settings to 640x480 pixels the 1024x512 still appears in Video RAM
Where I can find information about this textures loaded?

    I will report as bug. I did a test and discover if you delete the environment and create another the large image 1024x512 disapper.

    Ah, so it's the default environment probe then, you can report it but I can already predict the reply saying it's not a bug and closing it. Perhaps you'll instead want to open an issue on documentation tracker asking someone to document this in an article related to optimizing project export/file size or such.

      "I can already predict the reply saying it's not a bug and closing it" I see this many times. I will try report.
      But in any way I will update here if I find more information. And if anyone discover more information please report here. We are a communit and any help is welcome.

      CristianoSimao The CSV file generated is also blank.

      It shouldn't be empty. In my case it looks like this:

      The "Resource Path" column is empty, apparently because these are embedded textures.

      Debug.zip

        The (an) engine creates various 'textures' that cannot be 'eliminated'. To some, you may have access through various channels, to others not. So, no idea about OpenGL ES but if it was OpenGL there'd be a default framebuffer created by the context, and possibly a number of others used by engine for rendering of various effects. A framebuffer can have various textures attached, colour- and depth- are usually always there, others possible. The OpenGL framebuffer has at least two pairs of such textures in OpenGL, a front- and a back-buffer (colloquially called frames sometimes). While one is being displayed, the other is being drawn to. In Vulkan the application can choose how many such frames there are in-flight, often times there are three of them in a ring buffer, so to support different display modes.

        Apart from that, there can be other textures, for rendering shadows (multiple levels possible), for a skybox (6 of them), the blue Godot wif hif teef fticking out, fonts and symbols in various sizes, and whatnot the engine might have in mind.

        tl,dr: It is not that you don't have nothing even in a blank project, as Megalomaniak said, at least there must be the possibility to show you the dark screen with nothing in it, and that needs textures and memory on the video card. Though I doubt the default framebuffer is being on display there, at least not if it is OpenGL.

        Edit: ninj'd, there you have the answer from the cracks, sky material, textures for font rendering, symbols. And 1.8mb is really not a big thing.

          16 days later

          After all the tips here and many research, I created a benchmark in a old mobile phone Samsung Galaxy J5 and every single byte of ram are very important for this type of hardware.
          The environment tip is very important, in the computer this is nothing, no difference, but in mobile this help a lot.

          Thanks for all help. And if anybody discover something to help speed the render and consume less RAM please continue reporting here.

          How can you expect to run a full 3D game engine, or even any sort of app at all, without using some memory? The question is illogical.

            12 days later

            cybereality
            I only wanted to understand what is consuming the "power" of the hardware, CPU or RAM. And for test this I need create things to meassure the CPU and RAM consumption.
            I started with nothing ... a black screen. And I expected that only little Bytes or Kilobytes of RAM will be used to do this...
            But I finded that Godot is wasting RAM memory with a unused environment buffer or texture, even if I disabled this feature. And only when I deleted this environment file removed this "bug" in Godot.

            Yes the RAM need by used, but in smart way and only when the user declare some variable, texture.. etc And the RAM can not be spend with things the Engine Develepers forget in the code (bugs).

            For people that have powerfull computers and powerfull mobile phones this little bytes is irrelevant, but for 50% of people in the world using old hardware, every byte of RAM is important and can not be spend in "bug" or "hidden features".

              I understand. I don't think this is a "bug" though, it is just default functionality of the engine. As the engine includes lots of features, some may take up memory or processing power, since they are commonly used in any game. I do agree with you that it's good not to have unnecessary features. But we are also talking about 2MB of memory, when phones these days, even cheap ones, should have at least 1GB. So it seems sort of like a premature optimization or looking for problems when there are none.

              This is simply a problem of expectations being wrong.

              There is nothing hidden or forgotten, there is no bug. A black screen is not nothing. There are tens of megabytes of video ram occupied that you're not aware of even for rendering a black window, not speaking of the program and it's data itself, a runtime environment, any loaded libraries the program needs etc..

              Just start your browser and watch the gigabytes (>3GB virtual, 400MB residual in case of firefox) it occupies without any user input and just displaying an empty file. The amount of memory you mention is negligible on every hardware except microcontrollers, and those don't run game engines these days.

              Btw., there are pretty heavy reasons not to optimize a program overly, or prematurely, and I certainly would put these numbers under that rule. Because a few gigabytes go away elsewhere (not shown in your list), and because with a new release this may all be moot and have to be redone, fixating dev power that would better be invested for the engine. One of the reasons why "premature optimization is the root of all evil" (D. Knuth). One can spend all day searching for a byte to spare and forget the actual program.

              Just my 2 cents.

              Edit: partly ninja'd :-)

              Just for reference, an empty text document (no file open, no text) in Gedit on Linux takes 18.9MB. An empty Godot 3.5 project takes 55.4MB. And Firefox (with no webpage open) takes around 218MB. You can also compare to a simple 2D game made in Unity, Celeste, which takes 370.4MB of RAM. Also, for reference, one of the most popular smart phones in Nigeria is the Tecno Camon 15 Premier, which has 6GB of RAM. More than enough to run all the apps I mentioned, many times over, with RAM to spare. So I don't see how shaving off a few bytes is going to make any material difference in the real world.

              When I created my "3D Pac Man" to test the features of Godot and to test the result in a old Android phone the game run ok in PC but at 10 FPS in the mobile phone.
              Then I started the investigation to discover if I did something wrong or if Godot can not create anything playable in mobile.
              Then I compared my game RAM consumption with the Playstation 1 hardware specs (2MB of RAM). My goal is create games with the Playstation 1 look and feel.
              Then I lowered the screen resolution to 800 x 600, after 640 x 480, after 360 x 240 and this showed very little progress in the FPS.
              Then I thinked the RAM from my phone is the problem, and started this post here in the forum. Ok I discovered the environment tip, but this also not helped increase the FPS significantly.
              Then after studying the RAM speed from Playstation 1, the RAM speed from my mobile phone, and the RAM speed from my PC, I understood that the RAM is not the problem.
              I discovered the triangle limit for my phone, discovered that Godot consume more vertices than necessary (a cube have 8 vertices, but Godot render with 36 vertices) and understood that makes the code easier to Godot developers. And discovered that the light in Godot consume very very CPU power.

              After correcting my code, my lights and my mesh to the limit of my mobile phone then my game run at 60FPS.

              But if I need add more things and this things surpasses the limit of the RAM speed of my phone, then the FPS will drop. And I would like to have some little more Kilobytes of RAM, then this is the case where each kilobyte of RAM is important.

                CristianoSimao a cube have 8 vertices,

                This is only true if it is a smooth shaded cube...

                CristianoSimao but Godot render with 36 vertices

                And this is flat shaded cube(with UV's1 but I don't want to over complicate this).

                It has 'hardened normals' as artists would call them, thus the polygonal faces have to be split. Which is to say the 6 faces of the cube can't share vertices between them since the vertex normals have to be parallel to each other per each face. Conversely on a smooth shaded cube the vertex normals are shared and are not parallel to the face normal.

                This would be best illustrated with an image, which I don't have at hand right now...

                edit: here we go. Check the first image in this polycount wiki article:
                http://wiki.polycount.com/wiki/VertexNormal

                Also see image in linked post here:
                https://forum.unity.com/threads/smooth-vs-flat-performance-which-answer-is-right.487865/#post-3181533

                1 cuts in UV's cause extra vertices too. A hardened/flat shaded cube without UV's would be just 6 * 4 = 24 vertices.

                    I am pretty sure those problems are not related to Godot and we're trying to optimize the wrong end. See, D. Knuth was all right, 50 years ago :-)

                    And don't forget that there are several ways to do a cube: immediate with 36 verts, indexed with 8 verts and 36 indices (triangles) or 24 indices (quads, deprecated I think), or casting rays and see if they hit a * x, a * y, a * z where a is the cube size and x,y,z its orientation vectors ... no this may be wrong, but well there is a functional representation for a cube that I am too slow after a couple of beers to deduce or look up :-)

                    These are not Godot specific issues. In any 3D engine, you cannot render a cube with only 8 vertices. This is because GPUs use vertices and indices, so if the faces have unique normals (as they would for a hard cube) then you will need additional indices to store the differing normals. But this gets into the premature optimization. You can run probably tens or hundreds of thousands of polygons on mobile, I think you are thinking about this too deep and looking at the wrong things.

                    Don't worry, my game is alredy optmized, runing at 60FPS.
                    Megalomaniak, I understand, what I am tryting explain is what Pixophir explained, Godot is using imediate mode in GLES2.
                    See the OpenGL ES 2 documentation page 18 here:
                    https://registry.khronos.org/OpenGL/specs/es/2.0/es_full_spec_2.0.pdf

                    Godot is using the option "C", other options will need more "organization" in the mesh. And is ok using option "C" I understand.

                    And now people can search in Google about this things and find here the information that not is in the Godot documentation and also not in the Vide Memory usage panel inside Godot. (I hope some day they fix this)

                    Thanks for all help and tips.