Bouncing Camera , interpolating frames

[iOSxcOder]

Godot Version

4.6.dev - custom Mac OS ARM

Question

I’m messing around with Debugger and trying to find out more about smoothness and what resources are used .

Currently I work with this simple piece of code on Camera but only to learn only cpu is used :

extends Camera3D

var start_pos := Vector3(0, 90, 0)
var end_pos := Vector3(0, 10, 0)
@export var duration := 10.0

func _ready() -> void:
	transform.origin = start_pos
	start_movement()

func start_movement() -> void:
	var tween = create_tween()
	tween.set_loops()  
	tween.tween_property(self, "position", end_pos, duration)
	tween.tween_property(self, "position", start_pos, duration)

Is there better way then this to create smooth bouncing camera in Godot and maybe utilise Metal Render to fits extra fps -

Is there way how to enable this feature inside the Godot to utilise upscaling , and interpolations frames using Metal 4 ?

WWDC25: Render complex scenes with MetalFX

---

Godot v4.6.dev (084d5d407) - macOS Tahoe (26.0.1) - Multi-window, 1 monitor - Metal (Forward+) - integrated Apple M2 Max (Apple8) - Apple M2 Max (12 threads) - 32.00 GiB memory

[normalized]

Renderers and camera objects have generally nothing to do with each other. Camera is just a data structure consisting of several numerical parameters. Changing those parameters one way or another has nothing do with rendering performance. Doing with with tweens or using some mathematical functions is perfectly fine.

[gertkeno]

You probably want to set a trans and easing value for your tween. Chances are your computer is already running this simulation at the maximum framerate, so interpolating frames isn’t going to help, nor would it smooth the camera motion, only increase framerate.

Try

func start_movement() -> void:
	var tween = create_tween()
	tween.set_loops().set_trans(Tween.TRANS_QUAD).set_ease(Tween.EASE_IN_OUT)
	tween.tween_property(self, "position", end_pos, duration)
	tween.tween_property(self, "position", start_pos, duration)

[iOSxcOder]

So generally what is done by CPU and should be moved to multithreaded from blocking main thread , what should be on main thread , and what task is done by GPU and should be coded in shaders ?

[normalized]

Well it depends on what type of performance bottlenecks you’re experiencing. If you’re not experiencing any then there’s no need to think about threads or compute shaders. CPU runs scripts and GPU rasterizes polygons. And that’s pretty much it.

[iOSxcOder]

When running my Godot project in full-screen, my FPS drops significantly to between 30-43 FPS. However, in windowed mode, the performance is much better and smoother. I tried this with different project without extra stuff like interpolation, expo nationals, ( math ) and it seem to be doing much better https://youtu.be/7Qq4XRaOuOc

Machine: Mac Studio M2 Max (32GB RAM)

Monitor: Samsung 4K @ 60Hz (connected via HDMI)

Build: Custom Godot arm64 build with Metal 4 support (though the issue also persists on stable).

The Bottleneck: Render Resolution

After debugging, the core issue appears to be the render target resolution.

In Windowed Mode, the game renders at a reasonable 2668x1501.

In Full-Screen Mode, Godot defaults to rendering at a massive 5K resolution (5120x2880), even though my monitor is only 4K and viewport is set to 1920x1080 .

This 5K render target seems to be the entire bottleneck. My Mac is trying to render twice as many pixels as the monitor can display, causing the huge performance drop.

Video showing the 5K render target: https://youtu.be/XkEltTT3I8c

What I’ve Ruled Out

Shadows: Toggling shadows has almost no impact on performance. (See: https://youtu.be/4nnzr4YDQo0)

Scene Complexity: The FPS does improve if I lower viewport.scaling_3d_scale = 0.8, which confirms the bottleneck is related to pixel fill-rate (resolution) and not the 3D scene itself.

[normalized]

@iOSxcOder

The Bottleneck: Render Resolution

The actual bottlenecks will become apparent once you run the visual profiler. You’ll be able to see what parts of the rendering pipeline are taking up the most time and optimize accordingly.

You can always render at fixed resolution and scale up to actual screen resolution. It won’t be as crisp but it’ll run at good framerates.

[iOSxcOder]

I’ll be honest I’m looking on it as seeing this strange behaviour in windowed mode as size is bigger fps is lower , and full screen is absolute nightmare .

But on my simple test project I never came across this low fps ,

Can you test it out how it runs on your hardware , maybe you can notice where is issue .
It’s from course which I took and learned a few things but sometimes it seem a bit overdoing .

GameDev.tv / Godot RPG / Godot RPG · GitLab

[normalized]

Did you visually profile it properly. Your video shows you’re clicking around the profiler but I don’t see any proper profiling charts there.

[iOSxcOder]

That’s the thing , when I return from full screen all I see in visual profiler, would you mind to download and give try on your side ?

[normalized]

Run it in a large window so you can see the profiler chart as you go.

[iOSxcOder]

cool ,
but the thing is the fps is lower in full window mode , fps in window mode seem to do fine the 60 fps .

Also it doesn’t show any activity on GPU in Godot

[normalized]

Hmm…

Visual Profiler not showing GPU times on Mac (Apple Silicon)

Are you rendering with Metal? Can you try forcing Vulkan and see if you can profile then? Also see what happens if you render with OpenGL by switching to “Compatibility” renderer.

[iOSxcOder]

Yeah I Use Metal , on 4.5.1 is 3.2 and on this custom built is 4 with improved fps ( or at least that how they advertised )

I have tried Compatibility - signifactly worse graphic but same result on fullscreen in terms of performance

@normalized

Also I tried to switch to Vulkan , but still not measure GPU activity .

[iOSxcOder]

4 2 2

This seem to be issue with measuring from 4.3 onwards , but in old 4.2.2 it hits around 30 fps where in custom 4.6 dev on metal 4 - 45+ .

It probably something to do with Apple API as it strange how size is done and they want you to buy their 5K monitor for sake of no upscaling .

So solution :
If you don’t have Mac Studio Display , use native 1920x1080 for 4K monitor lol

[normalized]

Absolute values don’t really matter. Click on those two largest stacks on the chart to see which parts of the rendering pipeline they represent, so you get some clue where the actual bottlenecks are.

[iOSxcOder]

is this what you mean I selected two widest .

Funny enough when I set my system ( Mac OS ) resolution to 1080P , Render target is 4K

[iOSxcOder]

This is how it performs on 1080P using 4.2.2 which is Vulkan not Metal.

So I will stick to 1080P system settings when making game as it seem to be on Mac OS really trading off performance when upscaled .

[normalized]

@iOSxcOder

is this what you mean I selected two widest .

Yes. So you can optimize GI, or make it optional for the player. GI is always expensive so a special care need to be taken with it. It’s not just enough to switch it on. If it’s not significantly contributing to your visual mood, you can simply do away with it completely.

And large opaque pass means you’re bruteforce rendering too much stuff. For start check how many draw calls you typically have (in monitors). If the number is big, see what strategies you can use to bring it down.

[iOSxcOder]

How can I check this draw calls ?