[Scilab-users] .isoview (and .cube_scaling) design <= Re: surf & isoview: bug or unexpected "feature"

[Samuel Gougeon]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20180530/9c11d1ce/attachment.htm>