yang686526

orthoproject query
orthoproject query
i am using dd 1.13.01 vectorization framework.
once i get an ellipse whose coordinates are in viewing coordinate system(i.e. in exgssimpledevice::elliparcproc) then i use the following code to project it on xy plane of the screen coordinates.
odgeplane plane = odgeplane::kxyplane;
odgeentity3d* entity = elliparc.orthoproject(plane);
my assumption is that this the entity will now be an ellipse whose coordinates are described in the screen coordinates.
but when i query the major and minor radius of the entity, it turns out to be totally wrong.
i assume that the xyplane that has been passed as a parameter to orthoproject call means the xy plane in screen coordinates. is this correct?
thanks
-paresh-

quote:
but when i query the major and minor radius of the entity, it turns out to be totally wrong.
what do you mean by "totally wrong"?
are the major and minor axis lies in xy plane (does they have zero z-coordinate)?
are major axis longer then minor axis?
the sample of using this functionality is dwf export.
sincerely yours,
george udov
i drew a circle in top-view mode(i.e. normal in z-coordinate system of wcs).
then i rotated my view angle till the circle was just short of becoming a line..i.e. the radius ratio(minor/major) of the resulting ellipse should be very small.
after using the orthoproject call, i find that the radius ratio = 0.85!
thats why my ellipse is fatter than the way it looks in autocad.
i want to project the ellipse in xyplane of the screen coordinates.
is the xyplane parameter that i passed to orthoproject correct??
does it assume the ellipse to be in wcs?? my ellipse is in view coordinate system..
thanks

note that odgeelliparc3d:roject, odgeelliparc3d:rthoproject are just mathematical functions.
it means that elliparc.orthoproject(odgeplane::kxyplane); will project ellipse on xy plane of coordinate system in which ellipse is given.
if your ellipse is in "view" coodinates, then odgeelliparc3d:rthoproject will return ellipse that is projection of source ellipse on xy plane of view cs.
if you need ellipse projected on xy plane of screen cs, then you should first transform source ellipse to screen cs, and then orthoproject() it.
also note that if ellipse is looking nearly like line segment, it doesn't mean that minoraxislength()/majoraxislength() will be very little for it. this statement is true only for ellipses with orthogonal axes.
sincerely yours,
george udov

non-orthogonal axis???
the orthoproject function should have returned the new orthogonal major and minor axis of the projected ellipse.
how do i query the orthogonal axes now?
should i call ellipse.correctaxis? i tried using this call. it corrects the axes..but the start and end angle returned by it are same!! the start angle should have been 0 and end angle=2*pi for an ellipse.
please help.
thanks

quote:
non-orthogonal axis???
the orthoproject function should have returned the new orthogonal major and minor axis of the projected ellipse.
in general, neither odgeelliparc3d, nor acgeelliparc3d must always have orthogonal axes. so any function, that produces odgeelliparc3d, can return ellip arc with non-orthogonal axes. including odgeelliparc3d:rthoproject().
quote:
how do i query the orthogonal axes now?
odgeelliparc::correctaxis (this function was renamed in modern dd versions, now it is called "orthogonalizeaxes") rearranges ellipse axes to be orthogonal.
quote:
it corrects the axes..but the start and end angle returned by it are same!! the start angle should have been 0 and end angle=2*pi for an ellipse.
does it transform closed ellipse to non closed? this can be obtained by this code:
code:
odgeelliparc3d* pell;
// ... doing something with pell
// ...
bool bwasclosed = pell->isclosed();
pell->correctaxis();
oda_assert(pell->isclosed == bwasclosed);
if this assert fails, it definetely means bug of dd. please note that last available 1.13 is 1.13.05, and the last available dd is 1.14.01.
sincerely yours,
george udov