Why not GDNative? about godot_voxel HOT 4 CLOSED

It was indeed started before GDNative, and still isn't mostly because of what @tinmanjuggernaut said. It would limit the module not just because of being limited by script API, but also because it makes integration less natural, adds a bit of overhead. Quite often with this status, there are blockers to workaround for (Feature requests, PR etc, like I had to do for my terrain plugin, it wasnt properly functionnal for about a year until Godot finally exposed the features I needed!).

I'm also concerned about stability. AFAIK GDNative lacks a lot from type-safety when interacting with the Godot API (and ABI compatibility often breaks across versions), mistakes are easy, and it can be a daunting task to diagnose them while at the same time this module already does tight threaded stuff with huge amounts of data. I need to give another try to see the status of this but so far i've been more confident with a module workflow, and rebuilding the engine isnt complicated (and fast once you've done it once). So I'm not opposed to a GDNative port, but it's not something I'd like to work on too soon (but you are free to try :D)

Also there is the fact that GDNative libraries currently don't work on web and mobile exports (I could be wrong about latter tho, havent checked recently). Less of a problem for me as I personally want to use this module on high-end desktop, but could be a concern for others.
GDNative also doesn't support natural exposition to C#, which is something quite likely for people wanting to build a large game from voxel technology. Currently you have to go through varcalls (i.e calling by function name and variant args which is much slower and daunting in C#). As a module, voxel tools just work fine with this language.

On the other hand, I'm not sure about integration in core. I know Reduz would be interested to have a voxel terrain but maybe my expectations aren't exactly the same as his, but that's speculation as I don't know if he actually had a detailed look at the module. Also, while I stick to most of Godot's guidelines with conservativeness, I had to break some rules in the codebase to leverage extra performance and maintainability (because I had to, rather than having to stick with whatever "modern" standard), you can see I use std::vector, lambdas and template functors quite often. I wouldn't consider the module ready for integration in core for a year as well because I consider the API right now is far from "final" and editor tools are rough.

Finally, I vaguely thought about moving away from Godot API, and limit its uses for places where I actually interact with it (while preferably not adding overhead). VoxelServer is a possibility. That would help make the module a bit more independent, so that it could not only ease its port to GDNative (if someone dares :D), but also to other engines. I'm personally not interested in maintaining multiple frontends as I just care about the module itself and its use in Godot, but that could be something to consider in the future.

from godot_voxel.

IIRC it was started before GDNative was a thing.

from godot_voxel.

I agree development time would be faster in GDNative as we can compile just the module, not the engine, and don't have to reload Godot. Yet, GDNative still takes some setup for the end user.

Also GDNative is still kind of clunky right now. It's new and not feature complete. And you have to work through the GDNative API to access the engine instead of working directly with the back end classes.

So although it's Zylann's call as to when it's ported, if ever, I suspect GDNative won't be ready for a project as complex as Voxel Tools for at least another year. Then v4 & Vulkan coming out, there's even more API to implement in GDNative.

A more likely path is including it in the master branch of Godot once the module is feature complete. But again, that's way out and may not be desired by Zylann or Godot devs.

from godot_voxel.

Thanks for all the info. You've given me quite a bit to chew on for a while. The idea of moving away from the Godot API is particularly interesting. I guess I'll have to wait and see where this project goes. Whatever you end up doing, keep up the amazing work!

from godot_voxel.