[Scilab-users] surf & isoview: bug or unexpected "feature"

classic Classic list List threaded Threaded
7 messages Options
Antoine Monmayrant Antoine Monmayrant
Reply | Threaded
Open this post in threaded view
|

[Scilab-users] surf & isoview: bug or unexpected "feature"

Hi all,


I am a bit surprised by the way isoview acts on a surf plot.
It seems to just scale the x,y,z axis so that the plot is inside an
isometric 3D cube.
I was expecting an aspect ratio that depends on the Z matrix value and
size or on the X,Y coordinate vectors and the Z matrix value.
Here is an example:

//without X,Y axis: expecting an aspect ratio in the (x,y) plan
corresponding to the dimensions of the Z matrix
Z=rand(10,30);
h=scf();
surf(Z);
isoview("on");//we should see a 3/1 aspect ratio in the x/Y plane but we
have square

//trying with X,Y coordinates: expecting an the plot to fit inside a
"cube" with aspect ratios along the x,y & z directions
//that depends on max(X)-min(X), max(Y)-min(Y) & max(Z)-min(Z)
Z=rand(10,30);
X=1:size(Z,2);
Y=1:size(Z,1);
h=scf();
surf(X,Y,Z);
isoview("on");//we should see a 3/1 aspect ratio in the x/Y plane but we
have square


Am I the only one to expect this behaviour?


Antoine



--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

  Antoine Monmayrant LAAS - CNRS
  7 avenue du Colonel Roche
  BP 54200
  31031 TOULOUSE Cedex 4
  FRANCE

  Tel:+33 5 61 33 64 59
 
  email : [hidden email]
  permanent email : [hidden email]

+++++++++++++++++++++++++++++++++++++++++++++++++++++++

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Antoine Monmayrant Antoine Monmayrant
Reply | Threaded
Open this post in threaded view
|

Re: surf & isoview: bug or unexpected "feature"

OK, answering my own question:

It seems that when calling surf(), the cube_scaling property of the
current axis is set to "on", which results in the observed behaviour.
Manually resetting to its default value "off", gives me the expected
behaviour.
Should I fill a bug about the absence of cube_scaling mention on the
help pages of surf() and isoview() ?

Antoine

Le 21/02/2018 à 10:59, Antoine Monmayrant a écrit :

> Hi all,
>
>
> I am a bit surprised by the way isoview acts on a surf plot.
> It seems to just scale the x,y,z axis so that the plot is inside an
> isometric 3D cube.
> I was expecting an aspect ratio that depends on the Z matrix value and
> size or on the X,Y coordinate vectors and the Z matrix value.
> Here is an example:
>
> //without X,Y axis: expecting an aspect ratio in the (x,y) plan
> corresponding to the dimensions of the Z matrix
> Z=rand(10,30);
> h=scf();
> surf(Z);
> isoview("on");//we should see a 3/1 aspect ratio in the x/Y plane but
> we have square
>
> //trying with X,Y coordinates: expecting an the plot to fit inside a
> "cube" with aspect ratios along the x,y & z directions
> //that depends on max(X)-min(X), max(Y)-min(Y) & max(Z)-min(Z)
> Z=rand(10,30);
> X=1:size(Z,2);
> Y=1:size(Z,1);
> h=scf();
> surf(X,Y,Z);
> isoview("on");//we should see a 3/1 aspect ratio in the x/Y plane but
> we have square
>
>
> Am I the only one to expect this behaviour?
>
>
> Antoine
>
>
>

--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++

  Antoine Monmayrant LAAS - CNRS
  7 avenue du Colonel Roche
  BP 54200
  31031 TOULOUSE Cedex 4
  FRANCE

  Tel:+33 5 61 33 64 59
 
  email : [hidden email]
  permanent email : [hidden email]

+++++++++++++++++++++++++++++++++++++++++++++++++++++++

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: surf & isoview: bug or unexpected "feature"

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.


S.

Le 21/02/2018 à 11:06, Antoine Monmayrant a écrit :

> OK, answering my own question:
>
> It seems that when calling surf(), the cube_scaling property of the
> current axis is set to "on", which results in the observed behaviour.
> Manually resetting to its default value "off", gives me the expected
> behaviour.
> Should I fill a bug about the absence of cube_scaling mention on the
> help pages of surf() and isoview() ?
>
> Antoine
>
> Le 21/02/2018 à 10:59, Antoine Monmayrant a écrit :
>> Hi all,
>>
>>
>> I am a bit surprised by the way isoview acts on a surf plot.
>> It seems to just scale the x,y,z axis so that the plot is inside an
>> isometric 3D cube.
>> I was expecting an aspect ratio that depends on the Z matrix value
>> and size or on the X,Y coordinate vectors and the Z matrix value.
>> Here is an example:
>>
>> //without X,Y axis: expecting an aspect ratio in the (x,y) plan
>> corresponding to the dimensions of the Z matrix
>> Z=rand(10,30);
>> h=scf();
>> surf(Z);
>> isoview("on");//we should see a 3/1 aspect ratio in the x/Y plane but
>> we have square
>>
>> //trying with X,Y coordinates: expecting an the plot to fit inside a
>> "cube" with aspect ratios along the x,y & z directions
>> //that depends on max(X)-min(X), max(Y)-min(Y) & max(Z)-min(Z)
>> Z=rand(10,30);
>> X=1:size(Z,2);
>> Y=1:size(Z,1);
>> h=scf();
>> surf(X,Y,Z);
>> isoview("on");//we should see a 3/1 aspect ratio in the x/Y plane but
>> we have square
>>
>>
>> Am I the only one to expect this behaviour?
>>
>>
>> Antoine
>>
>>
>>
>

--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: surf & isoview: bug or unexpected "feature"

In reply to this post by Antoine Monmayrant
Hi Antoine and Stéphane,

Please look at https://codereview.scilab.org/#/c/18857/ and its header,
and try
--> uman isoview! @

Samuel

Le 21/02/2018 à 10:59, Antoine Monmayrant a écrit :

> Hi all,
>
>
> I am a bit surprised by the way isoview acts on a surf plot.
> It seems to just scale the x,y,z axis so that the plot is inside an
> isometric 3D cube.
> I was expecting an aspect ratio that depends on the Z matrix value and
> size or on the X,Y coordinate vectors and the Z matrix value.
> Here is an example:
>
> //without X,Y axis: expecting an aspect ratio in the (x,y) plan
> corresponding to the dimensions of the Z matrix
> Z=rand(10,30);
> h=scf();
> surf(Z);
> isoview("on");//we should see a 3/1 aspect ratio in the x/Y plane but
> we have square
>
> //trying with X,Y coordinates: expecting an the plot to fit inside a
> "cube" with aspect ratios along the x,y & z directions
> //that depends on max(X)-min(X), max(Y)-min(Y) & max(Z)-min(Z)
> Z=rand(10,30);
> X=1:size(Z,2);
> Y=1:size(Z,1);
> h=scf();
> surf(X,Y,Z);
> isoview("on");//we should see a 3/1 aspect ratio in the x/Y plane but
> we have square
>
>
> Am I the only one to expect this behaviour?
>
>
> Antoine
>
>
>

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: surf & isoview: bug or unexpected "feature"

Great ! But in this case I would add also

isoview('off') missed switching .cube_scaling='on'

S.

Le 21/02/2018 à 13:37, Samuel Gougeon a écrit :

> Hi Antoine and Stéphane,
>
> Please look at https://codereview.scilab.org/#/c/18857/ and its header,
> and try
> --> uman isoview! @
>
> Samuel
>
> Le 21/02/2018 à 10:59, Antoine Monmayrant a écrit :
>> Hi all,
>>
>>
>> I am a bit surprised by the way isoview acts on a surf plot.
>> It seems to just scale the x,y,z axis so that the plot is inside an
>> isometric 3D cube.
>> I was expecting an aspect ratio that depends on the Z matrix value
>> and size or on the X,Y coordinate vectors and the Z matrix value.
>> Here is an example:
>>
>> //without X,Y axis: expecting an aspect ratio in the (x,y) plan
>> corresponding to the dimensions of the Z matrix
>> Z=rand(10,30);
>> h=scf();
>> surf(Z);
>> isoview("on");//we should see a 3/1 aspect ratio in the x/Y plane but
>> we have square
>>
>> //trying with X,Y coordinates: expecting an the plot to fit inside a
>> "cube" with aspect ratios along the x,y & z directions
>> //that depends on max(X)-min(X), max(Y)-min(Y) & max(Z)-min(Z)
>> Z=rand(10,30);
>> X=1:size(Z,2);
>> Y=1:size(Z,1);
>> h=scf();
>> surf(X,Y,Z);
>> isoview("on");//we should see a 3/1 aspect ratio in the x/Y plane but
>> we have square
>>
>>
>> Am I the only one to expect this behaviour?
>>
>>
>> Antoine
>>
>>
>>
>
> _______________________________________________
> users mailing list
> [hidden email]
> http://lists.scilab.org/mailman/listinfo/users


--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: surf & isoview: bug or unexpected "feature"

Le 21/02/2018 à 13:47, Stéphane Mottelet a écrit :
> Great ! But in this case I would add also
>
> isoview('off') missed switching .cube_scaling='on'

Done. The fixed behaviour of isoview() is now available in Scilab 6.1.0-
(by now, continuous built of the master)

Samuel

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by mottelet
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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users