Thanks to visit codestin.com
Credit goes to github.com

Skip to content

BUG: Fix face orientations of bar3d #12259

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 2 commits into from
Nov 11, 2018
Merged

BUG: Fix face orientations of bar3d #12259

merged 2 commits into from
Nov 11, 2018

Conversation

eric-wieser
Copy link
Contributor

@eric-wieser eric-wieser commented Sep 25, 2018 •
edited
Loading

Fixes #12138, which is caused by these incorrect orientations

I was hoping I could modify the existing bar3d test with something like:

@pytest.mark.parametrize('azim', [-60, 60])
@image_comparison(
    baseline_images=['bar3d_shaded'],
    remove_text=True,
    extensions=['png']
)
def test_bar3d_shaded(azim):
    ...
    ax.view_init(azim=azim)

but I couldn't work out how to make parametrize work with the baseline_images argument of image_comparison

@eric-wieser
Copy link
Contributor Author

eric-wieser commented Sep 25, 2018 •
edited
Loading

Worked out how to parametrize the test.

Let me know if you'd like to see the test in a separate PR, to make the result easier to compare.

Edit: Done in #12273 - will rebase this after that.

@dstansby dstansby added topic: mplot3d MEP: MEP13 artist properties and removed MEP: MEP13 artist properties labels Sep 25, 2018
@dstansby dstansby added this to the v3.1 milestone Sep 25, 2018
@eric-wieser eric-wieser force-pushed the bar3d-counterclockwise-faces branch from c894a71 to d6d43e9 Compare September 25, 2018 16:33
@dstansby
Copy link
Member

Would it be possible to stick the test images on different axes on the same figure (something like subplots(2, 2)? This will save a few images, and also make a nice side by side comparison of the different viewing angles.

@eric-wieser
Copy link
Contributor Author

I avoided that because it leads to a 100% diff in the target image, and also removes the ability to use pytest.parametrize.

However, I'm not super committed to that decision - if you think that'd be best, can you comment to that effect on #12273?

@eric-wieser
Copy link
Contributor Author

@dstansby: How does #12292 look?

@eric-wieser eric-wieser force-pushed the bar3d-counterclockwise-faces branch from d6d43e9 to b527911 Compare September 26, 2018 16:43
@eric-wieser
Copy link
Contributor Author

eric-wieser commented Sep 26, 2018 •
edited
Loading

Updated. Something odd seems to be happening though - the light source is above the plot, yet it renders as if it were below. - resolved - _generate_normals was wrong

Might also be worth considering changing the default lighting angle so that it doesn't hit cuboids at exactly 45 degrees causing adjacent faces to be the same color.

@eric-wieser eric-wieser force-pushed the bar3d-counterclockwise-faces branch from b527911 to e9b652e Compare September 26, 2018 17:07
@ImportanceOfBeingErnest
Copy link
Member

I would have thought that the reason for the two bright faces is that, independent of the viewing angle, you have one bright face facing the viewer. Is this undesireable?
I think it would be good to see the same case visually with a before/after - comparisson here.

@eric-wieser
Copy link
Contributor Author

eric-wieser commented Oct 4, 2018 •
edited
Loading

@ImportanceOfBeingErnest: you have that before/after comparision in the rich diff of the result image

An argument for why this should be fixed - for graphs containing both a surface and a bar plot, this will make the shading consistent.

@ImportanceOfBeingErnest
Copy link
Member

So for surface plots the lightsource rotates together with the coordinate frame as well. I never noticed that, but now that you mention it, it's clear. (Somehow undesired in my eyes, I would much rather have the lightsource constant in the room and rotate the plot alone, instead of rotating the whole room with its lights, but that's not for debate here I guess.)

Would there be any way to make it consistent for the zero-extent bar as well?

image

@eric-wieser
Copy link
Contributor Author

eric-wieser commented Oct 20, 2018 •
edited
Loading

Ugh, I didn't see you'd replied here.

Somehow undesired in my eyes, I would much rather have ...

I agree, that would be a neat feature. I'm working on adding shading to some extra plots- once that's done, maybe I'll investigate a fixed light source.

Would there be any way to make it consistent for the zero-extent bar as well?

That's a bug I'd rather not deal with yet that comes down to z-sorting coincident faces. We only got away with it before because the upper and lower faces were the same color. I'd prefer to leave that to a later PR, where the approach would be either:

  • Sort by normal vector in the case of coincident faces
  • Cull all faces with a back-pointing normal vector
    At least right now it looks correct from the top, which is probably the more important side.

Before I can reasonably do that, I'd like to get this and then #12136 in.

@eric-wieser eric-wieser mentioned this pull request Oct 31, 2018
Merged
6 tasks
anntzer
anntzer reviewed Oct 31, 2018
View reviewed changes
@anntzer
Copy link
Contributor

anntzer commented Oct 31, 2018

Why did the notshaded baseline image change?

@eric-wieser
Copy link
Contributor Author

eric-wieser commented Oct 31, 2018 •
edited
Loading

Why did the notshaded baseline image change?

Because some faces are now rendered with the points in reverse order, and I guess the renderer somehow cares about that. The diff can be seen here:

image

There's a handful of changed pixels (shown in red) along the bottom axis, and the other edges.

@eric-wieser eric-wieser force-pushed the bar3d-counterclockwise-faces branch from e9b652e to 7bcc001 Compare October 31, 2018 15:57
@eric-wieser
Copy link
Contributor Author

Not sure why CI fails

@eric-wieser
Copy link
Contributor Author

Looks like it maybe just needs rebasing on top of a commit with CI configured. Shall I go ahead and do that?

@eric-wieser
STY: Add trailing commas
304859e 
This makes the next commit easier to follow
@eric-wieser
BUG: Fix face orientations of bar3d
05c60cc 
Fixes matplotlib#12138, which is caused by these incorrect orientations.

This also corrects _generate_normals to use a counterclockwise convention
@eric-wieser eric-wieser force-pushed the bar3d-counterclockwise-faces branch from 7bcc001 to 67fc7c1 Compare November 10, 2018 21:35
@eric-wieser
Copy link
Contributor Author

@dstansby: Rebased

@eric-wieser eric-wieser force-pushed the bar3d-counterclockwise-faces branch from 67fc7c1 to 05c60cc Compare November 10, 2018 22:14
@timhoffm timhoffm merged commit 3e90025 into matplotlib:master Nov 11, 2018
@eric-wieser
Copy link
Contributor Author

Was hoping you'd merge rather than squash to keep me from having to rebase. Oh well - thanks for putting this in anyway!

@QuLogic
Copy link
Member

QuLogic commented Nov 11, 2018

That setting is sticky, so I don't know if @timhoffm did that on purpose (I wouldn't have squashed for this PR). If it wasn't on purpose, please @timhoffm be careful on the next merge.

@eric-wieser
Copy link
Contributor Author

The stickiness has caught me out in the past too.

@ImportanceOfBeingErnest
Copy link
Member

On the weekly call on 29 oct it was discussed that all PRs should be squashed-merged if possible to keep the history cleaner and reduce security risks. I think if someone does not want this to happen for their PR they should mention it.

@QuLogic
Copy link
Member

QuLogic commented Nov 14, 2018

Hmm, that probably should be announced. I'm also not particularly for it when it's an experienced contributor.

@timhoffm
Copy link
Member

Sorry if squashing caused troubles. The changes seemed rather small and related so that I did not consider it important to keep separate commits.

+1 that an author should explicitly mention that commits should not be squashed.

@ImportanceOfBeingErnest ImportanceOfBeingErnest mentioned this pull request Feb 4, 2019
Merged
6 tasks
@eric-wieser eric-wieser deleted the bar3d-counterclockwise-faces branch March 23, 2019 18:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@anntzer anntzer anntzer approved these changes

@timhoffm timhoffm timhoffm approved these changes

Assignees
No one assigned
Labels
topic: mplot3d
Projects
None yet
Milestone
v3.1.0
Development

Successfully merging this pull request may close these issues.
6 participants
@eric-wieser @dstansby @ImportanceOfBeingErnest @anntzer @QuLogic @timhoffm