-
-
Notifications
You must be signed in to change notification settings - Fork 7.5k
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
BUG: plot_surface ignores lightsource when cmap/facecolors are not specified #8877
Comments
A demo: import numpy as np
from matplotlib import pyplot as plt
from mpl_toolkits.mplot3d import Axes3D
x, y = np.mgrid[-2:2:5j,-2:2:5j]
z = x * y
|
This should probably remain open until some image-comparison tests are added to confirm it is fixed. I suspect the last issue still persists |
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help! |
Three different, undocumented, cases that I think should be the same:
plot_surface(..., shade=True, lightsource=..., cmap=..., facecolors="garbage")
- usesLightSource.shade
, which does some messy and unnecessary trig inLightSource.hillshade
, using the orientation of the lightsource.plot_surface(..., shade=True, lightsource=..., cmap=...)
- uses_shade_colors
, which does a more sensible vector-based approach, but hard-codes a[-1, -1, 0.5]
normal vector, rather than respecting the lightsource direction.plot_surface(..., shade=True, lightsource=..., facecolors="garbage")
- as aboveRegarding (2), I think that there is a typo in
axes3d.py
, and this change should be made:It seems dumb to only calculate face colors if the user already asked for different ones.
Regarding (3) - I think it would be useful to unify the shading into a normal-vector based approach, which I might try in a later patch
The text was updated successfully, but these errors were encountered: