-
-
Notifications
You must be signed in to change notification settings - Fork 21.3k
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
[3.x] Fix AtlasTexture
nesting
#56795
[3.x] Fix AtlasTexture
nesting
#56795
Conversation
I once went down that rabbit hole and there's still a lot of horrible ways to trigger cyclic dependencies by mixing and matching proxy texture formats, e.g.:
Basically any |
Maybe adding a method like |
11ba471
to
63fd172
Compare
I've actually removed that cyclic dependency check as that wasn't really a proper solution, it was just checking one specific case. And a proper solution (whatever it will be) can be made in another PR. |
Thanks! |
When drawing an
AtlasTexture
it was directly calling theVisualServer
by itself instead of just forwarding the draw request to the sourceatlas
texture (with the proper rect/region passed in). As a result anAtlasTexture
being a sourceatlas
of anotherAtlasTexture
could have resulted in incorrect rendering. This should be fixed now (assuming other methods work as they're supposed to).With this being fixed it means that pretty much nothing external should care if some
Texture
is actually anAtlasTexture
as there should be no need to treat it as some special case whereAtlasTexture
'sregion
and/ormargin
needs to be manually taken into account or something like that. If there's such special casing somewhere then it's very likely there's something wrong conceptually in there (asAtlasTexture
should probably be handling this stuff by itself).So for example fix in #37939 was conceptually wrong, the same as my fix in #51030 on top of it. I've kind of reverted them as such special casing is not needed in there (it was never needed in there, the bug was elsewhere). Now it should work properly.
Fixes #42806.
Fixes #56767.
Just note that for the frames already saved with the incorrect data above issues still hold.