Link: https://old.reddit.com/r/godot/comments/1tdfeq8/moving_grass_placement_from_gdscript_hot_loops_to/

This is an automated archive made by the Lemmit Bot.

The original was posted on /r/godot by /u/Hostarro on 2026-05-14 23:49:16+00:00.

Hey folks - working on Luminids, a cozy world building colony simulator about little beings of light that evolve over time. This post is for anyone that's been hesitant to combine C++ and GDScript approaches to your game.

I’ve been migrating our dense grass system in Godot from a mostly GDScript runtime to a C++/GDExtension hotpath, and the frame-time difference has been pretty dramatic. Honestly I was pretty gunshy about doing it.. I thought it was going to be really complex and scary - turned out, not so bad at all to write an addon and create a bridge file.

The old path was doing the kind of work GDScript really does not want to do at runtime: candidate generation, terrain payload scans, rejection checks, mask checks, and some voxel-buffer surface extraction.

In profiler captures, the bad path showed:

• Script Functions: up to ~410ms in the worst case
• GroundedVoxelTerrain / VoxelTerrainSetup: ~20-45ms in newer captures, previously ~399ms callback spikes
• GrassWorldMaskProvider: ~136-147ms in some cases
• broad vertical terrain scans: ~12-35ms in failing biome cases

After moving the grass placement and terrain payload extraction onto the native/packed path, the latest short windowed traversal looked like this:

1200-frame windowed traversal
steady window from frame 300

grass process p95:        0.830ms
grass chunk build p95:    0.736ms
grass snapshot p95:       0.728ms
native worker p95:        0.0806ms
grass upload p95:         0.509ms

terrain callback p95:     0.593ms
terrain callback max:     3.547ms

visible grass instances:  4275
active chunks:            96
pending chunks:           0
deferred chunks:          0

So depending on which old hotspot you compare against, the savings are roughly:

410ms script spike -> 0.83ms grass process p95
about 409ms saved, ~99.8% reduction

34-69ms newer script spikes -> 0.83ms p95
about 33-68ms saved, ~97.6-98.8% reduction

20-45ms terrain/grass callback entries -> 0.593ms p95
about 19-44ms saved, ~97-98.7% reduction

12-35ms broad scan cases -> ~2-3ms bounded native scan
about 10-32ms saved, ~75-91% reduction

It's not a magic bullet.. I get that using C++ wasn’t enough by itself. I also changed my data shape.

The working version now looks more like:

loaded terrain availability
-> native packed terrain surface payload
-> packed grass snapshot
-> native worker placement/rejection/transform packing
-> pooled MultiMesh upload

And the rules became:

No GDScript candidate loops.
No GDScript voxel-buffer scans.
No recursive scene scans per frame.
No fast-height hacks for placement.
Batch Godot API calls.
Keep workers on plain packed data, not live scene objects.

Still not all the way there.. the full 10k-frame traversal and multi-run perf gate still need to pass, and there are still broader terrain/runtime spikes outside the grass hotpath. But for the grass system itself, moving the dense numeric work out of GDScript took it from “can blow an entire frame by hundreds of milliseconds” to sub-millisecond p95 territory in the current short traversal.

Thanks for reading! Feel free to check out www.luminids.com for more dev logs on how I'm handling terrain, systems, the Luminids brains and more.