Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Magic Resolution consistency/override #399

Open
teadrinker opened this issue Mar 20, 2024 · 3 comments
Open

Magic Resolution consistency/override #399

teadrinker opened this issue Mar 20, 2024 · 3 comments

Comments

@teadrinker
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Collaborator

pixtur commented Mar 27, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants