<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 21/02/2018 à 12:05, Stéphane
Mottelet a écrit :<br>
</div>
<blockquote cite="mid:98256e3d-9110-e818-7456-d7dc1d601c77@utc.fr"
type="cite">Hello,
<br>
<br>
The cube_scaling appeared with version 5.2 or 5.3 (I don't
remember) because the previous default behavior, which corresponds
to
<br>
<br>
cube_scaling="off"
<br>
<br>
could produce surfaces which were very hard to visualize with
default angles and hard to homogeneously "rotate" in the elevation
angle, when the surface is very flat. See this example:
<br>
<br>
clf
<br>
[x,y]=meshgrid(-1:0.1:1,-2:0.1:2);
<br>
surf(x,y,x.*y*1e-5)
<br>
gca().cube_scaling="off";
<br>
<br>
The default combination cube_scaling="on" and isoview="off"
corresponds to the default behavior in Matlab. Introducing the
cube_scaling property and its default value helps "migrating
users" as they obtain the same thing in both softwares.
<br>
<br>
Anyway, I don't think that the combination cube_scaling="off" and
isoview="off" has still an interest as it can produce the annoying
behavior of the above example. The default combination
cube_scaling="on" and isoview="off" allows the 3D object to fill
the whole 3D box whatever the proportions of the enclosing 2D
canvas, which is the expected default behavior.
<br>
<br>
Antoine's remark points out that cube_scaling="on" and
isoview="on" produces a plot whose proportions are completely
wrong with respect of the value of isoview="on". Adding in the
help page of "axes_properties/isoview " a sentence such as
<br>
<br>
If you want *real* isometric scales on all axes in 3D you have to
set cube_scaling property to 'off'
<br>
<br>
is not admissible.Setting the value of cube_scaling to the
opposite of the isoview value when the latter is changed could be
a solution. At least, when the high level isoview *command* is
used.
<br>
</blockquote>
<br>
The implementation of this <b>gca().cube_scaling</b> property is
unfortunately an example of the (too) raw and fast importation of
a feature answering in a truly awkward way to a true need.<br>
<br>
Extending some isometrical tunings in 3D by <i>adding</i> <i>an
axes property </i>instead of by <i>adding some new values to the
existing .isoview property </i>IMO was a costy error. Why ?<br>
<ul>
<li>adding a property whose job is not orthogonal to the <i>.isoview</i>
one makes the whole thing puzzling, and i guess the coding as
well. In 3D, what does this property, and what does the other
one in a dependent way? This is really annoying.<br>
<br>
</li>
<li>Due to a missing or poor initial analysis, the result is
rather poor. The point is that we may need isometrical modes
coupling any possible pair of directions, or even all of them.
This is why, from the "on"|"off" values available in 2D, new
.isoview values like "xy", "xz", "yz", "xyz" -- without creating
any new property -- would have been more handy and powerful. And
likely clearer and easier to code.<br>
Then, to actually get a cubic shape whatever are the x,y and z
scales, a last value "cube" could be possible, still without any
new property.<br>
</li>
</ul>
Analyzing a feature before implementing it has certainly a (low)
cost. The use of some poorly built features wastes a lot more time
for everyone and for a long time.<br>
It's a pity.<br>
<br>
Regards<br>
Samuel<br>
<br>
</body>
</html>