Sprite in Subviewport renders jaggedy compared to same sprite outside Subviewport

Godot Version

v4.2.stable.mono.official [46dc27791]


My scene has a Subviewport and then renders into a fullscreen Sprite2D via ViewportTexture. For reasons I don’t understand, sprites in the viewport end up jaggedy as heck (or, if I up the filter level, end up blurry). I cannot get the Sprites’ pixels to come through 1:1 - there’s absolutely nothing going on, the viewport is intended to pass into the full screen sprite viewport texture 1:1.

The only clue I have into the problem is that if put a game sprite in the viewport, give it a texture + material, and then make another game sprite outside (after) the viewport, give it the same texture + material, the game sprite in the viewport renders jaggedy, the one outside doesn’t. The textures I’m using here are very large, and are scaled down to be rendered. There are no mipmaps. It almost feels like being inside the viewport is affecting the canvas_item shader for the game sprite somehow. But I don’t know how, nor can I control it. All I know is the same sprite rendered outside the viewport looks fine. That sprite inside the viewport looks like jaggedy garbage.

What could I be doing wrong here?

(Also, the problem I think is certainly in the viewport itself, not the sprite displaying the viewport texture, because if i save a screen shot from the Subviewport’s texture, the game sprite is jaggedy in that. So it seems to entirely be a problem within the subviewport)

I should further mention that if I use a texture for the game sprite that doesn’t need scaling, then no jaggedies appear. So more specifically it feels like something goes haywire for the game sprite canvas_item shader when the texel → pixel ratio is high and the sprite is inside a viewport. As I said, the large images don’t have mipmaps, so I don’t think it’s as mipmap selection issue?

Futhermore, for the sprite appearing jaggedy inside the viewport, if I move the sprite around, the jaggedies shimmer, implying that somehow the sprite’s transform relative to the screen is a factor … (making me wonder if something is being quantized/truncated inappropriately…)