yang686526

getting arc points
getting arc points
hi,
i have block references entities which contains some polylines and an arc (doors in a building).
i don't know if this is usefull, but some of the attributes in my block references are mirrored (x and / or y).
in my source code, i read block entities, collect entities inside that block and then transform these entities with the block transform.
after that, i need to get arc points.
here is the source code to get sample arc points:
code:

void arc::getpoints(pointseries* points) const
{
double startangle = dbarc->startangle();
double endangle = dbarc->endangle();
if (startangle > endangle)
startangle -= 2 * m_pi;
odgecircarc2d arc (odgepoint2d (dbarc->center().x, dbarc->center().y),
dbarc->radius(), startangle, endangle);
odgepoint2darray gepoints;
arc.getsamplepoints (0, 0, 0, gepoints, null);
const int size = gepoints.size();
for (int ipoint = 0; ipoint < size; ++ipoint)
points->push_back(new geomcvt:oint (gepoints[ipoint].x, gepoints[ipoint].y));
}
all doors are located at the right place, but the arc of the doors don't seem to have the right rotation.
do you have any idea what i didn't do correctly ?
thank you very much !
sylvain
blocks have transformations, and these transformations must apply to blocked entities.
see the following properties of the oddbblockreference for help :
position(), blocktransform() and origin()
also remember the case when blocks contain blocks, what i have implemented is a transformation stack to handle sub blocks etc..
hope this helps
jason
i guess you are ignoring reference vector of the db arc.
you may construct ge arc from db by 3 points - start, middle and end.
it is simple and requires no parameters adaptation.
vladimir
hi,
thank you for your answers.
the problem doesn't seem to be related to the block transformation, because all doors are located correctly. in that file, my blocks are not contained in other blocks. if i remove the block transformation, all doors are located at (0,0). moreover, all my other files, which contains a lot of arcs, are read correctly in my application.
in my block entities iterator, i do the following:
code:
if (tmat) // block's odgematrix3d
{
oddbentityptr transformdbentity;
dbentity->gettransformedcopy(*tmat, transformdbentity);
dbentity = transformdbentity;
}i tried to create my odgecircarc2d instance using the starting and ending points, calculating the arc bulge, and i couldn't make it working.
when i look at my file structure in the odamfcapp, arcs angles are different compared to what i read throught the sdk. i also looked at the sdk example (readex) which dumps all geometries from a file to the standard output, and i couln't see anything special.
so i am really wondering what i am doing wrong, or what i missed.
i am including my dwg file i you want to look at it.
thank you again for your help.
sylvain
attached files (195.0 kb, 1 views)

i didn't say anything about transforms.
using 2 points and a bulge is not that simple as 3 points.
code:
odgepoint3d p1,p2,p3;
arc->getstartpoint(p1);
arc->getendpoint(p3);
double start,end;
arc->getstartparam(start);
arc->getendparam (end);
arc->getpointatparam((start + end)/2, p2);
odgecircarc3d arc(p1,p2,p3);
vladimir
hi vladimir,
your solution worked !!!
i validated your solution with different files, and everything appear correctly.
i'm still wondering why i couldn't make it working using other odgecircar2d constructors (angles / bulge). there must be a bug in oddbarc (get*angle()) or in odgecircar2d (constructors)...
thank you again !
sylvain
afaik there are no bugs there.
vladimir
sylvain,
i don't know which constructor you are using, but if it is this one:-
code:
odgecircarc2d:dgecircarc2d (
const odgepoint2d& startpoint,
const odgepoint2d& endpoint,
double bulge,
bool bulgeflag = true)don't forget the bulgeflag:-
code:
if bulgeflag == true, then bulge is the maximum distance from the arc perpendicular to a chord between the start and endpoints.
if bulgeflag == false, the bulge is the tangent of 1/4 the included angle of the arc, measured counterclockwise.i know this caught me out when i first used it.
it may happen that your problems were caused by ignoring dbarc's normal. after some transformations arc in xy plane may have normal (0,0,-1) instead of default (0,0,1)
this is because dbarc is always counter clock-wise around normal.
all angles are measured around normal.
even if you know for sure that drawing is flat you can't ignore dbarc's normal while converting dbarc to gecircarc2d.
sergey slezkin