Skip to content

Axes3D voxels with alpha rendered wrong -- surfaces seem to cancel #9745

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

Open
lukasheinrich opened this issue Nov 10, 2017 · 20 comments
Open
Labels
keep Items to be ignored by the “Stale” Github Action topic: mplot3d

Comments

@lukasheinrich
Copy link

Bug report

Bug summary

The shading of the voxels when using alpha looks off, when they overlap, shades seem to cancel each other out.

Code for reproduction

from mpl_toolkits.mplot3d import Axes3D

test_data = np.array(
      [[[ 0.005,  0.005],
        [ 0.000,  0.035]],

       [[ 0.005,  0.000],
        [ 0.005,  0.010]]])
alphas = np.divide(test_data,np.max(test_data))/2.0

Actual outcome

screenshot

Expected outcome

GIven the data source, I would have expected a result more like this, which was produced with the code found at

http://stackoverflow.com/questions/30715083/python-plotting-a-wireframe-3d-cuboid?noredirect=1&lq=1

screenshot

Matplotlib version

  • Operating system: Mac OS X
  • Matplotlib version: 1.5.3
  • Matplotlib backend (print(matplotlib.get_backend())): module://ipykernel.pylab.backend_inline
  • Python version: Python 2.7.10
  • Jupyter version (if applicable): 1.0.0
@lukasheinrich lukasheinrich changed the title Axes3D voxels with alpha rendered wrong -- surfaces seem to cancel[ Axes3D voxels with alpha rendered wrong -- surfaces seem to cancel Nov 10, 2017
@lukasheinrich
Copy link
Author

lukasheinrich commented Nov 10, 2017

a simpler test dataset exhibiting the same behavior is

np.array(
      [[[ 0.,  1],
        [ 0.,  2]],

       [[ 0.,  0],
        [ 0.,  1]]])

notebooks are attached

https://github.com/lukasheinrich/code-snippets/blob/master/voxels.ipynb
https://github.com/lukasheinrich/code-snippets/blob/master/voxels_custom.ipynb

@jklymak
Copy link
Member

jklymak commented Nov 10, 2017

Crossref #9559?

@WeatherGod
Copy link
Member

no, this is different. The implementation drops faces for adjoining voxels. Perhaps we can make this optional?

@tacaswell tacaswell added this to the v2.2 milestone Nov 10, 2017
@lukasheinrich
Copy link
Author

lukasheinrich commented Nov 10, 2017

@WeatherGod yes that would be great. the internal faces are important if you want to do a 3d heatmap/ density plot.

@WeatherGod
Copy link
Member

I am putting together a PR for this feature (and might have found a bug in the original implementation, too), but I can't think of a good kwarg name for this. Any ideas?

@lukasheinrich
Copy link
Author

lukasheinrich commented Nov 13, 2017

maybe internal_faces ? with values True/False

@WeatherGod
Copy link
Member

Would unexposed_faces be clearer, perhaps?

@lukasheinrich
Copy link
Author

to me internal_faces is more understandable. Also googling the term brings up similar problems, so maybe it's not a bad term?

http://meshlabstuff.blogspot.ch/2009/04/how-to-remove-internal-faces-with.html

@WeatherGod
Copy link
Member

ok, internal_faces it is.

@lukasheinrich
Copy link
Author

just following up, what's the status on this -- anyways we can contribute?

@WeatherGod
Copy link
Member

WeatherGod commented Dec 4, 2017 via email

@WeatherGod
Copy link
Member

@lukasheinrich , the PR is #9927

@eric-wieser
Copy link
Contributor

eric-wieser commented Dec 11, 2017

This was a deliberate decision in #6404, but it wasn't a principled one. There was a choice between

  1. Drawing both faces in the same position, and letting z-fighting occur, making their color either a random function of viewing angle, or a function of draw order
  2. Computing a "mixed" color for the two faces, and then drawing one. This is a little more work, and requires you to come up with a good mixing algorithm. Obviously for your single-color case, the algorithm is trivial.
  3. Not drawing them at all

(1) could be fixed by drawing one-sided patches, but I'm not sure if matplotlib supports that.

(2) was more work that I was willing to invest for my problem (alpha was an afterthought), so I thought I'd leave it to someone more opinionated.

(3) was easy, so I went with it!

@eric-wieser
Copy link
Contributor

eric-wieser commented Dec 11, 2017

Note that you can use the approach here to force the culled faces to render, as well as avoiding z-fighting issues:
numpy logo translucent

@lukasheinrich
Copy link
Author

@eric-wieser yeah I saw that example, but it seems like a lot of bookkeeping/data-shuffling for a result that (to me) seems like a natural expectation. Would people still be interested in the work started in #9927 ?

@eric-wieser
Copy link
Contributor

I don't think #9927 is a good solution, because it overdraws two polygons of different colors in exactly the same spot

@lukasheinrich
Copy link
Author

I do like the gapped look from the example you posted. Maybe this would be a good fit (perhaps with a adjustable gapsize kwarg?

@eric-wieser
Copy link
Contributor

That might be reasonable, with gapsize=None or maybe gapsize=0 being the current behavior. I think it should be a fraction of the voxel edge lengths, to scale well to the non-uniform cases.

@kbasye00
Copy link

Hi, Any progress on this? I was surprised to end up with something like this (where the two middle voxels are the same color):

voxel_bug

If not, I might be interested in trying to work out the color blending based on https://en.wikipedia.org/wiki/Alpha_compositing#Alpha_blending Thanks!!

@github-actions
Copy link

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!

@github-actions github-actions bot added the status: inactive Marked by the “Stale” Github Action label Apr 24, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale May 24, 2023
@rcomer rcomer added the status: closed as inactive Issues closed by the "Stale" Github Action. Please comment on any you think should still be open. label May 30, 2023
@scottshambaugh scottshambaugh removed the status: inactive Marked by the “Stale” Github Action label May 16, 2024
@scottshambaugh scottshambaugh added keep Items to be ignored by the “Stale” Github Action and removed status: closed as inactive Issues closed by the "Stale" Github Action. Please comment on any you think should still be open. labels May 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
keep Items to be ignored by the “Stale” Github Action topic: mplot3d
Projects
None yet
Development

No branches or pull requests

9 participants