几何尺寸与公差论坛------致力于产品几何量公差标准GD&T (GDT:ASME)|New GPS(ISO)研究/CAD设计/CAM加工/CMM测量  


返回   几何尺寸与公差论坛------致力于产品几何量公差标准GD&T (GDT:ASME)|New GPS(ISO)研究/CAD设计/CAM加工/CMM测量 » 仿射空间:CAX软件开发(三)二次开发与程序设计 » CAD二次开发 » AutoCAD二次开发 » DirectDWG
用户名
密码
注册 帮助 会员 日历 银行 搜索 今日新帖 标记论坛为已读


回复
 
主题工具 搜索本主题 显示模式
旧 2009-05-06, 02:18 PM   #1
yang686526
高级会员
 
注册日期: 06-11
帖子: 14579
精华: 1
现金: 224494 标准币
资产: 234494 标准币
yang686526 向着好的方向发展
默认 【转帖】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..........................
yang686526离线中   回复时引用此帖
GDT自动化论坛(仅游客可见)
回复


主题工具 搜索本主题
搜索本主题:

高级搜索
显示模式

发帖规则
不可以发表新主题
不可以回复主题
不可以上传附件
不可以编辑您的帖子

vB 代码开启
[IMG]代码开启
HTML代码关闭

相似的主题
主题 主题发起者 论坛 回复 最后发表
【转帖】3d to 2d vectorization yang686526 DirectDWG 0 2009-05-04 03:03 PM
【转帖】screw thread fim callou yang686526 American standards 0 2009-04-29 09:52 PM


所有的时间均为北京时间。 现在的时间是 01:54 PM.


于2004年创办,几何尺寸与公差论坛"致力于产品几何量公差标准GD&T | GPS研究/CAD设计/CAM加工/CMM测量"。免责声明:论坛严禁发布色情反动言论及有关违反国家法律法规内容!情节严重者提供其IP,并配合相关部门进行严厉查处,若內容有涉及侵权,请立即联系我们QQ:44671734。注:此论坛须管理员验证方可发帖。
沪ICP备06057009号-2
更多