I’ve been working on a custom C++ GDExtension build of the 3D Tiles for Godot plugin and looking for suggestions to further optimise performance and reduce resource usage during runtime.
Most of the existing features (tile loading, mesh generation, raster overlays, etc.) work well, but as the scene complexity increases, performance drops noticeably when large numbers of tiles or buildings are visible simultaneously.
I am yet to start with optimisations on the C++ side and I’d appreciate input from anyone who has worked on similar optimisations:
Which areas of the Godot rendering pipeline or the 3D Tiles implementation are most worth profiling for performance bottlenecks?
Are there existing patterns or hooks in the current plugin codebase where geometry or texture optimisation can be most effectively integrated?
Has anyone experimented with conditional mesh or material simplification in GDExtensions, or any best practices for dynamic LOD switching?
Any recommendations for profiling tools, engine flags, or rendering settings that significantly improve tile streaming and scene loading performance?
This would also help others facing similar challenges, Thanks in advance for your insights and suggestions.
Hi,
Following are a few architectural improvements and suggestions based on observation, kindly ignore if any points that are not applicable.
1. Missing Object Pool for 3D Tiles
The current 3D Tiles implementation does not appear to reuse Cesium3DTile objects. Tiles are allocated and destroyed repeatedly as visibility changes, which can lead to unnecessary memory churn and potential fragmentation, especially during aggressive camera movement or LOD switching.
Introducing an object pool for frequently created and destroyed tile nodes could significantly reduce allocation overhead and improve runtime stability.
2. No Centralised Resource Manager
Textures, materials, and related GPU resources are created inline during tile loading. There is no centralised resource manager responsible for ownership, reuse, or deduplication.
A resource manager pattern would provide:
Shared material and texture reuse across tiles
Explicit lifecycle control and cleanup
Reduced duplicate GPU allocations
This would be particularly beneficial for large tilesets with repeated material usage.
3. Pooling Limited to Worker Threads
The only pooling mechanism currently present is BRThreadPool, which applies exclusively to background worker threads. There is no equivalent pooling strategy for scene objects or render resources.
Extending pooling concepts beyond threads to tiles and render assets would better align the system with real time streaming workloads.
4. Dependency on Scene Tree and Reference Counting
The plugin relies entirely on Godot’s scene tree ownership model and reference counting for object lifecycle management. While this is functionally correct, it may not be optimal for high frequency creation and destruction patterns such as tile streaming.
Explicit pooling and resource management would complement Godot’s lifecycle system and reduce pressure on the allocator.
The current design is correct from a functional standpoint, but performance and memory behaviour could be improved by -
Adding object pooling for tile nodes
Introducing a centralised resource manager
Reducing inline resource creation
Treating tiles as reusable streaming entities rather than disposable scene nodes
These changes would improve scalability for large datasets and reduce runtime allocation overhead without altering existing external behaviour.
