godot_voxel VS godot-cpp

Don't do this, CSG is unoptimized. Use this.

Take a look at https://github.com/Zylann/godot_voxel, which would be a great starting point that you could build game mechanics on top of.

https://github.com/Zylann/godot_voxel https://voxel-tools.readthedocs.io/en/latest/

Currently all our major C++ based number crunching is in the GDAL. We haven't had to make in-house GDExtensions or Modules, yet. But we do also use Godot Voxel. Both are good examples of where you'd want more native speed.

I originally ported Qodot to an engine module that required people to compile their own engine (like godot-voxel) but users were turned away at this first roadblock.

I really wanted to use it but sadly it might be hard to export projects done with it cuz it's not a gdextension yet https://github.com/Zylann/godot_voxel/issues/333 still possible but i think you gotta compile something.

If you aren't adverse to doing a custom editor build you could add https://github.com/Zylann/godot_voxel

To give some practical examples. At my day job we use GDAL (a C++ geospatial data processing library) and Zylann's Godot Voxel (a C++ engine Module) https://github.com/Zylann/godot_voxel

The master branch of this one will also build as a GDExtension for Windows. This one is successfully building regularly, but structured different than the rest of the GDExtensions I've seen. I haven't played with this project too much yet, but it's an insanely powerful module/extension: https://github.com/Zylann/godot_voxel

Write C++ classes or functions using C++ bindings for the Godot engine.

Might have sth to do with https://github.com/godotengine/godot-cpp/issues/1057 . All of these errors pop up when godot::Refs are returned by certain engine functions like the one in FastNoiseLite but objects instantiated via memnew work like a charm. Plus with more gdextensions registered these issues seem to happen at more places.

I think part of the problem is that using GDExtension is like a two-way FFI. You can call (C++) extension functions from GDScript, but the same interface and overhead are used to call (lib) Godot functions from the (C++) extension.

Here's a good example (look, there I am!), although it's a bit old and actually led to perf improvement:

https://github.com/godotengine/godot-cpp/issues/1063

I've had some performance problems with GDExtensions: https://github.com/godotengine/godot-cpp/issues/1063

I tried checking out cpp repo for my godot version 4 from this repo

godot-cpp/gdextension/gdextension_interface.h

Thanks! At the moment I've been running into issues with accessing some methods of the AudioServer as well as overriding some native functions (primarily related to audio_stream and audio_stream_player). These issues on the issue tracker cover them: https://github.com/godotengine/godot-cpp/issues/1090 https://github.com/godotengine/godot-cpp/issues/1088 That said, there may be a way around this, it could just be that different bindings need to be used - currently the audio stream and audio stream player code is heavily based on existing classes like AudioStreamPlayerPolyphonic. Worst case I believe Godot itself needs to be updated to expose the appropriate bindings. I'll upload a separate branch for what I have for the GDExtensions version (though it fails compilation) sometime soon. I started this as a traditional Godot module during the 4.0 pre-alpha days but I definitely want to move it to GDExtension so its super easy for people to pull into the official engine release.