Hello!<br>I'm doing a break in my 2D project to try out 3D things, and like with any engine I use I wrote a voxel world generator! HEHEH<br><br>It's not based on the existing Minecraft Godot project, I actually ported code from my previous projects and improved it so it works well in Godot. I even took it a bit further by allowing voxels to have any geometry.<br><br><img alt="" src="https://raw.githubusercontent.com/Zylann/voxelgame/master/screenshots/2016_04_27_2037_half.png" title="Image: https://raw.githubusercontent.com/Zylann/voxelgame/master/screenshots/2016_04_27_2037_half.png" height="453" width="760"><br><br>I just open-sourced the project here: https://github.com/Zylann/voxelgame<br>It's all GDScript with SurfaceTool, so expect world generation to be slow as hell.<br>But thanks to thread goodness the game runs smoothly at 60 fps with a decent viewing range.<br><br>I eventually plan to work on a C++ module to improve number crunching through datagrids and simplex noise buffers, so world generation and mesh extraction could be speed up 100 times faster.<br><br>Edit: I moved voxel stuff to a new C++ module: https://github.com/Zylann/godot_voxel<br>the game requires this module to run. You can still find the pure-GDScript implementation in a branch, but it's no longer updated.<br>

7 days later

Nice !!I definitely will have a look at this and how you did it. Currently I have less time so I keep my post short but I will have a look at your project :)

I ported my code to a C++ module, and now I don&#039;t even need a thread to generate the heightmap!(Well, with more complex stuff it might still be required anyways :D)Also added ambient occlusion.https://github.com/Zylann/godot_voxelI&#039;ll make a branch soon in my voxelgame repo that makes use of this module, I just need to clean GDScript mess before :pAlso, tried with 3D noise:[img width=760 height=456]https://github.com/Zylann/godot_voxel/raw/master/screenshots/2016_05_04_0319_w800.png[/img]While I know where I&#039;m going for graphics and terrain generation, I still don&#039;t know how physics will work. Will Godot physics be enough? Or will I have to roll my own? Or mix the two with a special kind of collider?

Nice that looks insane! I love it.Just came back from holiday so I still didn&#039;t look at your code ;( . But great that it is possible to achieve good performance using c++. Just if you are interested. The way I did the physic is by just having a bunch of cube collides. Whenever the player position gets changed by one Voxel I check for surrounding Voxels and adapt the position of the colliders... Needs less computing power but it is hard to do mining because i cant use ray-casts.I&#039;m new to Voxel systems so I didn&#039;t read any resources how things work best and just tried my ideas so this might be a very bad implementation. You seem to have some experience so this might not help you, but it wanted to mention it anyway.Keep up this projectwhat is the frame rate you achieve with the big 3D noise terrain and shadows?

To be fair, that 3D noise screenshot was running at 20 fps, because my graphic card is 4 years old and I turned on all the options :p Shadows take the most part, if I disable them it goes up to 40.There is also a great deal of hidden geometry under the terrain, and AFAIK Godot doesn&#039;t performs occlusion queries.I achieve 60 fps with a heightmap terrain with a render distance of 816 voxels in XZ directions.One thing bothers me about this, I had an OpenGL prototype years ago that was running at 60 fps too, but without any form of culling, so I suspect Godot to be slower somewhere. Are VBO in use? Or is the culling process taking too much time? I&#039;ll investigate with cuboids of 32x32x32 rather than 16x16x16. If it&#039;s not enough... I&#039;ll consider optimizing the meshing process further.Edit: http://zylannprods.fr/lab/voxy/: I made this with Unity 4, same algorithm, with render distance of 1216 voxels AND shadows, and it renders much faster. So I think there is room for improvement in Godot renderer as well.About physics... when I have time, I may test two approaches. One with Godot physics like you said, and if it&#039;s not good enough I&#039;ll write a custom collider. The problem is that the player is not the only one to require physics.One cool thing I absolutely want to test is... VoxelMobs! Construct anything and make it a mob that collides with the terrain :D But that will be in a while...Raycasting should be easy to do by hand, with a custom implementation in C++ :)I recently moved terrain handling in C++, so now just create voxel types and implement _generate(voxels, position) in GDScript and you&#039;re done :pAnd it&#039;s very fast because I exposed helper functions like fill_area(). But in the longer term there will be an option to do that in a thread anyways :)

Godot&#039;s renderer is known to be very unoptimized, for example, the batch count will be much higher than it should. This is due to low usage of instancing (since OpenGL ES 2.0 does not guarantee its support by the hardware).Since OpenGL ES 3.0 (the version of OpenGL that will be used for Godot 3.0&#039;s render) mandates support of much more features including instancing, it will be possible to achieve much better performance and looks.

Wow... This is nice!Keeping an eye on this, good work!

I tested using cuboids of 32x32x32, and I get more FPS with worlds generated with 3D noise. This is because it takes much less meshes to cull. However it involves a high latency at modifying the meshes, so I&#039;ll stick with 16x16x16 for now...Unless there is a way to tell Godot to cull groups of meshes together rather than everyone of them?@Calinou I don&#039;t understand, how could instancing be used in a scene where almost every mesh is different?