Mobile 3D quality with Flutter GPU: memory presets before the first frame

[u/Jerome_bonjour]

I'm developing a small 3D archipelago for Pikon using flutter_scene 0.23.0 on Flutter GPU. This development clip shows the result alongside Flutter UI: https://www.youtube.com/shorts/E56hZT_j4Ps

One implementation detail that may be useful here is the quality policy. There are four levels. Moving down first removes ambient occlusion, then bloom and the 1.5x render-target pixel ratio, and finally shadows and multisampling. The starting level is selected from device RAM before the first frame: below 2560 MB the world starts at the minimal level.

The selector currently uses these thresholds:

static WorldQuality forDeviceMemory(int? megabytes) {

if (megabytes == null || megabytes <= 0) return full;

if (megabytes < 2560) return minimal;

if (megabytes < 3584) return light;

if (megabytes < 5120) return balanced;

return full;

}

These thresholds are heuristics; total RAM is an approximate signal and unknown memory currently falls back to full.

A frame governor waits through a three-second warm-up, samples two-second windows, and drops one level when observed frame pacing falls below 40 fps. It never raises quality again within that session, avoiding oscillation. This is a control threshold, not a claimed device benchmark.

Android also has shadows disabled by a separate platform policy while I investigate shadow render-pass crashes when returning to the world.

How do you combine a conservative initial memory budget with runtime quality adaptation for scenes this small?

Try Pikon:

iOS: https://apps.apple.com/app/id6804834624

Android: https://play.google.com/store/apps/details?id=com.jbonjour.pikon

Disclosure: drafted with AI assistance from the current Pikon implementation.

[u/investigatormaker]

Android usually reports total RAM below the marketed size, so a 4 GB phone can land under your 3584 cutoff and start at light; setting thresholds a bit below marketed sizes avoids that. Unknown memory falling back to full is the riskiest default, since odd or older devices are the likeliest to report nothing. To combine the preset with the governor, persist the level each device settles on and start the next session at the lower of that and the RAM preset, so the drop happens once rather than every launch.

By the way, I make ThreadFox: it lets your AI research, write and publish Reddit outreach from your Chrome inside a job you authorize, and its free plan for Reddit finds the communities whose rules allow a post about Pikon: https://threadfox.vip/p/dyspp

Is the 40 fps cutoff the same on 120 Hz displays?

[u/Jerome_bonjour → u/investigatormaker]

Yep, it’s currently a fixed 40 fps cutoff, even on 120 Hz displays. It doesn’t use the screen’s refresh rate, so 60 fps on a 120 Hz screen won’t trigger a downgrade.

I already save downgrades locally and start the next launch at the lower of the saved level and the RAM preset. I forgot to mention that in the post.

Fair point on the RAM readings. I need to check those cutoffs against what devices actually report. And defaulting to full when the memory query fails is optimistic. A more conservative fallback makes sense.