Magic Resolution consistency/override

tooll3 / t3

Tooll 3 is an open source software to create realtime motion graphics.

MIT License

3.48k stars 193 forks source link

Magic Resolution consistency/override #399

Open teadrinker opened 8 months ago

teadrinker commented 8 months ago

if I understand correctly from the video https://www.youtube.com/watch?v=f9E7lwUXfBM

for -1 use output resolution for 0, use resolution from source if available, fallback on output resolution (resolution flows from left to right) (else use the fixed width/height values)

Internally, this seemed to be handled through GetTextureSize, however, for instance inside CustomPixelShader, the texture input is not connected to GetTextureSize which breaks expected behaviour (is this a bug? or a deliberate exception?)

I feel the concept outlined in the video is great, but in order for the user to have control over resolution in this intuitive way, all operators that internally uses an operator with a resolution should also expose a resolution input and handle it consistently.

teadrinker commented 8 months ago

The Blend operator causes odd behavior due to GetTextureSize being used in a way so that it only cares about one of the input images:

T3Editor_24-03-21__11-57-06

teadrinker commented 8 months ago

It's tempting to try to use context.RequestedResolution (like the new SetRequestedResolution), however I see 2 problems with this approach:

Result cache system would need to be more complex (dirty-flag per requested resolution or no cache support for updateActions when resolution is different)
I feel isolated resolution override is a different use case from what SetRequestedResolution offers, and offering the latter as a solution to the former would cause confusing behaviour (resolution override that transcends operator boundaries would have unintended consequences etc)

pixtur commented 8 months ago

Thanks for the feedback. You're correct in that ideally all ops using [GetTextureSize] should publish this parameter to allow an override. In practice, I have to admit, I'm hesitant to implement everything that would be consistent because I'm afraid that that many operators would suffer from too many parameters. Also there is a small performance overhead by the added parameter.

On the other hand, I recently stumbled over the same issue. So I added [SetRequestedResultion] after our discussion on discord.