yang686526

ray and xline?
ray and xline?
hi,
the rayproc() and xlineproc() functions of my override are not called during vectorization. i noticed that header file has a comment above these function declarations: "this function should not be overridden by clients." why is this so?
i want to draw ray and xline differently and not have them clipped to the boundary i specified while setting up the device.
thanks,
varun
hi,
i had similar problem before, and i've overriden also the xline() and ray() funcs to allow my own xlineproc() and rayproc().
code:
void myview::xline(const odgepoint3d& pt1, const odgepoint3d& pt2)
{
m_modelentrypoint.geometry().xlineproc(pt1,pt2);
}
void myview::ray(const odgepoint3d& pt1, const odgepoint3d& pt2)
{
m_modelentrypoint.geometry().rayproc(pt1,pt2);
}
hope it can help you. my view is:
class myview
: public odgsbasevectorizeview
, public odgigeometrysimplifier
{
...
}
best regards
chudomir

chudomir is absolutely right.
odgsbasevectorizeview performs clipping of xlines and rays by viewport clip region.
sincerely yours,
george udov
thanks chudomir. now am able to get the call for ray and xline using the method you suggested.
however am still having two problems with this approach:
1. i have files which contains only xlines/rays. now as i catch the calls and process xline()/ray() in my implementation of view (and don't call the base class method), my device's draw_color() and draw_color_index() are not being called for these. as a result i am unable to set the correct colors for the xlines and rays.
2. in case of ray, the position is not correct. for example, consider a file which has only one ray. dd gives me the basepoint and thrupoint, clipped to the boundary of the device and hence the basepoint is near the one of the edges, while i would expect the basepoint to be at the center after zoomextents() as it is the only relevant point in the view.
dd guys, can you help me out?
thanks,
varun

1. please try this code
code:
void yourview::xline(const odgepoint3d& pt1, const odgepoint3d& pt2)
{
if(effectivelyvisible() && !regenabort())
{
ontraitsmodified();
m_modelentrypoint.geometry().xlineproc(pt1, pt2);
}
}
void yourview::ray(const odgepoint3d& start, const odgepoint3d& pt2)
{
if(effectivelyvisible() && !regenabort())
{
ontraitsmodified();
m_modelentrypoint.geometry().rayproc(start, pt2);
}
}
2. unfortunately, our zoomextents functionality doesn't take rays into account
sincerely yours,
george udov
thanks george. point 1 is resolved.
regarding point 2, when i tried it in autocad, it mostly centered the origin of ray, hence i was looking for the same with dd. can this be added to the list of not-so-important enhancements of dd?
btw, what exactly does dd do in zoomextents(). i see that it also introduces some extra margin besides bringing all elements into view.
actually we have an efficient implementation of our own (during export), to compute the bounding box of all entities we export (as we have the bounding boxes of individual objects already cached in our app). but it doesn't match the behavior of dd's zoomextents() due to the extra margin you guys add. is this something you can share with us?
thanks,
varun

regarding point 2, it just was added to list of dd bugs :-)
about propagating your own bounding box - yes, you can do it. cdwgviewer:nviewzoomextents() includes two parts - computation of bounding box, and setting view to fit bounding box.
sincerely yours,
george udov
we're already doing it
just wanted to know how much margin we should add.
thanks,
varun

code:
bool odabstractviewpe::zoomextents(odrxobject* pview, const odgeboundblock3d* pviewext) const
{
odgeboundblock3d tmp;
if(!pviewext)
{
if(viewextents(pview, tmp))
{
tmp.settobox(true);
pviewext = &tmp;
}
else
{
return false;
}
}
else if(!pviewext->isbox())
{
tmp = *pviewext;
tmp.settobox(true);
pviewext = &tmp;
}
odgepoint3d min = pviewext->minpoint(), max = pviewext->maxpoint();
// clip huge extents
if(min.x < -10e100)
min.x = -10e100;
if(min.y < -10e100)
min.y = -10e100;
if(min.z < -10e100)
min.z = -10e100;
if(max.x > 10e100)
max.x = 10e100;
if(max.y > 10e100)
max.y = 10e100;
if(max.z > 10e100)
max.z = 10e100;
odgepoint3d viewtarg = target(pview);
odgevector3d viewdir = direction(pview);
odgematrix3d xeyetoworld = eyetoworld(pview);
// set target to center of the scene, keeping view direction:
odgepoint3d newtarg = xeyetoworld * (min + (max - min) / 2.0);
if(isfrontclipon(pview) || isbackclipon(pview))
{
// keeping distance from target to front & back planes
newtarg = newtarg.orthoproject(odgeplane(viewtarg, viewdir));
}
double fw = pviewext->maxpoint().x - pviewext->minpoint().x;
double fh = pviewext->maxpoint().y - pviewext->minpoint().y;
setview(pview, newtarg, viewdir, upvector(pview), fw * 1.02, fh * 1.02, isperspective(pview));

return true;
}
sincerely yours,
george udov
ah! i see... 1.02 = 1% margin on all four sides.
thanks sergery.
regards,
varun
hi george,
found another problem:
for a file containing only rays/xlines, the call to my device::xlineproc() and device::rayproc() have parameters outside the bounds specified to my device's onsize().
for example, with attached files, with {0, 0, 100, 100} specified to onsize(), i get negative values for the firstpoint/basepoint of xline/ray in my device's override.
the coordinates passed to my view::xline() and view::ray() do not seem to be dependant on the bounds set.
i am now doing exactly as you suggested. that is calling m_modelentrypoint.geometry().rayproc() and m_modelentrypoint.geometry().xline() from inside my view.
i've attached the files i am testing.
please advise.
thanks,
varun
attached files (23.2 kb, 6 views)
(23.4 kb, 3 views)


if you don't want to get clipped xlines/rays, then they surely will sometimes have end points out of window (see attached picture).
attached images (2.2 kb, 15 views)

sincerely yours,
george udov
yes, but if i have specified a bounding box i expect:
- all ray origins to lie inside the bounding box (not happening now).
- all xlines to have some intersecting portion with the boundng box (not happening now).
or am i being completely unreasonable?
(images with the two dwg files i posted before, imported with a bounding box of size 100x100 are attached with the bounding boxes also drawn).
thanks,
varun
attached images (15.5 kb, 14 views)
(21.0 kb, 14 views)


by default, dd clips xlines and rays by screen rectangle you specified, and gives you result polylines. that are lie on screen for sure.
if you disable this clipping, you'll get unclipped xlines and rays. of course, they can have definition points outside the screen rectangle, and even can have place far from screen rect.
btw, if task is to highlight rays and xlines geometry, the correct way is:
code:
void yourview::xline(const odgepoint3d& pt1, const odgepoint3d& pt2)
{
m_bxlinegraphics = true;
odgsbasevectorizeview::xline(pt1, pt2);
m_bxlinegraphics = false;
}
void yourview::ray(const odgepoint3d& start, const odgepoint3d& pt2)
{
m_braygraphics = true;
odgsbasevectorizeview::ray(start, pt2);
m_braygraphics = false;
}
then you can analyze flags m_bxlinegraphics and m_braygraphics in your polylineout. btw, such approach is used, e.g., in odgsopenglvectorizeview::text.
sincerely yours,
george udov

hi george,
tried the new suggestion. it works even worse than before:
- starting points of all rays in the attached file are lost.
- all xlines which were not intersecting with the bounding box are dropped.
so far the closest we've gotten to the expected output is with the method using m_modelentrypoint.geometry()... suggested by you and chudomir earlier.
please take a look at the attached images (newconstructionline.jpg and newray.jpg are outputs with checking flags in polylineout() as suggested in your last post).
is the difference only due to the dd bug of not taking xline/ray into account during zoomextents()? and if so can i expect the output using m_modelentrypoint.geometry()... to match the expected output once you provide the fix for this bug in your maintainance release?
you mentioned about disabling default clipping. how do i go about doing that? does this only affect rays and xlines?
thanks,
varun
attached images (14.0 kb, 11 views)
(16.1 kb, 10 views)
(14.8 kb, 9 views)
(12.0 kb, 10 views)