Le 21/02/2018 à 12:05, Stéphane Mottelet a écrit :
Hello,
The cube_scaling appeared with version 5.2 or 5.3 (I don't remember)
because the previous default behavior, which corresponds to
cube_scaling="off"
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:
clf
[x,y]=meshgrid(-1:0.1:1,-2:0.1:2);
surf(x,y,x.*y*1e-5)
gca().cube_scaling="off";
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.
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.
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
If you want *real* isometric scales on all axes in 3D you have to set
cube_scaling property to 'off'
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.
The implementation of this *gca().cube_scaling* 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.
Extending some isometrical tunings in 3D by /adding/ /an axes property
/instead of by /adding some new values to the existing .isoview property
/IMO was a costy error. Why ?
* adding a property whose job is not orthogonal to the /.isoview/ 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.
* 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.
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.
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.
It's a pity.
Regards
Samuel
_______________________________________________
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users
