Terrain brush size is too small

[BlueCannonBall]

The terrains maximum brush size is too low when editing larger terrains.

[Zylann]

It could be increased but it's going to be very slow, pixels are modified using GDScript. For large edits it's recommended to use the generator to produce general shapes, while the brush is mostly for adjustments.

[Calinou]

Would there be a way to speed up image manipulation in GDScript, such as exposing a method to modify pixels using an array? I haven't played much with the Image class; I'm not sure exactly what can be done to optimize it.

[Zylann]

@Calinou in fact I've been considering writing a GDNative library to delegate most of these operations. They don't sound very common, the ones I plan to implement are:

• add
• add using a brush
• multiply
• multiply using a brush
• min and max values within a rect
• average using a brush
• sum
• lerp...
• potentially more

This should make editing as fast as a regular image editor, I hope. GDNative has issues, but those functions can be static and (no they can't... GDNative doesnt support it) don't require anything complex or custom, that would be at least for the editor.

This plugin also uses half-precision floats, which might contribute to the slowness because CPUs don't have native operations to work with them. An alternative would be edition on GPU but it comes with a lot of caveats, such as size limitation, memory overhead, hard-to-implement undo/redo and raycasting, the need to wait frames, having to dynamically grab back the pixels anyways to update culling AABBs and colliders... code complexity would rise a lot if we conserve the same features currently available (that might change in Godot 4 tho).

I thought of PR-ing those methods to Image but never did because it's very likely they will be refused, due to how specific they can be.

[Zylann]

Brushes can be much larger thanks to GDNative now, if you are on Windows. I still need to find a way to build the library for Linux. I have MinGW but don't know how to configure SCons for cross-compilation. I don't know how to build it for OSX.

[Calinou]

It's probably a better idea to use Travis CI to generate compiled libraries, so you can include them in your releases automatically. This way, you also avoid depending on a local environment for making releases.

[Zylann]

@Calinou where can I learn how to compile win64, osx and linux binaries using SCons with Travis CI? I thought it was just for testing. The godot-cpp dependency is also a double-submodule which needs setup as well. Was this ever done already with a GDNative plugin?

[Calinou]

godot-cpp itself is built for all platforms using Travis CI, although the generated binaries aren't uploaded anywhere (I don't think there would be much point in doing so for the raw bindings).

You could package compiled libraries for each platforms using Travis CI's GitHub Releases deployment. Unfortunately, since Travis CI doesn't allow passing data between stages (without your own server), each platform would have its own ZIP archive. The user would then have to download all ZIPs and extract them in appropriate folder in the addon. Maybe GitHub Actions allows sharing data between stages…

GitLab CI definitely allows sharing data between stages, but you'd have to host a mirror of the repository on GitLab, which adds more work.

The godot-cpp dependency is also a double-submodule which needs setup as well.

Setting up recursive submodules should be no problem, just call git submodule update --init --recursive in the CI script.

Was this ever done already with a GDNative plugin?

I'm not sure if there are public setups out there, but I might look into it eventually.

[Zylann]

I have zero experience in writing Travis scripts, at the moment I don't understand half of what the GodotCpp one does xD I don't mind if each binary has a different zip, since I will still end up packaging them myself. Being able to build those at all is already an improvement.