I need to think on this a bit. The original code intentionally flipped the display upside down, but I haven't a clue why anyone would want that. But, just because I can't think of a reason right now doesn't mean that it isn't supposed to be this way.

I found a use case, at least, that will make this fix useful.

Fromhttps://matplotlib.org/examples/mplot3d/rotate_axes3d_demo.html

With changing Elevation angle from (0-360) as an example.

In the current code base, the rotation will be discontinued at 270(i.e the 3d plot got flipped by 180deg) (see below)

With the fixed code , it will complete one whole rotation(see the gif provided)

If you are referring to the flipping behaviour of the variable V, then I think it is a normal behaviour. The fix does not attempt to change that, the fix only normalizes the input angle on initialization of the view, to make it consistent throughout the plotting. As you might notice, it is not only the plot got flipped on z-direction 180 degree, the azimuth also got flipped on the original bug report.

hey@WeatherGod , have you made up your mind?

you know what? That animation convinced me. I'll approve.

This still strikes me as the wrong fix. We should be normalizing it when we render, not when we store - there might be graphs that want to do something clever with the view angles, and expect them to be continuous.

it seems to me view_init is a method elevation and azimuth used in rendering.(they have to be stored some where)

if there are need for raw angle operation (non normalized) on elev and azimu, then have it done by implementing getter and setter on these two attributes.

and when start drawing, a call to view_init should normalize the operated angles.

And i dont understand what do you mean by "continuous" ..

@eric-wieser any thought ?

Re milestoning 3.1 as this looks to need more discussion....

I've rolled the fix for the original bug into PR#21426, I believe this PR can be closed.

#21426 has been merged and so this PR can now be closed@WeatherGod.