godot-jolt VS gdal

Some other Rust game engines ship with their own physics engine. Fyrox, for example, has advanced 2D/3D physics, supporting rigid bodies, joints, ray casting and more. Godot too, which has community-led Rust bindings also has an in-built physics engine as well as a Godot-native extension using the Jolt physics engine. In fact, which is reported to be more performant than the official physics engine.

When the performance of Godot's physics engine has been mentioned before I've seen https://github.com/godot-jolt/godot-jolt pointed to as a drop in more performant solution.

Haven't tried it in a project yet myself

No idea if this will solve your problems, but with Godot 4 Physics being a bit undercooked you might want to try a different physics engine. Like Godot-Jolt: https://github.com/godot-jolt/godot-jolt

Godot 4 itself is actually fairly good about diving to its C/C++ base for the nasty stuff. Like its Physics. The reimplementation for Jolt physics into Godot 4 is again C/C++ calculation library.

If you'd like to try out Godot Jolt for yourself, you can find the latest release, as well as important gotchas, on the project's GitHub page. Just bear in mind that the extension is still in development and will likely have a couple of bugs that have yet to be found. C# support for GDExtension is also not in a great place right now, so there are some issues there as well.

Try a different physics engine: https://github.com/godot-jolt/godot-jolt

Your comment made me do a bit of research and I found this: https://github.com/godot-jolt/godot-jolt

It's possible to create a GDExtension for it (similar to what was done for Jolt), but I haven't seen any for Bullet yet. There's a lot of hype going around Jolt, so it's understandably where most of the community effort is going :)

Or godot-jolt (linked in that Tweeter thread respones).

TiTiler is a dynamic tile server built on FastAPI and Rasterio/GDAL. Its main features include support for Cloud Optimized GeoTIFF(COG), multiple projection methods, various output formats (JPEG, JP2, PNG, WEBP, GTIFF, NumpyTile), WMTS, and virtual mosaic. It also provides Lambda and ECS deployment environments using AWS CDK.

GDAL is the real heart, the python aspect is mostly wrappers around that I'm fairly sure. I love python for the record, the only reason I bring it up, is cause python haters accuse it of being slow, but QGIS drops down to C++ when speed is necessary, like most modern packages do.

gdal 0.15 (repo, docs), a set of Rust bindings for the GDAL library, used for access to geo-spatial data formats, is now out!

GDAL (Geospatial Data Abstraction Library) is a the geospatial data processing library. It handles a lot of Raster/Vector analysis and alteration. gdal_contour and gdal_rasterize which would be used to create isolines (contour lines) . There's more complex processing and analyses than that. More common is reprojecting multiple layers, and some that being as Vector files, into different coordiatne systems.

Access: GDAL

As an example we use GDAL heavily through its C# binds. We do all the additional data processing, that isn't done by the C++ GDAL, in C#. The final results are both Data (held in memory or temp exported to a file), and a normalized Raster Texture that we can display on a TextureRect. Most of the C# data processing scripts aren't even Inheriting from any Godot Class.

I think this would be the best way to handle this. GDAL is what you should look into for this project.