yang686526

oddbarc->startparam
oddbarc->startparam
what does startparam and endparam of an oddbarc actually refer to?
why would i sometimes get an error returned (result=5) when i call?:
parc->getstartparam(startparam);
result = parc->getpointatparam(startparam, respt);
returns eok if successful. if point is not on the curve, then einvalidinput is returned. other errorstatus return values are implementation-dependent.
startparam is a point? it is a single double. does it not refer to an angle and that if it lies on the arc it retruns eok and returns a valid point? please explain.
here is the code that implements this
getstartparam will return the starting angle -
odresult oddbarc::getpointatparam(double param, odgepoint3d& respt) const
{
assertreadenabled();
oddbarcimpl *pimpl = oddbarcimpl::getimpl(this);
if(param >= pimpl->m_dstartangle && param <= pimpl->m_dendangle)
{
odgevector3d vradius(pimpl->m_dradius * cos(param),
pimpl->m_dradius * sin(param), 0.);
vradius.transformby(odgematrix3d:lanetoworld(pim pl->normal()));
respt = pimpl->m_center + vradius;
return eok;
}
else
{
return einvalidinput;
}
}
so it might be an issue with double precision. you might try adding 0.0000000000001 and see what happens.
it doesn't seem to be a precison problem. here are my results for the attached example:
acdbarc
arc (-399, -148.5, 0) to (-399, -162.5, 0) center (-399, -155.5, 0)
normal: (0, 0, 1)
start angle: 1.5708
end angle: 4.71239
start param: 1.5708
end param: 4.71239
getpointatparam(1.5708): (-399, -148.5, 0) result: 0
getpointatparam(4.71239): (-399, -162.5, 0) result: 0
acdbarc
arc (-399, -160.75, 0) to (-399, -150.25, 0) center (-399, -155.5, 0)
normal: (0, 0, -1)
start angle: 4.71239
end angle: 1.5708
start param: 4.71239
end param: 1.5708
getpointatparam(4.71239): (0, 0, 0) result: 5
getpointatparam(1.5708): (0, 0, 0) result: 5
acdbarc
arc (-360.026, -154.903, 0) to (-367, -148.5, 0) center (-367, -155.5, 0)
normal: (0, 0, 1)
start angle: 0.0853085
end angle: 1.5708
start param: 0.0853085
end param: 1.5708
getpointatparam(0.0853085): (-360.026, -154.903, 0) result: 0
getpointatparam(1.5708): (-367, -148.5, 0) result: 0
acdbarc
arc (-367, -150.25, 0) to (-367, -160.75, 0) center (-367, -155.5, 0)
normal: (0, 0, -1)
start angle: 1.5708
end angle: 4.71239
start param: 1.5708
end param: 4.71239
getpointatparam(1.5708): (-367, -150.25, 0) result: 0
getpointatparam(4.71239): (-367, -160.75, 0) result: 0
acdbarc
arc (-367, -162.5, 0) to (-360, -155.5, 0) center (-367, -155.5, 0)
normal: (0, 0, 1)
start angle: 4.71239
end angle: 0
start param: 4.71239
end param: 0
getpointatparam(4.71239): (0, 0, 0) result: 5
getpointatparam(0): (0, 0, 0) result: 5
attached files (30.7 kb, 4 views)

it would appear this to be a bug. i'll pass it along.

this appears to be somewhat fixed in version 1.10. if i pass the start and end params to getpointatparam, it does now say that the angle lies on the arc. however, this example shows that there still is a problem.
acdbarc
arc (-399, -160.75, 0) to (-399, -150.25, 0) center (-399, -155.5, 0)
normal: (0, 0, -1)
start angle: 4.71239
end angle: 1.5708
start param: 4.71239
end param: 7.85398
getpointatparam(4.71239): (-399, -160.75, 0) result: 0
getpointatparam(7.85398): (-399, -150.25, 0) result: 0
getpointatparam(6.28319): (-404.25, -155.5, 0) result: 0 [b]
the angle 6.28319 is not on the arc, however the point (-404.25, -155.5, 0) does lie on the arc.
attached files (22.8 kb, 3 views)

oddbarc is always counter-clockwise aroud its normal.
angles are measured in arc's ocs (when normal is co-directional with z axis).
start angle 270 and end angle 90 means than point on x axis (with angle 0 or 360) is on the arc.
in other words if start angle is 270 and end angle is 90 it means that end angle is 90+360.
sergey slezkin
ok. if that is the case, does getstartpoint( ) and getendpoint( ) functions also return points in the arc's ocs? and if so, what function(s) can i call to transform those points to the wcs?
getstartpoint(), getendpoint(), center() and getpointatparam() return points in wcs.
sergey slezkin
what is the easiest way to get the arc direction then? in this case the direction in the wcs is clw and in the arc's ocs it's cclw?
direction is ocs is always counter-clock-wise.
in general case direction in wcs makes no sense:
if normal is (0,0,1) - direction in wcs is the same, if (0,0,-1) - oposite.
and what about normal (1,0,0)?
oddbarc direction is alway cclw around arc's normal.
sergey slezkin