Closed Zylann closed 6 years ago
I am on linux and I am looking to incorporate this plugin into my project. I'm happy to help get the C++ side stable as I've already began porting your code to be able to be compiled in without gdnative (you can set a compiler define to switch between gdnative and native).
I hear your are also looking for 16-bit texture support (https://github.com/godotengine/godot/issues/17450). I have also written 16-bit and 32-bit tiff loader for my own terrain, but seeing as I am trying to get your terrain working I can add that to your plugin.
I am not sure if it would be possible to get the tiff loader submitted back into godot as it requires some thirdparty libraries, they are how ever cross platform.
If you want to chat get on matrix: @supagu:matrix.org
Thank you for your proposal!
Compiling the C++ implementation as a module is not really the goal of this plugin, since it would require a bit more changes, both with #ifdefs all over the place, and also on the GDScript side, so I'm not sure about this.
Also if you want to work on the C++ side, you will have mostly two tasks:
16-bit UNORM mono/multichannel texture support would be nice indeed, and if possible should be added to the engine, especially considering PNG supports that format already but Godot doesn't implement it in Image, Texture and loader/saver. TIFF can also be proposed but I'm not sure if core devs will consider it worthwhile.
Hey Zylann, I am wondering if via gdscript I will be able to access the terrain classes in my own c++ plugin.
I currently do my own raycasting into a heightmap texture for example so need to use the terrain classes. Hence why I think I need to work around the gdnative implementation to make it a native implementation. I could be incorrect, I'm not familiar with gdnative, perhaps you can shed some light on this for me? Would I be able to access and use the terrain classes in my own native c++ plugin? (ideally without some weird build system)
If your C++ code lives as a module, you will be able to access terrain functionality through the script API (as if the terrain was a script, regardless of which implementation is in use). What kind of raycasting do you need and why? Because there is a chance you don't need to link the terrain library directly. In worst case, you could get the heightmap image and work on that intead (it's not future-proof though, since it's an internal format that can change), or if you want physics raycasting you could use the collider I recently implemented with Bullet.
This issue is about making the C++ implementation of this plugin work. If you want a feature you need for your own C++ project, please make another issue about it.
I'll close this issue for now because given the current state of the plugin, it's unlikely I'll have time to maintain a fully-replicated C++ version using GDNative. Maybe in the future some parts of the plugin will have optional GDNative implementation though.
The plugin currently works fine using a full GDScript implementation, but suffers from performance limitation in some areas. These areas can be optimized a lot using either GPU or C++ implementations.
The C++ implementation exists, but is currently not enabled and slightly getting out of date. It uses GDNative and C++ bindings: https://github.com/GodotNativeTools/godot-cpp It is already 99% the same as the GDScript one, though recently the GDScript implemention kinda became the reference since I worked on it a bit more and helped finding more areas to work on. Eventually I should come up with an API reference that both implementation should mirror, so that people can use one or the other without hassle. Note that the C++ implementation is intented to only contains core features + things that need performance.
The reason why the C++ implementation is not the default is because it's not stable, mainly due to the C++ bindings not being stable in the first place. Also, there is a lack of validation layers which would prevent unexpected crashes if users make mistakes in calling functions etc. Working on this part requires to also work on the C++ bindings to provide all this.
Also, I only have a Windows computer so I can only work on libraries I can compile and test from there.