vlax-curve and UCS

[irneb]

I like the vlax-curve-* function a lot. They make life soooo much simpler.

However, I've run into a problem. If I ask the user to select an entity with entsel, then I can use the picked point to get the vlax-curve-GetClosestPointTo. This works fine as long as the entity was drawn parallel to the WCS and the view is plan on the WCS. Try this with (say) a line with different Z values and you get an unexpected point.

All I can think of is to create a temporary flattened copy of the entity and then obtain the param at this point. Then convert the param back to the original. This becomes quite hectic if you also consider polylines, arcs, etc.

Does anyone know of an easier way? Am I missing something? The curve functions need a point directly on the entity before you can obtain the param ... from which you can get the rest of the stuff. A point (even) slightly off will produce an error.

[seant61]

Is it possibly a matter of transforming the UCS point returned by entsel to a WCS point required by vlax-curve-GetClosestPointTo?

[_gile]

Hi,

Assuming :

(setq ent (entsel))

You can do:

(setq param (vlax-curve-getParamAtPoint
              (car ent)
              (trans (osnap (cadr ent) "_nea") 1 0)
            )
)

But I had some issues with this expression on old style 2d polylines, so I write the following, which works fine with old style 2d polylines but may return wrong results with 3d polylines...

(setq param (vlax-curve-getParamAtPoint
              (car ent)
              (vlax-curve-getClosestPointToProjection
                (car ent)
                (trans (cadr ent) 1 0)
                (mapcar '-
                        (trans (getvar "VIEWDIR") 1 0)
                        (trans '(0 0 0) 1 0)
                )
              )
            )
)

[irneb]

Gile, thanks. I think I'd have to go the OSnap-Nearest route. I extremely seldom use the old Polylines. On second thought maybe a combination of the 2, I could always check what entity type it is before getting the point - then use ether of the algorithms depending on which would work.

The only problem I can see with this is if the DWG is a bit full, you can never be sure that osnap uses the same entity. You aperture is usually differently sized to your pickbox, so it "could" pick-up another entity instead.

BTW, haven't tried it yet, but would a ssget be more "accurate" if I then use the ssnamex. I know that if I use a (ssget "F" ...) the points returned by ssnamex is exactly on the crossing point of the fenceline. Just not sure how to enforce a single entity by picking a point with ssget, and if the point returned would give something other than entsel.

seant61, to see what I'm referring to - see the attached DWG. There's a line drawn from 0,0,0 to 200,200,200. Now enter the following on the command prompt:

(setq en (entsel))

Pick the line about 3/4 of the way up to the right-top end. Then type the following:

(setq eo (vlax-ename->vla-object (car en)))
(setq pt1 (vlax-curve-getclosestpointto eo (cadr en)))
(command "_.line" "_non" pt1 pause (cadr en) "")

When asked pick a point off the line. This should draw 2 lines starting from the ClosestPointTo to the point picked by the user. You can clearly see a large discrepancy between the 2. And the DWG doesn't even have any UCS set. It's all in WCS and Plan view. It's just that the line has different Z values.

Now a similar thing happens when you've got a polyline / arc / circle / etc on a tilted UCS.

[seant61]

I see what you mean.