scene aspectmodes "cube" or "manual" do not work with Scatter3D

[Chandler]

Example from the plotly docs, with aspect mode set to cube.

import plotly.graph_objects as go
import numpy as np

# Helix equation
t = np.linspace(0, 10, 50)
x, y, z = np.cos(t), np.sin(t), t

layout = go.Layout(scene=dict(aspectmode="cube"))

fig = go.Figure(
	data=[go.Scatter3d(x=x, y=y, z=z,mode='markers')],
	layout=layout)
fig.show()

On the x and y axis, one grid unit is length 0.5. On the z axis one grid unit is length 2.

These should be displayed with equal lengths if the aspect ratio is a cube. Same issue with 'go.Layout(scene=dict(aspectmode="manual", aspectratio=dict(x=1, y=1, z=1)))'

This help post indicates this should work or worked in the past cc @empet
https://community.plotly.com/t/creating-a-3d-scatterplot-with-equal-scale-along-all-axes/15108

Thank you.

[iiwolf]

This has been frustrating for me too. As well as these folks.

https://community.plotly.com/t/creating-a-3d-scatterplot-with-equal-scale-along-all-axes/15108/7
https://stackoverflow.com/questions/58087566/r-plotly-aspectmode-cube-not-making-axes-equal-in-3d-scatter-plot
https://stackoverflow.com/questions/69295750/plotly-scatter3d-aspectmode-not-consistent-across-axes

Any work around?

[antoniovandre2]

My solution was by two invisible points "rgba(255, 255, 255, 0)", one with the coordinates with the highest value obtained, and the other with the coordinates with the lowest value obtained.

[treder]

The problem hasn't been fixed yet it seems, I'm having it too in plotly 5.9.0

[empet]

There is NO bug in how scene_aspectmode behaves.
help(go.layout.Scene.apectmode) displays the following information:

If "cube", this scene's axes are drawn as a cube, regardless of
the axes' ranges. If "data", this scene's axes are drawn in
proportion with the axes' ranges. If "manual", this scene's
axes are drawn in proportion with the input of "aspectratio"
(the default behavior if "aspectratio" is provided). If "auto",
this scene's axes are drawn using the results of "data" except
when one axis is more than four times the size of the two
others, where in that case the results of "cube" are used.
The 'aspectmode' property is an enumeration that may be specified as:
- One of the following enumeration values:
['auto', 'cube', 'data', 'manual']

Some users who have posted here or on the plotly forum consider scene_aspectmode='cube' to be buggy because they reinterpreted in their own terms, what effect this setting should have, namely, that regardless of the grid unit on the axes, they must be displayed at the same length. FALSE! When scene_aspectmode="cube" the scene is displayed as three faces of a cube.

When setting scene_aspectmode="manual", you must also set scene_aspectratio=dict(x=a, y=b, z=c) for some a, b, c >0.

[mjstahlberg]

It seems that many users, myself included, expect equally scaled axes from either scene_aspectmode="cube" or scene_aspectmode="manual" in combination with scene_aspectratio=dict(x=1, y=1, z=1). Both approaches do not meet the expectation, but at least for me, scene_aspectratio="data" gives me what I want: non-spherical ellipsoids and spheres being distinguishable when showticklabels=False.

[stellarpower]

Personally, I am trying to plot data in 3D-space. I battled with matplotlib, then switched to Plotly, only to find the same problem. For 3D co-ordinates, it doesn't make much sense to have the canvas/viewport/whatever it's called specifically in Plotly, at an aspect ratio tied to my data, and it definitely doesn't make sense to autoscale the axes to the variance of the data. In fact I've seen reports before where someone has not bothered to label their axes (something that, coming from a background in physics, was always drilled into me is a capital offence) and come to completely incorrect conclusions about their data when everything was in fact fine, but two aces had been blown up to fit the others, and the person presenting their conclusions had not clocked this. Just mentioning this because based on that experience, this goes beyond just a UI thing, whilst it's clearly that person's fault, it can be damaging to data without an easy way to do this and when people quickly type things without using their brains.

I'd like a canvas that is a cube, and for my data to be scaled uniformly so that they fit on the screen, similarly to how and 3D graphics package (CloudCompare, MeshLab, Blender, etc.) would do. It therefore feels like this should be achievable with a single keyword argument somewhere, and not something that requires e.g. the user-programmer to iterate over their data and manually find the centre and limits and pipe those in, as I am having to resort to in MPL.