-
-
Notifications
You must be signed in to change notification settings - Fork 8k
feat(3d): improve plot_surface shading logic #30424
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
base: main
Are you sure you want to change the base?
Conversation
- Update plot_surface function to use "auto" as default shading mode - Add tests to verify new shading behavior with different parameters - Improve documentation for plot_surface function
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.
Hi @MengAiDev, thanks for your first pull request for matplotlib!
I left some comments with some things to change, so leave a comment when you've addressed them and I can take another look. Also please don't hesitate to ask if you have any questions.
lib/mpl_toolkits/mplot3d/axes3d.py
Outdated
i.e. neither *cmap* nor *facecolors* is given. | ||
|
||
Furthermore, shading is generally not compatible with colormapping and | ||
``shade=True, cmap=...`` will raise an error. |
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.
There is not an error being raised in this case AFAICT, so that should be added or this part of the docstring removed. My personal take is that we should not error, and instead warn that colors might not be as expected and still make the plot. @timhoffm thoughts?
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.
I suggested this behavior in #30290 (comment). My argument is that that combination is fundamentally not reasonable because it distorts the mapped colors and thus breaks the purpose of colormapping. If this is our point of view, erroring out is appropriate - prohibit unreasonable things and not just warn that they are unreasonable.
One can take another point of view that the depth-shading is important to get the 3d impression and exact coloring is less important (likely also depends on the colormap used - colormaps that mainly change hue should work better here). If we see this as a valid use case, I would not warn at all at runtime, because the user has to explicitly opt into the behavior by passing both arguments. We then only should add a note to the docstring.
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.
I would prefer the latter - there are use cases where colormapping is a visual aid rather than the only display of information, and the shading helps 3D interpretability. The one that I'm thinking about is coloring by Z value.
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.
Sounds reasonable.
Co-authored-by: Scott Shambaugh <[email protected]>
# Remove the None check as it doesn't seem to be needed | ||
|
||
# Raise error if shade=True and cmap is provided as documented |
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.
# Remove the None check as it doesn't seem to be needed | |
# Raise error if shade=True and cmap is provided as documented |
These comments do note make sense. AFAICS the first is a relic, the second only restates what the code does
PR summary
Fix: #30290
@tacaswell, @story645