Calling all Math Wiz's - vlax-curve-getfirstderiv
Darren J. Young
use...
Would someone be so kind as to explain what the derivative is as it
relates to the (vlax-curve-getfirstderiv) and (vlax-curve-
getsecondderiv) functions?
Thanks much!
--
Darren J. Young
CAD/CAM Systems Developer
Cold Spring Granite Company
202 South Third Avenue
Cold Spring, Minnesota 56320
Email: dyo...@coldspringgranite.com
Phone: (320) 685-5045
Fax: (320) 685-5052
Jamie Duncan (remove lock to reply)
would be the rate of change of the slope at that point.
--
Jamie Duncan
Consulting - If you're not part of the solution, there's good money in
prolonging the problem.
"Darren J. Young" <See.Sign...@Email.Address> wrote in message
news:MPG.1af33a4fe...@discussion.autodesk.com...
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.661 / Virus Database: 424 - Release Date: 19/04/2004
Darren J. Young
> would be the rate of change of the slope at that point.
Unless you need to massage and molest that number a little bit I don't
see it.
I checked a point on a spline's curve right at it's tangent point to a
horizontal line and the function returns back a point way off in space
somewhere.
Wait....wait.....wait....there's it is. Take the angle from 0,0,0 (WCS)
to the point returned by the first derivative and you get the angle at
that point.
Thanks much! That was quick!
I guy that was at one of my classes at AU a couple years ago just asked
me that (we were talking about it today) and I just happened to be
working on a project today myself where I needed that as well. You
killed to birds with one stone!
Jamie Duncan
texts. I can still derive simple beam equations etc, forget pdeq's,
anything complicated overtaxes my meagre memory resources...
Glad I could help.
--
Jamie Duncan
"How wrong it is for a woman to expect the man to build the world she wants,
rather than to create it herself."
- Anais Nin (1903-1977)
"Darren J. Young" <See.Sign...@Email.Address> wrote in message
news:MPG.1af340dd6...@discussion.autodesk.com...
John Uhden
information depending on the object selected.
--
John Uhden, Cadlantic
<the e-mail address is bogus>
http://www.cadlantic.com
Sea Girt, NJ
"Darren J. Young" <See.Sign...@Email.Address> wrote in message
news:MPG.1af33a4fe...@discussion.autodesk.com...
Tony Tanzillo
> Do a Google search in the Groups category. The function will return various
> information depending on the object selected.
No, that's GetParameterAtXxxxx that's interpreted
differently for each type of curve class.
The first and second derivatives are WCS vectors
that describe the tangent and normal directions
of the curve at a given point on it.
AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005
http://www.acadxtabs.com
Doug Broad
Vlax-curve-getfirstderiv and
vlax-curve-getsecondderiv both return vectors.
They are not always perpendicular to one another.
Neither is the second derivative always normal
to the curve
To simplify the discussion, the following terms
are defined:
D1 = first derviative vector returned from
vlax-curve-getfirstderiv
|D1|= length of D1
D2 = second derivative vector returned from
vlax-curve-getfirstderiv
|D2|= length of D2
PT= the point at which the derivatives are
taken on the curve.
PARAM = second argument to the functions.
Return value of (vlax-curve-getparamatpoint <curveobj> PT)
In general:
1. D1 is always tangent to the curve at PT.
2. D1 always indicates the direction of the curve at PT.
3. D2 always indicates the general direction of concavity.
4. |D2| is proportional to the sharpness of the curve at
that point. The faster the curve changes direction the
greater |D2| is.
5. Inflection points on the curve can be found where
|D2| is 0.
Specifically for circular curves:
1.|D1|=|D2|=radius of curvature.
2.D2 from PT ends at center.
3.D1 is normal to D2
4.PT+D1+D2(shorthand for D1 and D2 placed tip to tail
from PT) ends on the curve or where the curve would
be if it continued.
Specifically for elliptical curves:
1. D2 from PT ends at the centroid of the ellipse.
2. D1 is normal to D2 at the quadrant points.
3. |D1| and |D2| are each the half axis lengths at the
quadrant points.
4. PT+D1+D2 ends on the curve or where the curve would
be if it continued.
Specifically for line segments:
1.|D1|= length of the line.
2.|D2|= 0
3.D2 = (0.0 0.0 0.0)
Specifically for splines:
1. PT+D1+D2 usually does not end on the spline.
A value of (0.0 0.0 0.0) for D2 indicates that PT
is on a straight line segment or at an inflection point.
The above is derived from solely on my observation. I have
seen no documentation explaining these conclusions.
Regards,
Doug
"Tony Tanzillo" <tony.t...@bogus.com> wrote in message news:408cbbe8_3@newsprd01...
> "John Uhden" <juh...@cadlantic.com> wrote
John Uhden
anywhere. Even if some of it is incorrect, it can be used as a jump-start for
experimentation, which is all I have bothered to do. I've used them only
once... in the last @cv_inside function, which attracted no interest.
--
John Uhden, Cadlantic
<the e-mail address is bogus>
http://www.cadlantic.com
Sea Girt, NJ
"Doug Broad" <dbroad-no-s...@nash.cc.nc.us> wrote in message
news:408d6851_2@newsprd01...
Doug Broad
know is incorrect. Here are some functions to make investigation
easier. And I don't know about lack of interest in @cv_inside.
I thought it was very nice.
And several other conclusion:
In general
6. Inflection points only occur on continuous splines, not on
piecewise functions like plines unless spline fit.
7. The length |D1| is exactly equal to the arclength|length of
the curve between PARAM and PARAM+1.
(defun c:test ()
;;No localization to allow for examination of
;;variables after test.
(command "ucs" "")
(command "osnap" "non")
(vl-load-com)
(setq obj (vlax-ename->vla-object(car(entsel))))
(while
(setq pt (osnap (getpoint "\nPick point on object: ") "nea"))
(setq param (vlax-curve-getparamatpoint obj pt))
(setq d1 (vlax-curve-getfirstderiv obj param)
d2 (vlax-curve-getsecondderiv obj param))
(command "line" pt (mapcar '+ pt d1) "")
(command "line" pt (mapcar '+ pt d2) "")
(print (strcat "|D1|=" (rtos (distance '(0 0 0) d1) 2 3)
"|D2|=" (rtos (distance '(0 0 0) d2) 2 3)
))
)
(princ))
;;LENGTH OF CURVE BETWEEN PARAM AND PARAM+1
(defun c:L1 ()
;;Assumes one has run test. Purpose: To determine the
;;length of the curve to PARAM + 1
(setq pt2 (vlax-curve-getpointatparam obj (+ param 1.0))
dist1 (vlax-curve-getdistatpoint obj pt)
dist2 (vlax-curve-getdistatpoint obj pt2)
len (- dist2 dist1)
)
)
;;POINT AT PARAM+1
(defun c:NP ()
(command "point" (vlax-curve-getpointatparam obj (+ param 1.0))))
Regards,
Doug
"John Uhden" <juh...@cadlantic.com> wrote in message news:408dc3e5$1_2@newsprd01...
> Thank you, Doug. That's probably the most exhaustive explanation posted
> anywhere. Even if some of it is incorrect, it can be used as a jump-start for
> experimentation, which is all I have bothered to do. I've used them only
> once... in the last @cv_inside function, which attracted no interest.
>
> --
> John Uhden, Cadlantic
> <the e-mail address is bogus>
> http://www.cadlantic.com
> Sea Girt, NJ
>
<snip>
Tony Tanzillo
It is only normal to first order curves, which is natural
since their curvature is constant, and they have no
inflection points.
AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005
http://www.acadxtabs.com
"Doug Broad" <dbroad-no-s...@nash.cc.nc.us> wrote in message news:408d6851_2@newsprd01...
Doug Broad
Conclusion 7 is only true for curves(arcs, circles, splines..)
Length |D1| is equal to length of a line as stated earlier.
"Doug Broad" <dbr...@earthlink.net> wrote in message news:408e4e1e$1_1@newsprd01...
Darren J. Young
useful tidbits of information everyone posts here.
I'm seriously considering going back to school for a degree in
mathematics. My lack of knowledge in this area is sometimes crippling.
I don't even want to admit how long it took for me to come up with a
formula to give the start and end angles (from zero) of an arc given 3
coordinates (Start, mid, and end) of an arc.
--
Darren J. Young
CAD/CAM Systems Developer
Cold Spring Granite Company
202 South Third Avenue
Cold Spring, Minnesota 56320
Email: dyo...@coldspringgranite.com
Phone: (320) 685-5045
Fax: (320) 685-5052
> You're welcome John. Be sure to point out anything you
David Kozina
Given the simple straight line diagram below:
(No arcs or spline curves are involved in this case, but the Obj line could
be at any angle)
+ A
,Obj |
Start +==============+ End
|
+ B
Start = (vlax-curve-GetStartPoint Obj)
End = (vlax-curve-GetEndPoint Obj)
Lngth = (vlax-curve-GetDistAtParam Obj 1)
UnitDirectionVector[Start->End] = D1
(mapcar
'(lambda (ord)
(/ ord Lngth)
)
(vlax-curve-GetFirstDeriv Obj 1)
)
Am I correct regarding the above, so far?
If so, are the Unit Vector Normals to the direction vector?:
N1 to UnitDirectionVector =
(list (cadr D1) (- (car D1)) 0)
N2 to UnitDirectionVector =
(list (- (cadr D1)) (car D1) 0)
Given a distance X, normal to the end point, can points A and B then be
calculated as:
A =
(mapcar '+
End
(mapcar
'(lambda (ord)
(* X ord)
)
N1
)
)
B =
(mapcar '+
End
(mapcar
'(lambda (ord)
(* X ord)
)
N2
)
)
Am I making this too complicated?
Or am I on the right track?
Thanks for any input regarding the above.
Best regards,
David Kozina
Doug Broad
Since the endparam for a line is the length of the line,
your calculation for lngth would be incorrect.
Instead
lngth = (distance start end)
or
lngth = (vlax-curve-getdistatparam obj (vlax-curve-getendparam obj))
or
lngth = (distance (vlax-curve-getfirstderiv obj) '(0 0 0))
Also it is possible to get a distance on the line past the endparam
of the curve.
Regards,
Doug
"David Kozina" <djko...@t-3.cc> wrote in message news:40a3eb33_2@newsprd01...
> OK, now I've got a question... probably a simple one.
>
> Given the simple straight line diagram below:
> (No arcs or spline curves are involved in this case, but the Obj line could
> be at any angle)
>
> + A
> ,Obj |
> Start +==============+ End
> |
> + B
>
> Start = (vlax-curve-GetStartPoint Obj)
> End = (vlax-curve-GetEndPoint Obj)
>
> Lngth = (vlax-curve-GetDistAtParam Obj 1)
> Am I correct regarding the above, so far?
<snip>
David Kozina
Many thanks for the information.
Now I have more questions... :)
I seem to be confused regarding the term "Parameter", used with respects to
the functions
vlax-curve-getStartParam
vlax-curve-getEndParam
vlax-curve-getDistAtParam
vlax-curve-getParamAtDist
vlax-curve-getParamAtPoint
vlax-curve-getPointAtParam
For some reason I was under the impression that the parameter was a
percentage of the total length - IOW, 0.00 would be the parameter at the
start point, and 1.00 at the end point, 0.50 at the midpoint, etc. (Which,
would've made the first two functions above irrelevant, huh?)
So... just what *is* the relationship between distances, total lengths, and
parameters? I think such an explanation (or direction to a thread
discussing this) would be very helpful to me.
Also, you provided 3 methods for determining the length of the line, and I
can think of at least one more via
(vlax-get-property Obj 'Length)
(But only for lines and polylines, as in this case, not for other types of
'curves', (splines, ellipses, etc), correct?)
Has anyone determined via any type of testing which of these multiple
methods, is the most efficient? (Assuming you already have determined what
your "Obj" is and have also obtained the Start and End points)
<Here's the intended use for this particular case: Please feel free to
kibbitz>
What I'm trying to do in this case is extract 2 points by allowing the user
to draw a line (via the LINE command, so they can have easy access to DDE,
osnaps, etc, without a lot of extra fuss)
From that one object, I can extract the 2 end points, as well as calculate
additional points, which will allow me to draw additional objects and then
delete the original (construction) line object.
(In a previous iteration of this routine, I was using the getpoint function,
and then calculating additional points mathematically (via polar, angle,
dist, etc) - but since the vlax-curve-* functions require an object, using a
disposable 'construction' object seemed to be a better way to go about it -
and allow me some practice with these newer functions before trying to
tackle bigger and more complex things.)
I would really appreciate knowing if you consider this M.O. to be
appropriate in view of the newer vlax-curve-* functionality. Again, thanks
for the assistance.
Best regards,
David Kozina
"Doug Broad" <dbr...@earthlink.net> wrote in message
news:40a3fbad_3@newsprd01...
Doug Broad
It would have been consistent if the parameters had been
implemented as you expected. It is however more complicated.
Each type of curve has its own parametric meaning. They do
make sense once you accept the differences.
The best way is to learn by experiment. As I was looking
into it, I wrote a little program to give me feedback so that
I could understand the whole issue. Then I drew an example
of each type of curve and examined the returns.
Here are a few functions that might jumpstart your investigation.
I also created some to draw the first and second derivatives
from the picked point so that I could begin to understand things.
Look for those in my answer to John Uhden.
;;pardon me for the short names. These have no error
;;handling. Pick the object first and then use gs and gp
;;Code untested. Watch out.
(vl-load-com)
;;get object
(defun c:go ()(setq obj (vlax-ename->vla-object (car (entsel)))))
;;get startparam
(defun c:gs ()(vlax-get-startparam obj))
;;get paramatpoint
(defun c:gp()(vlax-get-paramatpoint obj (osnap (getpoint "\n Pick point on object: ")
"nea"))
For arcs and circles, I think you will find that the parameter is an angle. For
lines, it is the distance from the start point. Positive is toward the end of the line.
Does that help?
"David Kozina" <djko...@t-3.cc> wrote in message news:40a4db6d$1_1@newsprd01...
David Kozina
Yes, it helps. Thanks yet again.
Still curious as to how you or others consider the manner that I'm
attempting to implement said curve functions. Good? Bad? Ugly? :)
Seems like they are fairly easy to use - but only when there is some sort of
existing object geometry to work off of - IOW, not too good for pure
geometrical/mathematical point calculations, as you can do with dist, angle,
and polar, etc.
Best regards,
David Kozina
"Doug Broad" <dbroad-no-s...@nash.cc.nc.us> wrote in message
news:40a507a6$1_1@newsprd01...
Doug Broad
Your code looks fine. I'm still a little vague on how you
will be using this. I typically have used dist, angle, polar,
and mapcar to create parallel and perpendicular geometry
(say for rectangles, duct transitions, duct double-line...)
It does seem like the vlax-curve-xxx functions could have
some good applications when the baseline curve is not
straight. Perhaps others will chime in. The age of the
thread may limit participation however.
Regards,
Doug
"David Kozina" <djko...@t-3.cc> wrote in message news:40a53dc4$1_2@newsprd01...
> Doug,
>
> Yes, it helps. Thanks yet again.
>
> Still curious as to how you or others consider the manner that I'm
> attempting to implement said curve functions. Good? Bad? Ugly? :)
>
> Seems like they are fairly easy to use - but only when there is some sort of
> existing object geometry to work off of - IOW, not too good for pure
> geometrical/mathematical point calculations, as you can do with dist, angle,
> and polar, etc.
>
> Best regards,
> David Kozina
>
>
><snip?
Mark Propst
> geometrical/mathematical point calculations,"
Unless I'm mistaken, you could say that even stronger...
"they ain't no good at all" for pure calculations
they're absolutely only useful if you have an object, since they require an
object for input argument.
If you just have a trig problem you just solve it with trig funcs.
But you knew that.
:-)
"David Kozina" <djko...@t-3.cc> wrote in message
news:40a53dc4$1_2@newsprd01...
David Kozina
"Vlax-curve functions - they're *so* good you'll wish you had an object to
use them on..."
"Mark Propst" <nomor...@me.com> wrote in message
news:40a562e8$1_1@newsprd01...
David Kozina
> Your code looks fine. I'm still a little vague on how you will be using
this.
Just calculating a few points to draw a steel HSA using a couple of mlines
placed perpendicular to each other :) And it worked just fine, too, I might
add.
Next up will be a more complicated Bolt routine - mostly due to the number
of options I need to incorporate, as well as trying to work out the best
'logic flow' among them.
However, the actual creation/drawing of the bolts, mlines, block inserts,
ought to be cake now...
I typically have used dist, angle, polar,
> and mapcar to create parallel and perpendicular geometry
> (say for rectangles, duct transitions, duct double-line...)
mlines, man, mlines... ;)
(OK, maybe the duct transitions with mlines would be a little tricky - but,
show me a picture of what you're talking about...)
> It does seem like the vlax-curve-xxx functions could have
> some good applications when the baseline curve is not
> straight. Perhaps others will chime in. The age of the
> thread may limit participation however.
I wish Vladimir would stop by and hold some more analytical geometry
classes...
Best regards,
David Kozina
John Uhden
represents...
(defun c:2nd ( / @2D Object Start End Param P2 P2 Ang)
(redraw)
(defun @2D (p)(list (car p)(cadr p)))
(and
(setq Object (car (entsel)))
(setq Object (vlax-ename->vla-object Object))
(not (vl-catch-all-error-p (setq Start (vl-catch-all-apply
'vlax-curve-GetStartParam (list Object)))))
(setq End (vlax-curve-GetEndParam Object))
(setq Param Start)
(while (< Param End)
(setq P1 (vlax-curve-getpointatparam Object Param))
(setq Ang (apply 'atan (reverse (@2d (vlax-curve-getSecondDeriv Object
Param)))))
(print Ang)
(setq P2 (polar P1 Ang (* 0.1 (getvar "viewsize"))))
(setq Param (+ Param 0.5))
(grdraw P1 P2 1)
1
)
)
)
You could change it to observe 1stDerivs as well.
--
John Uhden, Cadlantic
<the e-mail address is bogus>
http://www.cadlantic.com
Sea Girt, NJ
"David Kozina" <djko...@t-3.cc> wrote in message news:40a5a611_2@newsprd01...
David Kozina
Thanks, John.
Putting on my 2nd derivative goggles now...
Best regards,
David Kozina
"John Uhden" <juh...@cadlantic.com> wrote in message
news:40a81764$1_1@newsprd01...
> Belatedly, here's a little function to help you "see" what the SecondDeriv
> represents...
<snip>
David Kozina
with respects to parameters and LWPolylines... (You know, it would be nice
if the help files were a little more robust/obvious regarding this).
*Please* provide corrections if I've got anything mixed up here...
**In the case of LW/Polylines**
Parameter 0.0 is at the First Vertex
Parameter 0.5 is midway along segment between First & Second Vertices
Parameter 1.0 is at the Second Vertex
...
Parameter N.0 is at Vertex (N+1)
vlax-curve-getStartParam = 0.0
vlax-curve-getEndParam = (total number of vertices - 1.0)
Since Parameter values here need not correspond in any way to distances,
this explains why additional curve functions are necessary to access that
information:
...DistAtParam 0.0 = 0.0
...DistAtParam 0.5 = 1/2 Length of First segment
...DistAtParam 1.0 = Length of First segment
...DistAtParam N.0 = Total Length of first N segments
If, for example
...ParamAtDist 2.0 = 4.35, you know that the point 35% of the way along the
Fifth Segment is 2.0 units away from the Start Point (along the curve) - and
...PointAtParam 4.35 will returns that location - and said point fed back to
...ParamAtPoint will return 4.35
If the above is sound - I've got two more questions, perhaps related to each
other:
~
/
|<-- Dist X -->| ,Obj /
+ +================+
A_pt Start_pt 2nd Vertex
(Parameter 0.0) (Parameter 1.0)
Is there any way with these function to extrapolate points, such as A_pt?
Or must I now resort to the older standbys: polar, ang, and dist?
Should I want to use vector calculations to accomplish the above, what is
the best way to find the *unit* direction and *unit* normal vectors?
(Start_pt to 2nd Vertex could be at any angle)
It appears that
(vlax-curve-getFirstDeriv Obj 0.0) returns a vector with length equal to
length of first segment.
How could this be converted to a unit vector? Like so?:
(setq 1stDeriv_vec
(vlax-curve-getFirstDeriv Obj 0.0)
)
(setq Norm
(distance '(0 0) 1stDeriv_vec)
)
(setq Unit_Vec
(mapcar
'(lambda (ord)
(/ ord Norm)
)
1stDeriv_vec
)
)
This seems to work in my limited testing - but I'd appreciate some
kibbitzing before I do a Wiley Coyote and step out over the precipice...
Any comments would be most appreciated.
Best regards,
David Kozina
Tony Tanzillo
of a point is the vertex index + the distance from
the start of the vertex expressed as a percentage of
the overall length of the vertex?
There's little use of the parameter in the problem you
describe, because solving that only requires you to
know the direction of a straight segment, which you can
derive from nothing but the adjacent vertices.
For more general computations of coordinates that lie
on a line (e.g., a straight lwpolyline segment), you
can use the parametric equation of the line in WCS.
Using the parametric equation, you can solve for any
number of points that lie on the extended vertex, using
pythagorian theorm.
AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005
http://www.acadxtabs.com
"David Kozina" <djko...@t-3.cc> wrote in message news:40aa6476_1@newsprd01...
Owen Wengerd
> OK, perhaps all of you already know this, but here are my findings so far
> with respects to parameters and LWPolylines...
I've preached about this before, but it bears repeating: parameters are
opaque real numbers by design, and you should not infer anything about their
relationship to points on an entity. The relationship of parameters to
points is a function of the PointAtParam functions. Trying to establish
relationships empirically is perilous at best. The relationship may change
at any time at the discretion of the implementor, and in any case, it's
impossible to be certain that any empirical relationships hold true in all
cases.
To reiterate: the parameters are opaque and their meaning and relationship
to points on the entity are defined completely by the DistAtParam()
function. By the same token, the first and second derivatives are simply
that, and I think it's dangerous to try to look for and potentially rely on
any "extraneous" relationships those have to the entity. Interesting
perhaps, but dangerous nonetheless. :)
--
Owen Wengerd
President, ManuSoft ==> http://www.manusoft.com
VP Americas, CADLock, Inc. ==> http://www.cadlock.com
David Kozina
<throwing pencil over shoulder>
NOW you tell me... :)
So, IOW, <to be safe>, I ought to round-file the curve functions for this
project, and just extract the vertex info via the vl property functions, and
then extrapolate additional points from those - correct? (Those curve
functions are rather interesting, though - and I'm not a bit sorry I got to
play around with them some.)
Of course, this raises more questions...
Is it preferred to calculate/extrapolate/interpolate points (assuming
straight segments) with vector calculations or with polar/angle
calculations? Seems like I've read that using polar/angle calculations
quickly leads to rounding/spatial errors, whereas vector calculations tend
to remain more accurate.
Also, with regards to the 'opaque' parameters in the curve functions, I
guess I am at a loss to understand just how (or for what purpose) the
functions should properly be used... Would you say that the "most critical"
function is ParamAtPoint - since that is the only way you can be sure that
you have the correct parameter to feed the other functions?
Thanks,
David Kozina
"Owen Wengerd" <ow...@manusoft.com> wrote in message
news:40aa88a9_2@newsprd01...
John Uhden
Are you saying that the "evident" relationship between parameters and vertices
of polylines is not necessarily consistent now? Or are you saying that such
"evident" relationship is likely to change? Or maybe both? Have you been
cleaning your crystal ball? I still have a lot of old lisp code that figures
out geometry by basic trigonometric procedures applied to DXF values. Are you
suggesting to stick with same? Then again, there have been rumors that AutoLisp
functions such as (entget) may be retired. One might deduce that by design,
developers will have to resort to ARX if either ActiveX methods will become
inconsistent or certain AutoLisp functions are retired. Certainly VBA, to my
limited knowledge, has no ability to derive the all the actual vertices of a
complex polyline.
Please expound.
--
John Uhden, Cadlantic
<the e-mail address is bogus>
http://www.cadlantic.com
Sea Girt, NJ
"Owen Wengerd" <ow...@manusoft.com> wrote in message
news:40aa88a9_2@newsprd01...
Owen Wengerd
> this project, and just extract the vertex info via the vl property
> functions, and then extrapolate additional points from those - correct?
In all honesty, I've forgotten what the original goal was. Assuming the
goal is to find midpoints of vertex segments, then essentially yes, scrap
the reliance on parameter relationships. That doesn't mean the parameter
functions are useless or should be ignored. For example you could get the
parameter of the midpoint of any segement, curved or straight(*1), by
finding the parameter of the segment endpoint vertices, querying the
distance to each endpoint with DistAtParam, then averaging the two
distances, then calculating the parameter of the midpoint with ParamAtDist,
then converting that parameter to coordinates with PointAtParam.
* The beauty of using parameters here instead of your own geometry functions
is that your code won't need to care what kind of shape the segment is. The
segment could be a Euclidean spiral for all you care. And *that* is the
beauty of parameters: they work for any curve of any shape, and you can
write code that is "curve-independent" if you utilize parameters.
Does that make sense? :)
Owen Wengerd
> vertices of polylines is not necessarily consistent now? Or are you saying
> that such "evident" relationship is likely to change? Or maybe both?
> Have you been cleaning your crystal ball?
I'm saying both. I'm fairly confident that the behavior of the built-in
lightweight polyline object won't change any time soon, but...
1) Third party developers are already able to make their own
AcDbPolyline-derived objects that don't necessarily use the same
relationships that Autodesk chose, and
2) I wouldn't be a bit surprised to see new possibilities beyond line and
arc for polyline segments sometime in the future (i.e. complex curves like
the Euclidean spiral example I used in my reply to David, although that
specific example is admittedly far-fetched).
> I still have a lot of old lisp code that figures out geometry by basic
> trigonometric procedures applied to DXF values. Are you
> suggesting to stick with same?
No, not at all. I'm not suggesting that parameters should be ignored; see
my other reply to David.
> Certainly VBA, to my limited knowledge, has no ability to derive the
> all the actual vertices of a complex polyline.
Really? If this is true, then "proper technique" is out the window and
hacking is the only option. :)
Luis Esquivel
> suggesting to stick with same? Then again, there have been rumors that
AutoLisp
> functions such as (entget) may be retired.
Hi John,
From?
David Kozina
(see below)
"Owen Wengerd" <ow...@manusoft.com> wrote in message
news:40ab6627$1_2@newsprd01...
> > So, IOW, <to be safe>, I ought to round-file the curve functions for
> > this project, and just extract the vertex info via the vl property
> > functions, and then extrapolate additional points from those - correct?
>
> In all honesty, I've forgotten what the original goal was. Assuming the
> goal is to find midpoints of vertex segments, then essentially yes, scrap
> the reliance on parameter relationships. That doesn't mean the parameter
> functions are useless or should be ignored. For example you could get the
> parameter of the midpoint of any segement, curved or straight(*1), by
> finding the parameter of the segment endpoint vertices,
This seems to be a CATCH-22 (to me), since I'm not understanding how you
would do this without making *some* sort of assumption regarding the
relationships of parameters to vertices (which you say is a no-no).
Say, for example, you want to find the midpoint of segment #1 of some
Object, and **you don't know** if you're dealing with a line or lwpolyline
or arc or some other oddity. (I say this because you say below that it
shouldn't matter what type of 'curve' it is) How would I take this first
step and determine the parameters of the segment endpoint vertices in this
case? Sorry for being so dense about this.
> querying the
> distance to each endpoint with DistAtParam, then averaging the two
> distances, then calculating the parameter of the midpoint with
ParamAtDist,
> then converting that parameter to coordinates with PointAtParam.
OK, I follow the rest of what you're saying, and it makes good sense - just
not the first part above. I really appreciate you're taking time to try and
explain this in an understandable way.
> * The beauty of using parameters here instead of your own geometry
functions
> is that your code won't need to care what kind of shape the segment is.
The
> segment could be a Euclidean spiral for all you care. And *that* is the
> beauty of parameters: they work for any curve of any shape, and you can
> write code that is "curve-independent" if you utilize parameters.
>
> Does that make sense? :)
Well... almost. Thanks, Owen.
Best regards,
David Kozina
Doug Broad
Polylines and 3dpolylines have a property called coordinates.
The coordinates are the locations of the verticies of the polylines.
There is no analog, however for the vlax-curve functions,
AFAIK in VBA.
Regards,
Doug
"John Uhden" <juh...@cadlantic.com> wrote in message news:40aac69d_2@newsprd01...
> Owen:
Luis Esquivel
as far as i have done lately i'm using all the vlax-curve-xxx or active-x
stuff to get/calculate/whatever... every/thing/position of part/point of a
curve objectn and no problema.
...
David Kozina
extension.
(Which is one of the reasons I'd like to understand their use better here
and now, should I eventually move on to VBA).
Best regards,
David Kozina
"Doug Broad" <dbr...@earthlink.net> wrote in message
news:40ab8ba5_1@newsprd01...
Owen Wengerd
> Say, for example, you want to find the midpoint of segment #1 of
> some Object, and **you don't know** if you're dealing with a line
> or lwpolyline or arc or some other oddity.
First of all, if you introduce the concept of segments then the object
must be a form of polyline, otherwise there are no segments to deal with.
What I meant with my earlier comment is that parameters allow you to deal
with *polyline* segments of any type, not just arcs and lines. (Yes, they
do allow you to deal with any sort of curve object in a generic way, but
only polylines have segments, and therefore only polyline objects are of
interest for an example of using parameters with segments.)
What I meant by my earlier comment about any kind of curve is that you can
(and should IMO) write your code to deal with polyline segments *of any
type*, not limited to arcs and lines. Imagine a polyline with a parabolic
segment, or maybe one with a sinusoidal segment. These are possible to make
today by implementing a custom polyline-derived object, and it's conceivable
that Autodesk might add such possibilities to the core polyline objects in a
future version of AutoCAD.
Now then, to find the midpoint of the first segment of a polyline, your
code barely needs to directly work with parameters at all (watch wrap):
<PRE>
(defun c:getmid (/ lwpline)
(if
(and
(setq lwpline (car (entsel "\nSelect a polyline entity")))
(= (cdr (assoc 0 (entget lwpline))) "LWPOLYLINE")
(setq lwpline (vlax-ename->vla-object lwpline))
)
(progn (princ "\n") (princ (getmid lwpline)))
)
(princ)
)
(defun getmid (lwpline / vertex0 vertex1 v1dist v2dist midptdist midptparam)
(setq vertex0 (append (vlax-safearray->list (vlax-variant-value
(vla-get-coordinate lwpline 0))) '(0))
vertex1 (append (vlax-safearray->list (vlax-variant-value
(vla-get-coordinate lwpline 1))) '(0)))
(setq v1dist (vlax-curve-getdistatpoint lwpline vertex0)
v2dist (vlax-curve-getdistatpoint lwpline vertex1)
midptdist (/ (+ v1dist v2dist) 2.0)
midptparam (vlax-curve-getparamatdist lwpline midptdist))
(vlax-curve-getpointatparam lwpline midptparam)
)
</PRE>
David Kozina
I think I get it now. Thanks for the more detailed explanation.
So, then, you *do* need to know/determine what kind of *object* you're
working with, then go from there. That clears up the CATCH-22 I was
tripping over.
But now, if I may, another question relating to polylines... (forgive me) :)
Is there any good/foolproof way to determine, with, say, input from a user
pick, what *segment* of a polyline one is dealing with? (Since I should not
rely on ParamAtPoint to help determine this). (I guess one needs to assume
the user won't be picking some self-intersecting point, should one exist -
<but, then again, what would happen in that case?>)
Note: I don't have to deal with this situation currently, but I'm curious
as to how this could be determined unambiguously.
Best regards,
David Kozina
Luis Esquivel
Here is a test to know the midpoint of a selected segment or point of a
curve object [no error checking]
(defun C:TST (/ dat lwpline px paramx vprev vnext pt)
(vl-load-com)
(if (and (setq dat (entsel "\nSelect segment on polyline: "))
(= (cdr (assoc 0 (entget (car dat)))) "LWPOLYLINE"))
(progn
(setq lwpline (vlax-ename->vla-object (car dat)))
(setq px (cadr dat))
(setq paramx
(vlax-curve-getparamatpoint lwpline (osnap px "_nea")))
(setq vprev (fix paramx))
(setq vnext (1+ vprev))
(setq pt (vlax-curve-getpointatparam lwpline (+ vprev 0.5)))))
(if pt
(vl-cmdf "_.line" pt pause ""))
)
Owen Wengerd
> Is there any good/foolproof way to determine, with, say, input from a
> user pick, what *segment* of a polyline one is dealing with?
Yes, there are several ways. You can use (vlax-curve-getClosestPointTo)
to find the closest point on the polyline, then covert that point to a
distance with (vlax-curve-getDistAtPoint), then step through the vertices
comparing distances at each vertex until you reach a vertex whose distance
is greater than the selected point. That vertex will then be the end vertex
of the segment containing the picked point.
You can also do it with (ssget ":N") and (ssnamex), but I don't have a
ready example of the code. :)
Owen Wengerd
> Here is a test to know the midpoint of a selected segment or point
> of a curve object [no error checking]
Your code relies on the empirically determined relationship of a point's
parameter to the segment containing the point, which is exactly what I've
been preaching about *not* doing. :)
David Kozina
"Luis Esquivel" <nos...@address.withheld> wrote in message
news:40abad2a_1@newsprd01...
> David,
>
> Here is a test to know the midpoint of a selected segment or point of a
> curve object [no error checking]
>
> (defun C:TST (/ dat lwpline px paramx vprev vnext pt)
> (vl-load-com)
>
> (if (and (setq dat (entsel "\nSelect segment on polyline: "))
> (= (cdr (assoc 0 (entget (car dat)))) "LWPOLYLINE"))
> (progn
>
> (setq lwpline (vlax-ename->vla-object (car dat)))
>
> (setq px (cadr dat))
>
> (setq paramx
> (vlax-curve-getparamatpoint lwpline (osnap px "_nea")))
>
> (setq vprev (fix paramx))
> (setq vnext (1+ vprev))
> (setq pt (vlax-curve-getpointatparam lwpline (+ vprev 0.5)))))
If I understood Owen correctly, the above 3 setq lines [which, btw, is the
approach I would've taken, too] are exactly what he said we **shouldn't**
do/assume with regards to
parameter<->vertex relationships. (Hence my last question).
Best regards,
David Kozina
Tony Tanzillo
call interpreting an lwpolyline's parameter as a means of
determining which vertex a given point is on, perilous.
That goes double in a non-object-oriented language where
there are no classes or overridden virtual methods, and
where objects are typically not dealt with in a class-wise
manner.
For example, LISP programmers generally don't manipulate
buches of curves of various base/derived classes with
indifference, as would be the case when calling virtual
methods of AcDbCurve-based objects in C++, by code that
knows nothing about the specific class of the objects it
is working with.
In fact, from LISP you can't even determine if a given
object is a derivative of AcDbCurve, without going to
such a rediculous extreme as invokng a vlax-curve-* method
on it, and trapping the error that occurs (and even that
does not necessarily indicate anything). There is no
AcDbCurve subclass data to look at in the (entget) list,
so we are not dealing with curve objects in the way that
a C++ programmer might.
When I'm working with native AcDbCurve based objects in
LISP, it is usually implied that our code assumes it is
dealing with an object of a specific type/class, not
some object that happens to be derived from that class.
For that reason, I think that while your comments are
valid in terms of C++/OOP concepts, I also think they
don't translate very well to practicle LISP programming.
If a LISP programmer encounters some custom AcDbCurve-
based object (assuming they can determine that), then of
course, it would be foolish at best, to interpret its
parameter in any way.
So while I do agree in theory, in practicle terms,
and WRT native objects like LWPOLYLINEs, I don't agree
entirely. As far as a change to the meaning of the
parameter, that may be likely with custom objects, but
seriously doubt it will ever happen to an LWPOLYLINE.
Thanks, but I'll keep using vlax-curve-getParamAtPoint
to determine what vertex a given point is on, especially
considering the alternatives. I think the line between
theoretical and practicle needs to be taken into account
here.
AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005
http://www.acadxtabs.com
"Owen Wengerd" <ow...@manusoft.com> wrote in message news:40aa88a9_2@newsprd01...
David Kozina
OK, NOW it makes sense. Thanks very much for explaining this.
Rather more complicated (than a 'simple assumption'), but I see how you can
do it.
Best regards,
David Kozina
"Owen Wengerd" <ow...@manusoft.com> wrote in message
news:40abb6a1$2_2@newsprd01...
Doug Broad
Can you give me a concrete example of where,
given that you know the object is a lwpolyline
that the point selected in this case:
(initget 1)
(vlax-curve-getparamatpoint object
(trans (osnap (getpoint "\nSelect point on object: ") "nea") 1 0)
)
and which returns 1.67823 is not on the second segment?
Certainly the method you show is foolproof. I'm just looking
for an example where the above would not work. Sometimes
we can make things more complicated than necessary.
Thanks.
Regards,
Doug
"Owen Wengerd" <ow...@manusoft.com> wrote in message news:40abb6a1$2_2@newsprd01...
Owen Wengerd
> there are no classes or overridden virtual methods, and
> where objects are typically not dealt with in a class-wise
> manner.
I think you're missing the boat. It's true that non-OO languages are less
interested in dealing generically with classes of objects and their
derivatives, but that is not the main issue here. As a programmer of custom
objects, I want to be able to freely take advantage of the flexibility that
Autodesk's paramaterization API provides without worrying about other
programmers who have made assumptions about how I will relate my parameters
to points on the curve. I would assume that Autodesk wants the same
flexibility, otherwise they wouldn't have exposed a parameterized curve
model in the first place.
As the sample I attached to another message demonstrates, this problem
transcends the issues with lisp/VBA and derived classes. I think
limitations are bad, and relying on empirically determined parameter
relationships limits both the code that makes the assumptions (by making it
susceptible to failure) *and* developers who wish to add new capabilities to
e.g. polyline objects (because they have to worry about third party code
failing).
In any case, programmers can each decide whether they want to trade
stability for "practicality". My goal here is to ensure that they
understand the potential ramifications of the decision before they make it.
Owen Wengerd
> I'm just looking for an example where the above would not work.
I should add that although the sample I posted is contrived and simple,
I've actually designed and developed complex polyline objects in the past
that don't follow the "traditional" parameterization rules. I point that
out to counter the argument that one would never encounter the demonstrated
situation in the "real" world. :)
Tony Tanzillo
> I think you're missing the boat. It's true that non-OO languages are less
> interested in dealing generically with classes of objects and their
> derivatives, but that is not the main issue here.
I disagree. That is the issue.
Also, I think you're missing the boat on one very simple
fact concerning OOP and LISP:
LISP applications have no concept or understanding of
polymorphism or inheritence. Not only is a LISP
application unable to determine an entity's ancestry,
the fact is that a LISP application has no legitmate
business even attempting to manipulate a custom entity
as if it were a concrete instance of one of its base
classes, in the absense of an explicit contract between
the implementor and the client.
And even if I were to agree to the use of polymorphism
in LISP, what is to suggest that an implementor of a
custom object cannot make the parameter contractual?
I see no legitimate reason why one cannot make emperical
assumptions about the parameter of native entities derived
from AcDbCurve. My opinion here is grounded in practicle
reality.
Owen Wengerd
> LISP applications have no concept or understanding of
> polymorphism or inheritence.
Did you look at my sample? There is no polymorphism or inheritance
involved (at least not as far as Lisp is concerned). :)
John Uhden
I get it. You *have* been polishing your crystal ball.
Dunno if this is right strand of the thread in which to respond, but the
examples I've read are dealing with LWPolylines, and you are cautioning about
curve types that as yet may not have been publicized. Not sure about others,
but a lot of my work is in between.
If we follow your suggestion not to derive empirical relationships about
parameters, then one might be stimied dealing with complex polylines, eg. an
AcDb3dPolyline that has been spline-fitted (Type 2)...
(vlax-get Object 'Coordinates) will return only the control points (say it's 6).
(vlax-curve-getendparam Object) will return the highest parameter (say 24.0)
But (vlax-get-property Object 'Coordinate 13.0) returns "; error: Automation
Error. Invalid index" because it's higher than number of control points.
So one has to rely on the evidence that each whole parameter represents a real
vertex (such as one would find via an endpoint snap), if one wants to find say
the segment selected via (entsel). Now in the old days (as yet still present)
one could use (nentselp) and retrieve the vertex entity and its information via
(entget) and (entnext) etc., and even modify any vertex using (entmod). Not so
with ActiveX, and maybe that's part of what you are preaching... that 4th party
hackers shouldn't be modifying extra vertices. Yet we might want to alter the
elevation (Z) in our own way while maintaining the stock 2D geometry.
Another example is changing the bulge of a 2D curve-fitted polyline segment.
Once again, we can't rely on the 'Coordinate property to find an extra vertex,
but must rely on the "evident" parameters. Again, maybe we're not supposed to
change a 2D polyline's bulge, even though we have been able to by
(entget)-(entmod) means and/or trusting the "evident" ActiveX parameters.
Now if they fixed the 'Coordinate property indexing to include the full range of
parameters returned by GetEndParam, then this argument is moot. So maybe I'm
ranting over ActiveX limitations that one doesn't experience with ARX.
Confusedly yours, John
--
John Uhden, Cadlantic
<the e-mail address is bogus>
http://www.cadlantic.com
Sea Girt, NJ
"Owen Wengerd" <ow...@manusoft.com> wrote in message
news:40ab6872$1_3@newsprd01...
Doug Broad
Thanks. An interesting demonstration which proves your
point.
Now I'm even more curious. What advantage would a third
party have in changing the parameters of a polyline in that manner.
What does or could the polyline do better? It doesn't appear
to affect anything observably.
Apparently the parametrization changes are eliminated if
pedit is used to fit curve and then decurve the object.
Thanks again.
Regards,
Doug
"Owen Wengerd" <ow...@manusoft.com> wrote in message news:40abfdf1$1_3@newsprd01...
Owen Wengerd
> If we follow your suggestion not to derive empirical relationships about
> parameters, then one might be stimied dealing with complex polylines,
> eg. an AcDb3dPolyline that has been spline-fitted (Type 2)...
Given the limitations of the ActiveX interface that you described (and it
is just the ActiveX interface -- no such limitations exist in ObjectARX) I
would use the (entget)/(entmod) approach where necessary.
I realized from reading your reply that my previous reply made it sound
like I was dissing (entget)/(entmod). I didn't mean to imply that those
should no longer be used. I meant that just because parameters are opaque
doesn't mean they aren't useful or should be avoided. :)
Owen Wengerd
> What advantage would a third party have in changing the
> parameters of a polyline in that manner. What does or
> could the polyline do better? It doesn't appear to affect
> anything observably.
That's exactly right: it *shouldn't* affect anything observably. The
parameters should only be meaningful to the code behind the object, and they
should only be incidental when used by client code. The relationship of the
parameters to the graphic representation of the object should in theory be
selected by the implementor so as to make the implementation efficient
internally, either mathematically or programmatically, whichever is most
important to the design goal.
For example, imagine an application where polylines are used to represent
the path that the tip of the cutting tool on a multi-axis milling machine
will cut along to machine a part. In that application, it might be more
efficient for the parameters to be related to a point on the milling machine
head somewhere other than the tip of the cutting tool. Furthermore, while
the visual representation of the path would be delineated by vertices, the
real path might not be. Imagine that the application needs to generate a
tool path from the polylines, but the tool path is defined by the location
of the base of the cutting tool rather than the tip (which is related to the
base in calculatable but unorthodox ways that depend on the exact
orientation of the cutting tool as it travels along the path). The math for
generating tool paths would be much simpler internally if the polyline's
parameters were related to the base of the tool rather than the tip that is
represented by the displayed polyline.
My point is that we should leave that decision to the implementor, and not
tie her down with needless assumptions. We can't possibly imagine all the
cases where using a different parameterization relationship could be
beneficial to the specific application, but surely we can recognize that if
the potential exists then someone somewhere will utilize it. :)
Tony Tanzillo
> Tony:
>
> Did you look at my sample? There is no polymorphism or inheritance
> involved (at least not as far as Lisp is concerned). :)
Did you look at my previous reply? Specifically:
> If a LISP programmer encounters some custom AcDbCurve-
> based object (assuming they can determine that), then of
> course, it would be foolish at best, to interpret its
> parameter in any way.
>
We're comparing apples and oranges. I'm referring to the
emperical meaning of built-in entities, not custom entities.
I maintain that for all practicle purposes, there is
absolutely nothing wrong with making assumptions about
the parameter of an AcDbPolyline. We will all be dead
and buried or barbequed before its meaning changes. :-)
Doug Broad
That makes sense.
Of course, now I'm curious about what the parameters
would actually look like for such an application. Since
the parameter can only be a single number(right?) and since,
as far as I can imagine, it is related to the distance along
the curve, would the tool be ahead or behind the tool path?
What are your capabilities for adjusting the parameters?
Is it only a scaling factor? Can the parameterization be offset
so that a curve starts at parameter 1 rather than 0? Can you
impose a mathematical function? Can parameters be placed
on the curve at specific distances along the path? Can they
have different spacings for each type of segment(arc or
straight)? Can they represent points off the curve? If so how
with only one number?....
If you don't have time to get into it, perhaps give a link to
where parameterization rules and applications are discussed.
Thanks again!
Regards,
Doug
"Owen Wengerd" <ow...@manusoft.com> wrote in message news:40ac37aa$1_2@newsprd01...
Owen Wengerd
> Since the parameter can only be a single number(right?) and
> since, as far as I can imagine, it is related to the distance
> along the curve, would the tool be ahead or behind the tool
> path?
The concept of parameterized curves has been explained in the past better
than I can explain it. I did a quick google search and found this:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=VA.00001029.0f78c621%40fleming-group.com&rnum=3&prev=/groups%3Fq%3Dparameterized%2Bcurve%2BAutocad%26ie%3DUTF-8%26hl%3Den.
If we're lucky, one of the math wizzes (Jon Fleming, where are you?) will
jump in and explain.
> What are your capabilities for adjusting the parameters?
> Is it only a scaling factor? Can the parameterization be offset
> so that a curve starts at parameter 1 rather than 0? Can you
> impose a mathematical function? Can parameters be placed
> on the curve at specific distances along the path? Can they
> have different spacings for each type of segment(arc or
> straight)? Can they represent points off the curve? If so how
> with only one number?....
Parameters *are* mathematical functions, and they can be *anything* so
long they maintain a one-to-one relationship between parameters and points
on the curve. In the example I posted before they do indeed represent
points off the curve. Look at the spline or ellipse objects in AutoCAD if
you want to see parameterization functions that are not linear like those of
lines and arcs. :)
Owen Wengerd
> I maintain that for all practicle purposes, there is
> absolutely nothing wrong with making assumptions about
> the parameter of an AcDbPolyline. We will all be dead
> and buried or barbequed before its meaning changes. :-)
I agree, it's a long shot that Autodesk will ever change it. :)
Luis Esquivel
Owen Wengerd... Escribio:
Hi Owen,
I tried your ARX and run the test nothing happens, what is the qpoly suposed
to do? the lwpoly that i drew did not change et-al??????
:) ? :(
> Load the attached .arx file into AutoCAD 2004, then draw a lightweight
> polyline and use the QPOLY command to convert the "normal" polyline into a
> "quirky" polyline. Now try using the parameter to determine the segment.
> In this sample the parameterization is just "stretched" by a factor of 3,
> but it could be much more complex. :)
Luis Esquivel
Now how can one can draw a polyline like that in a normal vanilla autocad?
> Check out the endparam value in the attached screenshot, and compare to
the
> number of vertices.
David Kozina
I think one of Owen's points is that maybe *you* *won't* ever do/make
something like that.
But one day you might get a drawing from a client that has objects like that
in it.
For whatever reason, you start copying the object here and there (CAD
entities propagate faster than rabbits, you know). Then, all of a sudden,
your routines that used to work (based on empirical/evident relationships
suddenly start having problems - and you will be hardpressed to know/figure
out why.
Think about the difficulties people have had with the educational plot
stamp.
As I see it, Owen just wants us to make an informed decision with respects
to these things, and be aware of the possible consequences, slim though they
may be at present.
Best regards,
David Kozina
"Luis Esquivel" <nos...@address.withheld> wrote in message
news:40acc520_3@newsprd01...
Luis Esquivel
Thank you Owen [when I grow up, I will learn all that you know :)]
Thank you David - now is clear
Owen Wengerd
> respects to these things, and be aware of the possible
> consequences, slim though they may be at present.
Well said David, thanks. :)
John Uhden
--
John Uhden, Cadlantic
<the e-mail address is bogus>
http://www.cadlantic.com
Sea Girt, NJ
"Owen Wengerd" <ow...@manusoft.com> wrote in message
news:40ac3132$1_3@newsprd01...