-
-
Notifications
You must be signed in to change notification settings - Fork 21.2k
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
Fix draw order of transparent materials with multiple directional lights #47129
Fix draw order of transparent materials with multiple directional lights #47129
Conversation
Never mind, this doesn't seem to work in all cases yet. |
OK, now it also respects the material priority among multiple transparent shaded materials. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On a preliminary review, this looks quite good. I need to spend more time reviewing before I approve though.
I have a few performance concerns in the back of my mind, but I think overall it shouldn't be too bad as not many people use multiple directional lights.
Another related issue, that does not get fixed by this (i.e. it did not work before, nor does it now): That means you can't have a scene with two transparent meshes and two lights, with the first mesh being lit by the first light and the second mesh lit by the second light. Fixing that would require grouping the elements by lights... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code makes sense. I did some testing and everything seems to work as expected :)
I don't know if it's worth merging for 3.3 though. On one side, if we are fixing multiple directional lights in 3.3 we might as well do the best we can. On the other, we are introducing more chances for regressions in a late release candidate, for something that is not very widely used...
tl;dr
Looks great, we need to decide if we merge before or after 3.3 :)
I think it's better to play it safe and merge for 3.4. The two commits should be squashed into one I guess (or if the second one makes sense as standalone, it should have a clearer title). |
d71bd37
to
63b7b77
Compare
Squashed and rebased to latest 3.x. |
Thanks! |
Fixes #47078