Where do the various textures in the Debug Video Ram Monitor come from?: Page 2

This is a READ-ONLY snapshot of the Godot Community Forums when TwistedTwigleg was the owner, which is hosted for archival reasons only. The current Godot Community Forums can be found here.

Some links may point to external websites, including the current Godot Community Forums. These websites are not associated with TwistedTwigleg.

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

CristianoSimao

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.

Megalomaniak

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's¹ 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

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

Pixophir

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 :-)

cybereality

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.

CristianoSimao

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.

Pixophir

I did not claim or imply that Godot renders in immediate mode.

I just mentioned a number of ways without referring to any specific software.

What I said is that the "problems" (if there are any) are likely unrelated to Godot. When debugging something with an already made up mind, it is unlikely to find the cause.

« Previous Page