yang686526

oddbpolyline::getparamatpoint() missed point
oddbpolyline::getparamatpoint() missed point
hello. all.
did find out that oddbpolyline::getparamatpoint() method is unstable and sometimes is missing points with "invalidinput" error message.

shouldn't this method be used with a tolerance parameter?
this is a schema of my code:
ppoly is a oddbpolyline object.
1. step polyline segments and find intersection:
odgelineseg2d::intersectwith(<odgelineseg2d>, <odgepoint2d>, tol);
2. convert intersection point to 3d:
odgepoint3d::set(odgepoint2d::x, odgepoint2d::y, ppoly->elevation());
3. extract parameter at 3d crossing point:
ppoly->getparamatpoint(<odgepoint3d>, double&); // error: invalidinput
if it is know issue what would be work around?
regards,
gok
life would be so much easier if we could just look at the source codefff">fff">
the conversion to 3d
code:
odgepoint3d::set(odgepoint2d::x, odgepoint2d::y, ppoly->elevation());
is incorrect if polyline's normal differs from (0,0,1)
if your polyline has normal (0,0,1) and you use latest dd version (2.2) please provide more information how to reproduce the problem. (some tolerance issues were fixed in latest release).
sergey slezkin
hello, sergey.
did double check polyline normal and it is (0,0,1). and i'm with latest ddwg 2.2.0.
did cook small app for your testing and putted it on my ftp (yours attach on web page is broken):
go to gok/ddwg folder for getparam.zip. it is a msvc6.0 project with sample drawing in debug folder.
i think tolerance should be an input parameter or served by global var for this method.
please, let me know the debugging results and your thoughts.
regards,
gok
life would be so much easier if we could just look at the source codefff">fff">

additional info might help to narrow down the problem.
was trying to "improve" point position and add closest point command:
odgepoint3d closest;
odresult res = ppoly->getclosestpointto(pp3d, closest);
res = ppoly->getparamatpoint(closest, param);
even 'closest' is exact the same as pp3d i'm loosing all my crossing points with einvalidinput.
help!!
life would be so much easier if we could just look at the source codefff">fff">
last edited by gok; 1st march 2007 at 05:32 pmfff">.
in your sample drawing coordinates are of values like 1.e+6 - 1.e+7.
double values have 16-17 valid decimal digits. so default tolerance 1.e-10 does not work for your drawing.
most ge functions accept tolerance as parameter but db (like getparamatpoint()) - not. they use default tolerance.
the default tolerance can be altered:
code:
odgetol tol(1e-9);
odgecontext::gtol = tol;
but it would be better to restore it after your intersection operation to avoid possible problems in other places.
for example:
code:
class temptolerance
{
odgetol m_savedtol;
public:
temptolerance(double tolval)
{
m_savedtol = odgecontext::gtol;
odgecontext::gtol.setequalpoint(tolval);
odgecontext::gtol.setequalvector(tolval);
}
~temptolerance()
{
odgecontext::gtol = m_savedtol;
}
};
// usage:
.....
{
temptolerance mytol(1.e-9); // set temporary tolerance
...
// do something
...
} // mytol goes out of scope. default is restored
the default will be restored in case of exception also
sergey slezkin

hello, sergey.
following your results i shifted origin for polylines and it works fine with default tolerance. do you think acadmap doing the same thing for each command or there is some global origin shift to improve accuracy?
by the way, what is the future of odgepolyline3d::setfitpointat()? it exists for 2d polyline so it shouldn't be a problem to add the same for 3d.
best regards,
gok
life would be so much easier if we could just look at the source codefff">fff">
you are absolutely right that the reason of precision loss is subtracting large values that are "close" to each other. i don't know how acad handles this situation (moving the points to an area around origin improves the precision but causes an overhead).
fit points and other spline-related functionality is not implemented in odgepolyline2d too.
sergey slezkin