4.2
When I use meshes without texture (godot’s standard boxmesh) it is completely normal, without lag, but when I place an object already imported into voxels, it lags a lot, reaching 5 fps. Can someone help me? Am I doing something wrong?
Remove all the interior faces that will not be seen.
Such a drastic difference is strange.
Is your model poly-count high? Or maybe your texture too large?
You could try to remove the texture and run the game to see if that’s the problem.
Does it run normally inside the editor and only lags in game? Or are you generating this procedurally?
You can also check the Debugger->Profiler, Visual Profiler, and Monitors tabs to see what is actually causing the “lag” to see if that helps pin-point the problem.
Here are some more general tips for performance:
You can always use occlusion culling if you have many overlapping meshes.
LOD might help depending on the number of polygons your models have.
MultiMesh might be a good solution, if you split them in good sized chunks.(MultiMesh — Godot Engine (stable) documentation in English)
From what I understand, the poly-count is 24x24x24 voxels, the texture is small, and it lags both in the editor and in game. I’m trying to make a procedural generation system following a tutorial, and it was working well until the part where I put an .obj with texture instead of godot’s default meshbox
I tried activating occlusion culling, LOD and multimesh and it didn’t work, it keeps lagging. I’m learning how to implement a chunk system that automatically deletes and adds blocks, but even so what causes the lag is exposure to many gridmap meshes(maybe specifically this one), I still don’t know why
Here’s what appears in the visual profiler:
Edit: even removing the mesh texture it still lags
Did you mean occlusion culling? If not how do I do this?
Yeah, occlusion culling. You can check the “Display overdraw” option to see if it is really working.
Here’s a really good video that explains what it is and how to use it (https://www.youtube.com/watch?v=lsoUQOpd3Yk)
I’d say you can try a few things to inspect your problem:
1 – Try to use a .glb or .gltf model instead. Who knows, maybe something is wrong with the .obj importer.
2 – Make a simple cube in blender and export it as the .obj or .gltf file and see if your game works fine with it.
My point it. Wierd things can happen. Test basic things first to see what work.
3 – Try to use the Godot .NET version if you aren’t already.
Even if you only use gdscript. I’ve had a SEVERE slowdown(1s delay) when selecting 3D objects when using the normal engine, but using the .NET version solved this for me.
4 – Make a minimal project that have this problem and upload it so someone can take a look, even if only to check if the still problem happens. Sometimes its a hardware issue.
Ok, so, I don’t know what that tutorial told you to do, but if you want to make procedural cubes in godot, your best option is to use a single mesh that is just the two triangles of your cube face, and use a MultiMesh to have an instance for each face that is exposed to air. So you get your voxel data and construct the set of faces, cache that and pass it to the multimesh to instantiate a quad for each face, then pass enough data to the shader so it knows which texture region goes on which face. You should be doing this using a single atlas for all the textures that can be a block face.
If you are doing all this, you shouldn’t have any slowdown derived from rendering.
Also worth checking if the materials are shared or unique.
It’s funny, cause somebody in our godot group has a similar setup. I think optimizing this is rather interesting. If all the other suggestions don’t work, you can try to use a custom shader with only one single mesh as multicube-mesh which contains say 10x10x10 cubes - basically one mesh combining all those cubes, so that you have only one transform for it. Use than a “visibility” texture for enabling or disabling cubes. One 32x32 would be large enough. You would need to assign a second UV set for the vertices, so that you would be able to map pixel to cube. With this mapping you could do than even more stuff, coloring for example or more fancy things like effects.
I accidentally deleted the project and redid most of the things, and discovered that most likely what really matters is the number of mesh colors. The more colors, the fewer frames I have, but with just 3 colors I start to have a very bad fps.
Here is a demo (please don’t notice the quality, it was the maximum I could get to approximate the editor’s fps)
https://youtu.be/pQ_L_ZgMDRo - 3 colors
https://youtu.be/vrePQyTMINY - 1 color
I tested your tip 1 and practically nothing changed in the editor and in the game. Some colors were changed, but the fps remained low.
The 2nd tip I tested with magicavoxel just adding 1 color, and it was much smoother in the project than the mesh with just 3 colors.
I wasn’t able to test the third tip, I didn’t quite understand how to use the .NET version, but regarding the fourth tip, here is the project: https://drive.google.com/file/d/1rkpNoR97ItTOiOkW3UOqtTEGeoBlw7TL/view?usp=drive_link
Do you have any tutorial that will help me do this? I still don’t understand how to use multimesh, and I don’t intend to use cubes exactly, but rather voxels in the shape of a cube with reliefs. I thought occlusion culling already handled this
I tested your project here.
I’m getting stable framerate inside the editor here.
But slight stutters inside the game.
(Using an 8 year old PC, Intel i7-7700, Geforce 1070)
Not sure if .mp4 videos will show, but here it is:
The stutters inside the game was due to your update_chunk function.
It is too slow to run at the main thread. You should probably use multi-threading to do chunk generations or you won’t be able to avoid stutters, as it hangs the main thread until it is finished.
And what a told about the .NET nothing much, is just that in my personal experience the .NET seems to work better inside the editor.
If you want to try. Just download the .NET version of the engine, and use it instead. (Download for Windows - Godot Engine)
One thing I have noticed (I’m running on an older system), is making changes to the project often results in lag (both in editor & ingame), which forces me to either reload project or restart GODOT completely. 