Skip to content

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

Open

Description

@lukasheinrich

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

Activity

  1. changed the title [-]Axes3D voxels with alpha rendered wrong -- surfaces seem to cancel[[/-] [+]Axes3D voxels with alpha rendered wrong -- surfaces seem to cancel[/+] on Nov 10, 2017
  2. lukasheinrich commented on Nov 10, 2017

    @lukasheinrich
    Author

    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

  3. jklymak commented on Nov 10, 2017

    @jklymak
    Member

    Crossref #9559?

  4. WeatherGod commented on Nov 10, 2017

    @WeatherGod
    Member

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

  5. added this to the milestone on Nov 10, 2017
  6. lukasheinrich commented on Nov 10, 2017

    @lukasheinrich
    Author

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

  7. WeatherGod commented on Nov 13, 2017

    @WeatherGod
    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?

  8. lukasheinrich commented on Nov 13, 2017

    @lukasheinrich
    Author

    maybe internal_faces ? with values True/False

  9. WeatherGod commented on Nov 13, 2017

    @WeatherGod
    Member

    Would unexposed_faces be clearer, perhaps?

  10. lukasheinrich commented on Nov 13, 2017

    @lukasheinrich
    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

  11. WeatherGod commented on Nov 13, 2017

    @WeatherGod
    Member

    ok, internal_faces it is.

  12. lukasheinrich commented on Dec 4, 2017

    @lukasheinrich
    Author

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

  13. WeatherGod commented on Dec 4, 2017

    @WeatherGod
    Member
  14. WeatherGod commented on Dec 4, 2017

    @WeatherGod
    Member

    @lukasheinrich , the PR is #9927

  15. eric-wieser commented on Dec 11, 2017

    @eric-wieser
    Contributor

    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!

  16. eric-wieser commented on Dec 11, 2017

    @eric-wieser
    Contributor

    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

  17. lukasheinrich commented on Jan 19, 2018

    @lukasheinrich
    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 ?

  18. eric-wieser commented on Jan 19, 2018

    @eric-wieser
    Contributor

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

  19. lukasheinrich commented on Jan 19, 2018

    @lukasheinrich
    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?

  20. eric-wieser commented on Jan 19, 2018

    @eric-wieser
    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.

  21. kbasye00 commented on Jul 11, 2020

    @kbasye00

    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!!

  22. github-actions commented on Apr 24, 2023

    @github-actions

    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!

  23. added
    status: closed as inactiveIssues closed by the "Stale" Github Action. Please comment on any you think should still be open.
    on May 30, 2023
  24. added
    keepItems to be ignored by the “Stale” Github Action
    and removed
    status: inactiveMarked by the “Stale” Github Action
    status: closed as inactiveIssues closed by the "Stale" Github Action. Please comment on any you think should still be open.
    on May 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    keepItems to be ignored by the “Stale” Github Actiontopic: mplot3d

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions