Scatter3 does not update axes limits when translated

Hi, I am having trouble with auto-updating axes limits with scatter3 after using translation. I would like them update but they do not. invariant to "hold" and XLimMode (and the such) are on auto.

I have written a code for example below.

Thanks, Alon

%create ordinates
X=-1:0.1:1;
Y=-1:0.1:1;
Z=X.^2+Y.^2;

%scatter and obtain handle
H=scatter3(X,Y,Z);

%create translation handle
Transltn=makehgtform('translate',[100,0,0]);
Transfm=hgtransform('Matrix',Transltn);

%implement translation
H.Parent=Transfm;

[Walter Roberson]

You are correct. This appears to be a bug.

Furthermore if you explicitly xlim([99 101]) then it will reset ylim to [0 1] instead of [-1 1]

[Alon Spinner]

Thank you for the quick response Walter

I am trying to find an alternitive. Currently, what I use is:

H=scatter3(X,Y,Z,C,3)

where C is a vector with range [min_value,max_value].

I noticed said bug doesn't exist in plot3, but I couldn't get an equivalent plot3 to work.

Do you have an idea?

[dpb]

"said bug doesn't exist in plot3, but I couldn't get an equivalent plot3 to work."

Isn't

hL3=plot3(X,Y,Z,'o');

same (altho note have to then use

grid on

as plot3 seems to turn the grid markers off)

[Walter Roberson]

plot3 does not permit changing marker size individually.

[dpb]

Yeah, but OP wasn't using anything but a fixed size of the markers anywhere I see??? scatter uses an area instead of a diameter measure but it's just square of the 'MarkerSize' line property.

Default 'SizeData' for scatter3 object is 36 and 'MarkerSize' is 6 for plot3 and they're indistinguishable in appearance in size.

subplot(2,1,1)
hP3=plot3(X,Y,Z,'o');
grid on
title('Plot3')
subplot(2,1,2)
hS3=scatter3(X,Y,Z);
title('Scatter3')

IF were mandatory to have variably-sized markers as well, then it would be necessary to use arrayfun() or some other mechanism and build array of line handles, granted.

But, the object was a workaround for the apparent bug of scatter3 wrt the translation issue.

[Walter Roberson]

"currently what I use" involves a scatter3 call that uses different marker size (C) but the same color (3) for each marker. If the arguments were posted reversed and it is constant point size and varying colors per marker, then plot3 cannot deal with that either.

[dpb]

I missed seeing that comment but note what I said above:

"IF were mandatory to have variably-sized markers as well, then it would be necessary to use arrayfun() or some other mechanism and build array of line handles, granted."

"... plot3 cannot deal with that"

Of course it can! (albeit with some extracurricular help) :)

cm=colormap;                  % save colormap
C=round(interp1([min(Z) max(Z)],[1 length(cm)],Z));  % C scaled to Z
hS3=scatter3(nan,nan,nan);    % create a 3D axes
delete(hS3)                   % get rid of unwanted scatter object
hold on                       % set hold for the axes to add to
hL3=arrayfun(@(x,y,z,c) ...
   plot3(x,y,z,'color',cm(c,:),'marker','o'),X,Y,Z,C);  % now simulate scatter3
title('arrayfun Plot3')

Treat a variable marker size vector the same way.

Granted it's not nearly as handy as scatter3 but if it has a bug, there is a workaround if it's needed badly enough. (Again, presuming plot3 doesn't have the same bug as seemed to be the case).

ADDENDUM

I didn't check to ensure the use of scatter3 to produce the axes didn't introduce the error; I presumed that had to do with the scatter3 object inside but perhaps not. It might be safer to use plot3 for that purpose as well instead; then will have to use grid on as it seems to turn the grids off by default.

[Alon Spinner]

I was looking to have one handle that includes all [X,Y,Z] data as I have to make decisions based on the entirety of the shape (for example: finding center of geometry and the such).

I suppose all those can still be made handling the array of line handles, but with much discomfort.

I have found it easier to modify the axes limits with coded conditions, to act as the 'auto' axes limits replacement.

Thanks for all the help though, dpb and Walter Roberson!

much appreciated.

[dpb]

Well, the data are all still in the array; it's just the simulated scatter3 plot that creates the multiple line handles; there's no reason I can see why would need those for any analysis.

If one is trying to modify a given point after an analysis on the plot, then that handle is 1:1 consonant with the location in the array so the same indexing works for it as for the individual points.

[dpb]

"I was looking to have one handle that includes all [X,Y,Z] data..."

I've been kept stewing over the above as I didn't understand what you were driving at until just now...at least I think I do now.

If you're speaking of the data being addressable as

hS3=scattter(X,Y,X,...);

and then using

hS3.[X|Y|Z]Data

instead of just X or Y or Z, then there's not too much difference between that and writing

hL3=arrayfun(...

and using the brackets to assimilate the comma-separate list from hL3.XData as

[hL3.XData].'

it's the same array. Of course, you could make a struct from the original data as well if like the nomenclature.

I'm still left wondering why you would write it using the struct form from the figure instead of just using the original variables X,Y,Z, though?

[Alon Spinner]

You are in the right. What you offer will work.

to explain further, I wanted to have the ordiante data in one figure for three reasons:

1. Plug and play - I already coded my entire program before I noticed the bug with the scatter3
2. My code lets the user to manually play with the data, using dials and buttons, to obtain certain wanted parameters. I am unable to share it, but think of a point cloud that can be streched/compressed/rotated/translated by the user. Once the user is pleased with the parameters, he can save the cloud point into a workspace variable containing the X|Y|Z of each point and other relevant data. I have found it more efficent to update the data of the graphic object instead of deleteing it, and then creating a new one for each of the users desicisions.
3. Child figures stack upon its parent (i.e Parent.Children=[last_child,...,first_child] in oppose to the standard way I use arrays [first_scatter3,...,last_scatter3] with A(end+1)=new_element