高级会员
注册日期: 06-11
帖子: 14579
精华: 1
现金: 224494 标准币
资产: 234494 标准币
|
【转帖】how to avoid rounding errors when using vectorization for im
how to avoid rounding errors when using vectorization for im
how to avoid rounding errors when using vectorization for import?
i am using vectorization framework of dd release 2.2.0 vc8 static libs to import contents of a dwg file into our application.
i am trying to bring everything at the same scale, that is i want a line of 'n' autocad unit to be mapped to exactly 'n' units in my application. the way i approach this is to get the height() and width() of oddbviewporttablerecord to be vectorized and set up a odgsdcrect so that it has the exact same height and width as the viewport and pass this rect to my device's onsize().
this works fine if the height and the width of the viewport have exact integral values, but in the real world case this is extremely rare.
when the height and width are floating numbers, we have to supply an integral value for the bounds of the rect; as odgsdcpoint (used by odgsdcrect) use long as the base data type.
this leads to a little bit of scaling due to the rounding off error.
for example, if i have have a horizontal line in the autocad file which measures 5 units and i vectorize a viewport which has the width setup as 5.1 units, i am only able to specify the width to my onsize as 5 units (after rounding off) and the actual length of the line i get in my device's callbacks is 4.902 units.
is there someway i can workaround this problem? as the actual device's callback api's take odgepoint3d and odgevector3d which are based on double, does it make more sense for odgsdcpoint to support floating values?
regards,
varun
dd folks, any answer to this question?
seems a very big issue in the library to me!.
thanks in advance,
-paresh-
hi,
for now only thing you can do is increase accuracy 10000-100000 times increasing viewport size. e.g. set size to 8000000 instead of setting it to 800 and then divide received geometry coordinates to 10000. don't forget to scale deviation accordingly to keep tesselation accuracy!
we'll think about interface changes necessary to solve this problem.
i've had to deal with this issue as well. increasing the viewport size does work but it causes significant performance degradation in vectorization because of the increase in tesselation, triangulation, linetype generation, etc... i spent some time trying to offset the effect of the large viewport size but ran out of time.
i am interesting in finding a solution to this problem.
thanks,
chad
chad,
you should override odgsbasevectorizeview::deviation() like this:
code:
double myvectorizeview::deviation(const odgideviationtype type, const odgepoint3d& pt) const
{
return m_dvpscale *fff"> odgsbasevectorizeview::deviation(type, pt);
}
that's what i told about above:
quote:
originally posted by me
don't forget to scale deviation accordingly to keep tesselation accuracy!
.
thanks for the reply but i don't have m_dvpscale available to me anywhere. how is that scale calculated?
thanks,
chad
this should be a variable in your derivative of odgsbasevectorizeview (e.g. myvectorizeview) which is set to the same value that is used to scale viewport size.
ok, i see what you are saying about deviation. yes, increasing the deviation as the viewport size grows solves many of the problems and i am doing that. one other problem that comes to mind that is not solved by deviation is the generation of linetypes.
i've attached an image that illlustrates the problem. this particular drawing has lines with an extremely small linetype scale. normally, this line is vectorized as a continuous line because the segmentation is too small to notice on the screen. giving such a large viewport size, however, causes the lines to be broken up into thousands of tiny segments which is a huge performance degradation (both time and memory for us.)
is there a way to control the linetype generation so that it behaves as if there were a smaller viewport size?
changing the linetype scale is not an option because that will change the appearance of the drawing which is not acceptable.
thanks for any advice on this,
chad
attached images (21.2 kb, 7 views)
chad,
you should override odgsbasevectorizeview::linetypegenerationcriteria( ) in the same manner as deviation().
perfect!
thank you very much for that information.
chad
hi dd folks,
is the support for floating points arguments in onsize() expected in the upcoming dd 2.3 release?
regards,
varun
yes..........................
|