3D performance on mobile sucks. Gridmap/Long models?

pegasusearl

tldr below.

Jesusemora performance optimizations are not limited to a platform.

From what I heard, mobile is different. Buuuut,.. I don't know.

Jesusemora Gridmap is not a voxel, it just draws the meshes on the screen, this means each mesh has its own transform, it just makes it easier for the artist to make the level.

I never think it was voxel, I treat them like tilemap, and yes I used it to simply line them up. Hopefully, there are wacky optimization under the hood if I used it instead of regular MeshInstance.

I plan on optimizing it by doing a manual culling. I have an assumption that Godot will automatically not render thing outside of the screen, that's why I never bothered. I will still render as minimal of meshes as possible.

Jesusemora I suppose you are using area3D with meshInstances? and not rigidbodies, or, worse, moving static bodies?

Yes it's Area3D with MeshInstances. Wouldn't rigidbodies be heavier?

Jesusemora something this simple you don't need collisions.

I need them, it's easier/faster to make and with not much CPU impact. And that's before I reduced my physics fps to 10. If I remove the terrain, the game will run 60fps in a potato so it's fine. With Area3D, the only math I have to do is predicting character landing on the moving platforms. Time is money and I didn't get paid enough.

I felt like you underestimate how Crossy Road make their game play smoothly (not the performance but how it plays), which is what I did in the beginning when thinking that tile based movement is enough. Or maybe you are thinking about something else, if yes then I apologize for the assumption.

Jesusemora polygons (triangles) must NEVER be smaller than 1 pixel. this is why your meshes should be optimized and why we have LOD.

Jesusemora 1 - make sure the triangles are not smaller than 1 pixel on screen.

WOWOWOWOWOWOWOW
THIS could be my ticket to Victory.

This part would have really small triangle wouldn't it? Maybe it's this one!! These small triangle only exist on my terrain. Especially with that camera angle.

I will pass it to my artist and see what he can do about it. I WILL WHIP HIM IF I HAVE TO.
I hope this will fix our performance.

Jesusemora there are many optimizations that were made in godot 4.

We started with Godot 4 but had issues with shared array buffer. We are having hard time implementing the game to our client's app. When we moved from Godot 4 to Godot 3, we actually see performance improvement, but with a little buggy rendering.

Jesusemora are you using GLES2?

Yes

Jesusemora 5 - it would also be a good idea to use gles3. gles2 is very old.

My boss said he got even worse performance with gles3.

Jesusemora 6 - make sure textures are set to VRAM compressed and I think you have to use ETC compression (read the docs). don't use the textures in lossless mode for 3D.

We use lossless, and will continue to do so. VRAM compressed just messes with the texture color. It added grey bits too. It supposed to have kinda pixel art like style, color need to be sharp and accurate, and vram compression ruins it.

Jesusemora and when it goes out of the screen, don't remove it, instead, transport it back to the start to be reused. you can keep these meshes in memory, it will be cheaper than creating them again.

I did this for the car and platforms. Our result is,... performance doesn't improve at all. I'm assuming because it's a CPU and Memory thing. And we have many extra CPUs in our pocket.

==================================================

tldr: the change that makes sense in our case is the tiny triangle. I will post an update when we implemented it.
(It would probably take really long time, our 3D artist can't use blender, they use qubicle/magica voxel)

Thank you for your reply, it gives ~~my life meaning~~ something I could try.

Jesusemora

pegasusearl sorry for playing doctor house, I always assume the worst, and works most of the time. It's nice meeting someone who knows what they are doing.

pegasusearl Jesusemora performance optimizations are not limited to a platform.

From what I heard, mobile is different. Buuuut,.. I don't know.

yes, there are optimizations specifically for mobile, but what I'm giving you is something very general to 3D. Most of what I've written I read in sites like polycount or experienced first hand.
I've also read the docs and skimmed through them again for this post, there are notes on top of notes when it comes to old hardware and mobile, and we should probably listen to them.

pegasusearl I never think it was voxel, I treat them like tilemap, and yes I used it to simply line them up. Hopefully, there are wacky optimization under the hood if I used it instead of regular MeshInstance.

I've always been distrustful of it. there is a guy who made mini-levels of his game and he ported his game to mobile, I haven't played it but was tempted to just to see how well it could run.

pegasusearl I plan on optimizing it by doing a manual culling. I have an assumption that Godot will automatically not render thing outside of the screen, that's why I never bothered. I will still render as minimal of meshes as possible.

there are many layers to this. what godot doesn't cull are animations, which you don't seem to have many of, but I've seen improvements in performance by disabling AnimationPlayers.

pegasusearl Yes it's Area3D with MeshInstances. Wouldn't rigidbodies be heavier?

you are doing it right then.

pegasusearl I need them, it's easier/faster to make and with not much CPU impact. And that's before I reduced my physics fps to 10. If I remove the terrain, the game will run 60fps in a potato so it's fine. With Area3D, the only math I have to do is predicting character landing on the moving platforms. Time is money and I didn't get paid enough.

I find that physics tends to be the bottleneck in games. disabling all physics tends to improve FPS. and if you need physics there's also servers, which are very fast.
but if it's not giving you trouble, you can keep them the way they are.

pegasusearl I felt like you underestimate how Crossy Road make their game play smoothly (not the performance but how it plays), which is what I did in the beginning when thinking that tile based movement is enough. Or maybe you are thinking about something else, if yes then I apologize for the assumption.

No need to apologize, I am the one assuming things.

pegasusearl This part would have really small triangle wouldn't it? Maybe it's this one!! These small triangle only exist on my terrain. Especially with that camera angle.

I don't think it will instantly fix your fps, but it will certainly help.

pegasusearl We started with Godot 4 but had issues with shared array buffer.

yeah, I think they are removing it in 4.3?

pegasusearl We use lossless, and will continue to do so. VRAM compressed just messes with the texture color. It added grey bits too. It supposed to have kinda pixel art like style, color need to be sharp and accurate, and vram compression ruins it.

from the docs:

Lossless Compression: This is the most common compression mode for 2D assets. It shows assets without any kind of artifacting, and disk compression is decent. It will use considerably more amount of video memory than VRAM Compression, though. This is also the recommended setting for pixel art.

VRAM Compression: This is the most common compression mode for 3D assets. Size on disk is reduced and video memory usage is also decreased considerably (usually by a factor between 4 and 6). This mode should be avoided for 2D as it exhibits noticeable artifacts.

also this for gles2:

Mipmaps

When pixels become smaller than the screen, mipmaps kick in. This helps reduce the grainy effect when shrinking the textures. Keep in mind that, in older hardware (GLES2, mainly mobile), there are some requirements to use mipmaps:

Texture width and height must be powers of 2

Repeat must be enabled

Keep in mind the above when making phone games and applications, want to aim for full compatibility, and need mipmaps.

When doing 3D, mipmap should be turned on, as this also improves performance (smaller versions of the texture are used for objects further away).

also, when using 3D the textures are set to sRGB, so the colors are changed. this is more a problem with the textures if they were made in linear color or with a color profile.
you can also change the colors from an environment node, like the color correction.

pegasusearl I did this for the car and platforms. Our result is,... performance doesn't improve at all. I'm assuming because it's a CPU and Memory thing. And we have many extra CPUs in our pocket.

how many materials are in the scene? and are the objects individual nodes?
having too many materials could cause performance issues, as each material will need a turn to send its uniforms to the gpu.
and the problem with removing objects is they exist in video memory as static, removing them means deleting them from memory and then sending them again, and static memory is not supposed to be touched often.
so pack as many meshes as you can into single materials with "mini-mega-textures". for example, your car has a car texture that is, say, 32x32 pixels in size, and you have 3 other cars with their own textures. well, instead of using 4 materials, use 1 material with a texture that is 64x64 pixels, and either use 4 meshes, or 1 single mesh and shift UVs.
and then pack as many of the textures into one big texture.
the artists can also reuse parts with this method, resulting in many variants of an object using a single texture.

Jesusemora

GorEldeen I think the problem could have to do with NOT using the recommended options for performance.

pegasusearl We use lossless, and will continue to do so. VRAM compressed just messes with the texture color. It added grey bits too. It supposed to have kinda pixel art like style, color need to be sharp and accurate, and vram compression ruins it.

pegasusearl My boss said he got even worse performance with gles3.

It's a mobile game, you can't expect the graphics to be perfect, there has to be a compromise somewhere.
and by the looks of it the team is very inexperienced. who knows what else they are doing wrong.

GorEldeen Godot was designed and focused on 2D games, the 3D renderer got added later, and probably caused conflicts with the core engine code, that's why Godot 4 was planned, they have rewritten the engine to they could fix all those bugs and make 3D well-integrated with the engine.

godot is a modern engine, designed with vulkan in mind and with some opengl support. we never heard what his boss's phone was, it could be a very ancient phone for all we know. the requirement of gles2 and bad performance with more modern versions is a bad sign.

GorEldeen if you want the absolute mobile support, Unity could be a less hard pill to take

WRONG. I had to uninstall marvel snap because it grew too heavy and would block my phone. changing to unity is not a guarantee of improved performance. less so with modern versions.
modern unity is designed around HD and HQ, which requires modern hardware and is very unstable and heavy. legacy unity had better performance but it's being deprecated. and you make a game in a version of unity, and when an update comes out you are forced to upgrade and your game will stop working or not be recognized at all.
also, the unity fee. they got into legal trouble with fricking Disney, and the marvel snap devs decided to switch to godot. it's not a good idea to ever go to unity, ever. let it die.

GorEldeen another one is Defold, which has the basic 3D features, but it's an absolute BEAST for mobile performance and small game size, either you try one of those, or go through optimizing your game as much as possible for it to work on Godot 3.

This one I know nothing about.

pegasusearl

Jesusemora I don't think it will instantly fix your fps, but it will certainly help.

Yea it didn't fix it. I tested by replacing the terrain with godot's built in plane mesh with just one color.
I just got the result.

Without terrain:

With terrain:

The result is almost the same as before. I don't get it, why is it only the terrain?
The other gridmap (obstacles) has more materials, more vertices, and more of them but it's very light.
The vehicles and platform combined also is more and they are moving.

The only difference about terrain is that, they are wide/long. They are so wide that each edges went out of screen.

This mysterious puzzle is very confusing.

Jesusemora how many materials are in the scene? and are the objects individual nodes?

I'm not sure.
Each mesh type have it's own material (the setting is the same, only the texture are different). But for the terrain, even if they only use one material, performance didn't improve at all.

For total maybe it's 11 terrain + 6 cars + 21 landmark + 11 obstacle (unwalkable part in the gridmap) + player + rare enemies
so above 55 materials.

Jesusemora the artists can also reuse parts with this method, resulting in many variants of an object using a single texture.

I wish he can do that. We are at the mercy of qubicle and magica voxel, our artist can't model in blender. He doesn't even know what UVs are. And I also don't know how to combine these mesh to use 1 texture except with the help of TexturePacker3D.

With TexturePacker3D, we tried to pack just for the terrain to one texture (then used in one material), no performance improvement. We haven't tried to do it for all meshes since it didn't improve anything. TexturePacker3D only support fbx so it's also a pain to import. (meshes need to be rotated and scaled)

Maybe we will try it when we had given up on terrain.

We are all still focusing on this gridmap terrain thing because just like in the screenshot, the terrain is what prevent us from getting 60fps. At least that's what we believe.

Jesusemora

pegasusearl Yea it didn't fix it. I tested by replacing the terrain with godot's built in plane mesh with just one color.
I just got the result.

could it then be a rendering issue?
try exporting a single plane with nothing else and see what the performance looks like.

pegasusearl The other gridmap (obstacles) has more materials, more vertices, and more of them but it's very light.
The vehicles and platform combined also is more and they are moving.

the other thing I'm seeing is buffer shadows. buffer shadows work by rendering a depth buffer and then projecting it on the scene. so the scene is rendered twice.
you could try disabling shadows. if this works, replacing them with blobs could be a solution.

pegasusearl I'm not sure.
Each mesh type have it's own material (the setting is the same, only the texture are different). But for the terrain, even if they only use one material, performance didn't improve at all.

For total maybe it's 11 terrain + 6 cars + 21 landmark + 11 obstacle (unwalkable part in the gridmap) + player + rare enemies
so above 55 materials.

you could create a version of the game where you remove all materials, then assign 2 or 3 to be able to see (so it's not all white). and see what performance looks like.
materials should be saved in a materials folder, if they are not, it would be a good idea to do it. when you add a material to the mesh or override, you are creating a new material that is tied to the scene.

pegasusearl I wish he can do that. We are at the mercy of qubicle and magica voxel, our artist can't model in blender. He doesn't even know what UVs are. And I also don't know how to combine these mesh to use 1 texture except with the help of TexturePacker3D.

mmm, those sound sketchy, but the model in your screenshot doesn't look bad.
you can take the textures, pack them in an image software like gimp or photoshop. then in blender you can combine the meshes with Ctrl+J, then select each of the meshes, scale the UV to a fraction and move it into its part in the atlas.
alternatively, in the mesh material you can assign the atlas and then move and scale the UVs in each material. this last one would mean using multiple materials, but reusing the same texture. (I honestly don't know how godot 3 handles gl_textures and materials)

lawnjelly

Those numbers for drawcalls look fine, but I'm not absolutely sure offhand whether they are accurate for gridmap in GLES2. Gridmap may be pretty inefficient in GLES2 because it doesn't support instancing.

What you might want to try is the new MergeGroup node in 3.6, which can bake gridmaps at runtime, and can potentially render more efficiently.

Often a killer on mobile is fill rate, which you can test by rendering to a smaller screen and seeing if the frame rate jumps up (does your boss's phone have high resolution? what model is it?). It doesn't look like you should be using that much fill rate but maybe something is using alpha unnecessarily (transparency kills fill rate), or something like that.

Shadows is often another bottleneck, but it sounds like you may have tried switching this off. Maybe having the terrain not cast shadows is worth doing.

Usually the best thing to do to track down the problem is as you are already - switch on and off various parts of the game and figure out what is using the time. So for terrain, try merging (as above) and maybe try with a simple non-textured material and see if that affects frame rate.

GorEldeen

3D performance with Godot 3 was always a hassle for a long time, a reason behind this might be that Godot was designed and focused on 2D games, the 3D renderer got added later, and probably caused conflicts with the core engine code, that's why Godot 4 was planned, they have rewritten the engine to they could fix all those bugs and make 3D well-integrated with the engine.

Though if you want the absolute mobile support, Unity could be a less hard pill to take, another one is Defold, which has the basic 3D features, but it's an absolute BEAST for mobile performance and small game size, either you try one of those, or go through optimizing your game as much as possible for it to work on Godot 3.

Cheers.

kuligs2

Can you not make a 2.5d game with pre rendered sprites? i mean your camera angle is the same all over.. so it should be easier and less resauce intensive..

GorEldeen

kuligs2 hey resauce, goreldeen here

Your code is very well-optimized!

or is it?

GorEldeen

Jesusemora

godot is a modern engine, designed with vulkan in mind and with some opengl support. we never heard what his boss's phone was, it could be a very ancient phone for all we know. the requirement of gles2 and bad performance with more modern versions is a bad sign.

That's Godot 4, not Godot 3 as I see in this case, the I think what they're doing should be simple to renderer on any 5-8 years old phone (except the lighting and the shadows because it eats the hell out of any device)

WRONG. I had to uninstall marvel snap because it grew too heavy and would block my phone. changing to unity is not a guarantee of improved performance. less so with modern versions.
modern unity is designed around HD and HQ, which requires modern hardware and is very unstable and heavy. legacy unity had better performance but it's being deprecated. and you make a game in a version of unity, and when an update comes out you are forced to upgrade and your game will stop working or not be recognized at all.
also, the unity fee. they got into legal trouble with fricking Disney, and the marvel snap devs decided to switch to godot. it's not a good idea to ever go to unity, ever. let it die.

Huh, I never knew about being forced to upgrade, my bad
I use Unity 5 and 2017 with monodevelop, but I haven't actually tried to publish any mobile game, but as I saw everyone is using it and honestly most of the mobile game industry use it so

But yeah, the company kinda sucks, but it doesn't change the fact that Unity is still a good game engine for any kind of games, surely, it comes with its own costs

This one I know nothing about.

I'm not really surprised, the game engine has a steep learning curve if you use it for the first time, it's like a good video with a bad intro that makes people leave, but the features and performance is well worth it.

Cheers.

Jesusemora

GorEldeen That's Godot 4, not Godot 3 as I see in this case, the I think what they're doing should be simple to renderer on any 5-8 years old phone (except the lighting and the shadows because it eats the hell out of any device)

the amount of things on screen probably wouldn't run on my 4 year old phone even if it was made in unity.
if you look at the few mobile 3D games like temple run, raid shadow legends or those survival games, the graphics are very simple and there are very few, very low poly objects, the textures are also low resolution. RSL looks good from afar, but it's actually using low poly models and normal maps to achieve the effect, and the shaders are simple. the shadows and lighting are probably baked.
other games "look" detailed but are actually 2D, like clash royale.
then there are puzzle games, those don't use lighting either, everything is unshaded.

GorEldeen Huh, I never knew about being forced to upgrade, my bad

you are not "forced" to upgrade, but the LTS only lasts a few years, and every other version has to be updated after a year. the reason for this is: unity is f***ng broken, and new versions were supposed to fix these issues. we are not talking just about (the many) bugs but also deprecated features like enlighten.

GorEldeen I use Unity 5 and 2017 with monodevelop, but I haven't actually tried to publish any mobile game, but as I saw everyone is using it and honestly most of the mobile game industry use it so

I started with 2018, just as HD and HQ were being introduced. you have no idea how bad unity has become.

GorEldeen but as I saw everyone is using it and honestly most of the mobile game industry use it so

it is very used but not ALL mobile games are made in unity. with a quick search, there are games made in unreal and others with their own engines, and games made in godot like swords and sandals.
world of goo uses its own open source engine, while baldurs gate mobile uses a modified version of the infinity engine for mobile.

GorEldeen the company kinda sucks, but it doesn't change the fact that Unity is still a good game engine for any kind of games, surely, it comes with its own costs

I think the moment the hearthstone and marvel snap devs decided to switch, that has got to be last nail on the unity coffin. unity was willing to get into legal shenanigans with activision blizzard and Disney at the same time, do you think you will be safe as an indie dev?

GorEldeen I'm not really surprised, the game engine has a steep learning curve if you use it for the first time, it's like a good video with a bad intro that makes people leave, but the features and performance is well worth it.

I don't really do mobile, mostly because of the special requirements from google and apple and how the app has to interact with the app store and the phone's authentication systems and stuff. It's extra work that I'm not willing to do. and In the case of google, I heard they require a team of 30 people to publish an android game, while apple is apple and you have to pay for the right to even compile the software.
So I'm on godot making games for PC, and maybe web.

kuligs2

GorEldeen what do you mean, i havent posted no code.

GorEldeen

kuligs2 You didn't, I just referenced a meme:
"Hey VSauce, Michael here"
"Your home security is great! or...is it?"

GorEldeen

Jesusemora

Jesusemora the amount of things on screen probably wouldn't run on my 4 year old phone even if it was made in unity.
if you look at the few mobile 3D games like temple run, raid shadow legends or those survival games, the graphics are very simple and there are very few, very low poly objects, the textures are also low resolution. RSL looks good from afar, but it's actually using low poly models and normal maps to achieve the effect, and the shaders are simple. the shadows and lighting are probably baked.
other games "look" detailed but are actually 2D, like clash royale.
then there are puzzle games, those don't use lighting either, everything is unshaded.

Ah, my bad, though your points are valid, I have done some blind calculations about the hardware back in the day, then quick search showed me that it so weak back then, sorry again mate

Jesusemora you are not "forced" to upgrade, but the LTS only lasts a few years, and every other version has to be updated after a year. the reason for this is: unity is f***ng broken, and new versions were supposed to fix these issues. we are not talking just about (the many) bugs but also deprecated features like enlighten.

that's so unfortunate, I really miss when Unity was just a cool game engine that everyone can use, now, it's a complete land mine field filled with surprises

Jesusemora I started with 2018, just as HD and HQ were being introduced. you have no idea how bad unity has become.

I actually started with 2019 and 2020 was around, I just love old stuff and ended up using Unity 5 (surely it wasn't my low end pc, for SURE it wasn't)

Jesusemora it is very used but not ALL mobile games are made in unity. with a quick search, there are games made in unreal and others with their own engines, and games made in godot like swords and sandals.
world of goo uses its own open source engine, while baldurs gate mobile uses a modified version of the infinity engine for mobile.

Mostly games with Unity and custom engine, but yeah unity seems like a bad choice now with that you told me the reality

Jesusemora I think the moment the hearthstone and marvel snap devs decided to switch, that has got to be last nail on the unity coffin. unity was willing to get into legal shenanigans with activision blizzard and Disney at the same time, do you think you will be safe as an indie dev?

Again, seems like a bad choice now.

Jesusemora I don't really do mobile, mostly because of the special requirements from google and apple and how the app has to interact with the app store and the phone's authentication systems and stuff. It's extra work that I'm not willing to do. and In the case of google, I heard they require a team of 30 people to publish an android game, while apple is apple and you have to pay for the right to even compile the software.
So I'm on godot making games for PC, and maybe web.

Understandable, mobile game development is a whole different industry than PC game development, I remember few months ago when I first used LibGDX because I heard it had the best performance for Android games, my brain was overloaded with HOW much stuff that I need to know, I snapped back into Godot after that lol, sometimes overthinking about optimization brings me nightmares