Skip to content

create set_offsets3d for PathCollection3d #19573

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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ianhi
Copy link
Contributor

@ianhi ianhi commented Feb 24, 2021

PR Summary

Add set and get_offsets3d to the PatchCollection3d object. The casting back to numpy array and transpose in the get method is for consistency with what the 2d version that returns a numpy array with shape (N, 2).

Does this need an example or can that be left to #19520?

PR Checklist

  • Has pytest style unit tests (and pytest passes).
  • Is Flake 8 compliant (run flake8 on changed files to check).
  • New features are documented, with examples if plot related.
  • Documentation is sphinx and numpydoc compliant (the docs should build without error).
  • Conforms to Matplotlib style conventions (install flake8-docstrings and run flake8 --docstring-convention=all).
  • New features have an entry in doc/users/next_whats_new/ (follow instructions in README.rst there).
  • API changes documented in doc/api/next_api_changes/ (follow instructions in README.rst there).

Copy link
Member

@timhoffm timhoffm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry to be so critical, but 3D is a mess and without a clear picture where we want to go we risk making it only worse.

We need a bit more thinking to get a consistent 3D API. We currently have,

  • Text3D.set_positions_3d, having optional zdir
  • Lines3D.set_data_3d , not having zdir`

Do we want a zdir parameter for data setters?

Also the 3D upcasting is solved differently. Text3D takes zdir but defers the data adaption to draw. In contrast Line3D doesn't even accept zdir in __init__ instead, Axes3D.plot calls line2d_to_3d() which passes zdir to set_3d_properties() and immediately modifies the data. Thus Text3D.get_positions_3d and Line3D.get_data_3d have different interpretations of the returned data, wrt. if zdir is applied.

When and how do we want to apply zdir? What interpretation should the getter return?

@ianhi
Copy link
Contributor Author

ianhi commented Feb 28, 2021

hmm yeah. Maybe it's best to close this PR and have that worked out on an issue?

One other thing to note is that looking at the tutorial the descriptions of zdir in the docstrings vary wildly:

When plotting 2D data, the direction to use as z ('x', 'y' or 'z').

The direction to use.

The axis direction for the zs. This is useful when plotting 2D data on a 3D Axes. The data must be passed as xs, ys. Setting zdir to 'y' then plots the data to the x-z-plane.

So until now I didn't even really understand what it was for - which I think is evidence for it's currently confused state of API. It's also weird to me that changing the zdir will affect what happens to plots where I fully specify xyz, it seems like it only ought to affect 2D data (or at least only calls where at least of xyz is a scalar).

Sorry to be so critical,

I think we have different definitions of "so critical" :)

and without a clear picture where we want to go we risk making it only worse.

Agreed, I was being irresponsible by jumping the gun to scratch the single itch I had rather than the larger picture.

@QuLogic
Copy link
Member

QuLogic commented Mar 2, 2021

Text3D takes zdir but defers the data adaption to draw.

This is something I implemented in #18525 when adding the getters/setters on purpose, and I would do the same for the other 3D artists (#18932) except that it requires some work to fix legends.

I can't say exactly what the API should be, but we should try to defer as much as possible the conversion to 2D to draw. Eventually, if we have a better 3D renderer, then it will be able to ingest the 3D values directly there instead.

@timhoffm timhoffm added the status: needs comment/discussion needs consensus on next step label Mar 6, 2021
@jklymak jklymak marked this pull request as draft May 15, 2021 15:26
Copy link

Since this Pull Request has not been updated in 60 days, it has been marked "inactive." This does not mean that it will be closed, though it may be moved to a "Draft" state. This helps maintainers prioritize their reviewing efforts. You can pick the PR back up anytime - please ping us if you need a review or guidance to move the PR forward! If you do not plan on continuing the work, please let us know so that we can either find someone to take the PR over, or close it.

@github-actions github-actions bot added the status: inactive Marked by the “Stale” Github Action label Nov 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: inactive Marked by the “Stale” Github Action status: needs comment/discussion needs consensus on next step status: needs rebase topic: mplot3d
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants