Hello there,
there is something i can't get even after some time spent tweaking and checking my setup.
For i have a world-coordinates-referenced point cloud,
a -yellow- plane (set wireframe) which is set to be on Z=1000
here the screenshots:
so... why if i shift-pick a point which is correctly shown as Z0 = -91.231567, then the same widget reports a "Coord. Z = -1035.231567" ?
here's a second screenshot, i added a second -green- plane which is set on Z=0
As the single point picking returns (or does it?) an absolute coordinate data, why shouldn't be that Z0 IS EQUAL to Coord.Z?
They are not different values, an offset is applied (note the decimals, they are the same)
This seems strange at least, but it must be either wrong or wrong is my take on it (and my two cents are bet on the latter)
I do not have any kind of global shifts, or somehow voluntary altered the coordinate system.
By the way, i used shift-picking but the other methods return the same data
Maybe a dumb question about coordinates (Z coord on point picking)
Re: Maybe a dumb question about coordinates (Z coord on point picking)
Which version are you using?
The way the red X, green Y and blue Z appear on the left side of the label is weird. And also, how and when was the 'coord Z' scalar field generated? Does it really match the coordinates in the current cloud position?
Last, even if I agree it's a different problem - not using a Global shift is risky here (as you will probably lose some accuracy, at least along the X dimension).
The way the red X, green Y and blue Z appear on the left side of the label is weird. And also, how and when was the 'coord Z' scalar field generated? Does it really match the coordinates in the current cloud position?
Last, even if I agree it's a different problem - not using a Global shift is risky here (as you will probably lose some accuracy, at least along the X dimension).
Daniel, CloudCompare admin
Re: Maybe a dumb question about coordinates (Z coord on point picking)
Using 2.14 downloaded last week
OK it is confirmed it is a dumb question:
i didn't noticed that "Coord.Z" is the name of the scalar field that indeed i created and THEN applied some transforms.
Maybe its good to have a suffix to that label. "SF Coord.Z =" to have a nice "first glance" comprehension of that value.
Refreshing it is causing values to match again.
For the global shift: yes i know i lose some accuracy, but since the values are millimeters, i can afford to have a whole 1mm error
As a little suggestion:
it would be nice (for me..) to have:
less transparency in the beam
to be able to copy/paste from tree a 2d label to have full data, not only the name.
copy/paste now results in a: "2D label: Point #6225085"
the last suggestion in "eye-candy"
to have a border and a footer banner to match the picked point's RGB color:
OK it is confirmed it is a dumb question:
i didn't noticed that "Coord.Z" is the name of the scalar field that indeed i created and THEN applied some transforms.
Maybe its good to have a suffix to that label. "SF Coord.Z =" to have a nice "first glance" comprehension of that value.
Refreshing it is causing values to match again.
For the global shift: yes i know i lose some accuracy, but since the values are millimeters, i can afford to have a whole 1mm error
As a little suggestion:
it would be nice (for me..) to have:
less transparency in the beam
to be able to copy/paste from tree a 2d label to have full data, not only the name.
copy/paste now results in a: "2D label: Point #6225085"
the last suggestion in "eye-candy"
to have a border and a footer banner to match the picked point's RGB color: