forum.cncdrive.com

let's imagine that we have any part for plasma cutting. This is XY only coordinates.
Is it possible to have a function that will return the position in the machine coordinates where the operator make click on the ToolPath viewer?
In this case we can easy calculate nearest point on the trajectory and move to this position.

I like your thinking Andrew .

That's a simple but very good idea.

Keith

Well, when it is a topview then translating the screen coordinates to 3D world coordinates is simple if the coordinates of interest is XY only.
When there is a rotation applied then things are not so simple.

When you click to a point on the screen that point can be translated to infinate amount of points in the 3D world coordinate system. These points are always on a line.
One endpoint of this line can be defined as the click point on the near plane which is in other words the screen at the lens of the camera viewing the 3D scene.
The other endpoint of the line can be defined on the far plane which is a parallel plane to the near plane, it is basicly the plane which your camera is viewing at and the points on the far plane are the most far distance your camera can view at, in other words your camera don't see behind the far plane.
The toolpath drawing is in between the far and the near plane, so the camera can see it.
I've attached a picture to make my description more clear.

So, when you click with the mouse you only have 2 points, because the screen is flat (2D), but you need a 3D point to be returned which is not easy, because the clicked 2D point can be translated to a line and not to a point.
After defining the line or ray of the click then it could be used to look for collision with objects in the 3D workspace, but there can be several objects which the line collides, not only one...

Hello Balazs!
Of course I'm talking only about 2D coordinates - only X and Y.
For plasma and laser cutting this is more than enough.
Is it possible to have nearest gcode line number and XY position for mouse click or may be coordinates of the nearest point on the cutting path ?
Or only position, in this case we will start analyse path and find nearest position on the trajectory.
It's will be very COOL, especially when operator need to restart or continue cut from any point of the trajectory.

Hi Andrew,

I can send the plugins the XY coordinate of the click in the 3D workspace coordinate system, but that will be only correct if the toolpath view is in Top view.
I think it will be better if you then making a determination in the plugin about which is the closest item in the toolpath,
because I'm afraid that if I implement this into the UCCNC directly then it will execute on all clicks and then it could cause slowdowns when very high line count toolpath is loaded.
So, it would be better if I just send the XY click coordinates and then you could do the rest in the plugin.

cncdrive wrote:Hi Andrew,
So, it would be better if I just send the XY click coordinates and then you could do the rest in the plugin.

Balazs, can you send the plugins the XY machine coordinates of the click in the toolpath view? So we can link this point to the toolpath.
If it's will be just XY position of the UCCNC main window frame , we can't to link this position to Machine coordinates.

Hello Balazs!
I am notice that you use perspective projection in OpenGL and in this case our task is not easy. Tool path can zoomed and the real tool path position can be in different positions in depth.
I don't know how UCCNC draw tool path, but very sure that there is a way to find it.
For example you can add a event in the plugin when click on the ToolPathView issue and function which has as argument the XY position of the click on the toolpath view (near plane) and which will return XY position where mouse ray cross with tool path plane.
What you think?

Hi Andrew,

No, we using Orthogonal projection, it gives a better view for this type of application.
So, the drawing I found and attached is not exactly appropriate for what we do, it was just to give you the idea of what I'm talking about.
But the problem still exist in Orthogonal projected space, because you have to get the coordinates in the modelspace which is rotated and zoomed etc.,
and so the mouse-ray projected on the near and far plane is not the same for the coordinate on the plane of interest where the drawing is.
However because the projection is orthogonal the coordinate is always correct when viewed from the TOP view, because then the near and the far plane coordinates in the modelspace are the same, because you viewing the planes from the top and the projection is orthogonal, so the 2 planes XY extents are the same.

But when the toolpath is rotated and/or zoomed then the coordinates are different on the near and the far planes and so they change by depth.

What we could do to get an approximately correct modelspace coordinate is we could test the pixel on the clicked point with glGetpixels and then we get the window Z depth and could unproject it to model space to get the Z coordinate in the model space.
However the problem is that the depth buffer is only 24 bits deep and so there can be cases when the returned coordinate will be not very precise, because of the limit in the resolution of the depth buffer.
I could change to 32 bits depth buffer, but not all graphics cards supports that and not everybody using strong gaming PCs and graphics cards, so the problem will still remain on many systems...

Hello Balazs!
I understand the course of your thoughts and I think 24 bits will be enough.
In any case, we will find the nearest exact point on the trajectory and the accuracy of the mouse click position is not so important.
Let's try to make it

Meanwhile I've made some tests. I've unprojected the clicked window coordinates to get the workspace coordinates with a Z depth based on the pixel check.
The resulted coordinates are pretty precise when in the TOP view, but are not so precise when the coordinate system is rotated, just like how I expected.
When in top view it is really precise, I mean it is exactly at the clicked point, visually there is no difference,
but when rotated then the results vary, especially when it is rotated with a high angle then I often see a few units differences, like in the +-2 units range which is a heavy error, but is understandable with the near/far plane distances we use and with the 24bits depth buffer.
So, if I'm correct it will be still OK for you, because you are only interested in the top view clicks, correct?