QuadRenderer FitIn, FitOut not working as expected (again)

Since the old topic is already locked, I have to start a new topic:

@joreg I don’t know if I am missing how to set this up properly, but now it seems even more broken than before:

Shouldn’t FitIn and FitOut at least keep the aspect ratio of the image? Here is what I would expect it to look like:

Fit Out (equivalent to object-fit: cover in CSS):

Fit In (equivalent to object-fit: contain in CSS):

I mean whatever it takes really, but I know that if we want to show an image on a quad 9/10 times you want to show that image undistorted. Right now, all modes of the quadrenderer distort the image if the aspect ratio of the render window changes.

At least that’s what I always assumed the Size Mode referred to.

what if you replace the WithinCommonSpace node with the new FlatCameraRenderer node?

Ah okay, the image doesn’t distort then, but the behavior is still not right. I created a patch with 2 render windows now, with very different aspect ratios to better show the difference.

But for Fit In, we should always see the whole image and 2 sides are always touching the edge of the renderwindow. For Fit Out you never see any black bars and the image always fills the render window such that its at the smallest possible size without showing black bars.

fitTexture.zip (358.0 KB)

Here is the C# or sort of pseude code you would use. Its pretty much the same in any language. I have built this in JS before as well.

// Aspect ratios
float textureAspect = (float)textureWidth / textureHeight;
float quadAspect = (float)quadWidth / quadHeight;

// — FIT IN (letterbox - entire image visible, may have bars) —
float scaleX, scaleY, offsetX, offsetY;

if (textureAspect > quadAspect)
{
// texture is wider than quad → fit to width, bars top/bottom
scaleX = 1f;
scaleY = quadAspect / textureAspect;
}
else
{
// texture is taller than quad → fit to height, bars left/right
scaleX = textureAspect / quadAspect;
scaleY = 1f;
}
offsetX = (1f - scaleX) * 0.5f;
offsetY = (1f - scaleY) * 0.5f;

// Apply: UV tiling = (scaleX, scaleY), UV offset = (offsetX, offsetY)

// — FIT OUT (cover/crop - quad fully filled, image may be cropped) —
float scaleU, scaleV, offsetU, offsetV;

if (textureAspect > quadAspect)
{
// texture is wider → crop sides
scaleU = quadAspect / textureAspect;
scaleV = 1f;
}
else
{
// texture is taller → crop top/bottom
scaleU = 1f;
scaleV = textureAspect / quadAspect;
}
offsetU = (1f - scaleU) * 0.5f;
offsetV = (1f - scaleV) * 0.5f;

// Apply: UV tiling = (scaleU, scaleV), UV offset = (offsetU, offsetV)

you always have to have a switch for when the aspect ratio of the image divided by aspect ratio of the container is larger or smaller than 1.

I tested it too
The behavior is the same; the problem persists

probably you can still use that testbench: QuadRenderer FitIn, FitOut not working as expected - #12 by yar

The main reason why this isn’t working properly is that TextureAspectRatio uses FixAspectRatio, which doesn’t use feedback.

Take a look at these nodes – they contain the main issue that I mentioned in my previous comments.

Hm, I am not sure if I got it right now, but to me it looks like its working properly.

covercontain

covercontain.vl (31.7 KB)

@chk try using a normalised common space.

I actually tried it, and strangely it’s working as expected. Further investigation is needed.

The patch is using the new FlatCameraRenderer with which I assumed I don’t need that anymore.

@chk the best way to find out if it’s working properly is probably to make something real. I’ll be back when this opportunity arises.

Thanks for your testbench.

I’ve figured out what the problem is
It might work fine in Stride. It doesn’t work in Skia

You can go back to the test bench I created earlier. It was built using Skia.

@yar please start a new topic when talking about skia (this topic was about Strides QuadRenderer). and when claiming something doesn’t work, please take the time to clearly describe what you see as opposed to what you expect.

@joreg Thanks for pointing out the difference, because it wasn’t clear from the thread that we were only talking about Stride!

I’ll definitely start a separate thread; thanks for bringing that to my attention.
Thank you, @seltzdesign, for reporting the issue in a separate thread!

I’d just like to point out that I’ve already explained what I’m talking about in the previous thread; I’ll just copy it over from there. Nothing has really changed. Please understand that it’s quite difficult to describe this sort of problem, because it’s hard to distinguish a ‘feature’ from a ‘bug’.