The read data does not match the display

[Ersoga]

Hi: I have a question... I have a Dxf file, I use netDxf to read it, the data in debugging is not consistent with the display in AutoCad, I don't know what is the problem. D.zip

[haplokuon]

Entities that belong to a block are local to the Insert (block reference) that references the block. So, in your case the start and end points of the lines inside the block must be multiplied by the transformation matrix of the Insert.

[Ersoga]

Yes, I know this, but the rotation data read in the insert block is 0, probably it should be 180 degrees, is this the transformation matrix you are referring to?

[haplokuon]

The Insert rotation is zero because that is the value stored in the DXF. You can try to load and save the file with netDxf and you will get the same result. The Insert transformation matrix can be obtained with the GetTransformation method it will return a Matrix3, it is a combination of the relationship between the document units and the block units, the insert scale, rotation, and normal. Additionally you will have to translate the coordinates of the entities inside the block to the Insert position.

Why do you think that the rotation should be 180º?

[Ersoga]

I get the correct directional result using the GetTreansformation method, and I notice that I'm ignoring the normal vector. Previously, I used the offset, rotate, and scale data to generate the transformation matrix, but the result was the opposite of the direction shown in AutoCAD, so I thought it might be 180 degrees. Thank you very much for your answer.

[airsxue]

The Insert rotation is zero because that is the value stored in the DXF. You can try to load and save the file with netDxf and you will get the same result. The Insert transformation matrix can be obtained with the GetTransformation method it will return a Matrix3, it is a combination of the relationship between the document units and the block units, the insert scale, rotation, and normal. Additionally you will have to translate the coordinates of the entities inside the block to the Insert position.

Why do you think that the rotation should be 180º?

Hi, I already got the transformation matrix as below.but how can I use it to get final correct posion of this insert? Thansk so much.

[Ersoga]

插入旋转为零，因为这是存储在 DXF 中的值。您可以尝试使用 netDxf 加载和保存文件，您将获得相同的结果。插入变换矩阵可以通过GetTransformation方法得到，它会返回一个Matrix3，它是文档单位和块单位的关系，插入比例，旋转，法线的组合。此外，您必须将块内实体的坐标转换为插入位置。 为什么你认为旋转应该是 180º？

嗨， 我已经得到了如下的转换矩阵。但是如何使用它来获得此插入的最终正确位置？非常感谢。

This is my code, hope it helps you.

[airsxue]

插入旋转为零，因为这是存储在 DXF 中的值。您可以尝试使用 netDxf 加载和保存文件，您将获得相同的结果。插入变换矩阵可以通过GetTransformation方法得到，它会返回一个Matrix3，它是文档单位和块单位的关系，插入比例，旋转，法线的组合。此外，您必须将块内实体的坐标转换为插入位置。 为什么你认为旋转应该是 180º？

嗨， 我已经得到了如下的转换矩阵。但是如何使用它来获得此插入的最终正确位置？非常感谢。

This is my code, hope it helps you. Wow, work well with your code, Thanks so much for your help. BTW, you are Chinese as well? nice to meet Chinese in Git.

[Ersoga]

您可以通过一个矩阵的格式文件和格式来保存。您可以在存储DX中尝试使用转换格式。单位和块单位的关系，为什么插入，旋转，法线的组合。另外，你必须将块内实体的坐标转换为插入。 你认为旋转的位置应该是180度？

嗨，我已经得到了这样的转换矩阵。但是如何使用它来获得这个插件的最终正确位置？非常感谢。

这是我的代码，希望对你有帮助。 哇，您的代码工作得很好，非常感谢您的帮助。BTW，你也是中国人？很高兴在 Git 中认识中国人。

Yeah, nice to meet you too.

[airsxue]

您可以通过一个矩阵的格式文件和格式来保存。您可以在存储DX中尝试使用转换格式。单位和块单位的关系，为什么插入，旋转，法线的组合。另外，你必须将块内实体的坐标转换为插入。 你认为旋转的位置应该是180度？

嗨，我已经得到了这样的转换矩阵。但是如何使用它来获得这个插件的最终正确位置？非常感谢。

这是我的代码，希望对你有帮助。 哇，您的代码工作得很好，非常感谢您的帮助。BTW，你也是中国人？很高兴在 Git 中认识中国人。

Yeah, nice to meet you too. 哈喽， 感谢你之前的帮助。之前你提供的那个代码应该是用于块对象的，请问如果多线段等对象有normal(0,0,-1)的情况应该怎么处理呢？谢谢！

[Ersoga]

您可以通过一个矩阵的格式文件和格式来保存。您可以在存储DX中尝试使用转换格式。单位和块单位的关系，为什么插入，旋转，法线的组合。另外，你必须将块内实体的坐标转换为插入。 你认为旋转的位置应该是180度？

嗨，我已经得到了这样的转换矩阵。但是如何使用它来获得这个插件的最终正确位置？非常感谢。

这是我的代码，希望对你有帮助。 哇，您的代码工作得很好，非常感谢您的帮助。BTW，你也是中国人？很高兴在 Git 中认识中国人。

Yeah, nice to meet you too. 哈喽， 感谢你之前的帮助。之前你提供的那个代码应该是用于块对象的，请问如果多线段等对象有normal(0,0,-1)的情况应该怎么处理呢？谢谢！

你可以看看项目源代码是如何使用Normal值的

[DavidWishengrad]

Hi,

I do not have the knowledge and experience to comment on most items here, and I am not sure I understand your problem properly, but it appears to me your transformation numbers are differing at the 14th decimal place.

This is similar to a problems I have had outside of netDXF, but with ACAD itself and how it handles roundoff errors. It can be a real nasty problem if it is not addressed. I have usually found quick work-arounds for my needs, such as adding a transformation matrix in the obscure dxf codes 1011 and 1013 from the get go, and then pulling them later. They update automatically as the object is transformed and translated by the end user while working.

• Registered Application Name: MILLLISTER
• Code 1011, 3D World space position: (0.00000000 0.00000000 0.00000000)
• Code 1013, 3D World space direction: (1.00000000 0.00000000 0.00000000)
• Code 1013, 3D World space direction: (0.00000000 1.00000000 0.00000000)
• Code 1013, 3D World space direction: (0.00000000 0.00000000 1.00000000)

Aside from getting the full 16 point precision and using that (it appears it can still break because it is really only good to 15, and not really 16, so calc errors are always possible), by making sure that all software involved is working to that precision...

it appears to me your only work-around is actually fixing the problem itself and calculating the unit circle square y vector from the known x vector and then the z vector and then using those calced numbers instead. If you have to check it by finding the dot product and it's wrong, you still need to fix it regardless, so why not just recalc it in your code? It seems like a way forward.

I may have all of this completely wrong. You will get the best advice from the others, but it is seriously high level math they understand from my point of view. Hope it can help though.

Take care

PS. That is the readout from the commandline in ACAD using the lisp command xdlist. In code those numbers are set and read at 16 decimal places.

On a final note, if one adds that matrix data upfront on every object as it is created and has a rendering engine that the values can be changed in, it then becomes a first person shooter video game. Yeah, that can be easily done. I have no real need for it and if one were really wanting that there are far better options to code for and with, but it would be funny.

[Ersoga]

Hi,

I do not have the knowledge and experience to comment on most items here, and I am not sure I understand your problem properly, but it appears to me your transformation numbers are differing at the 14th decimal place.

This is similar to a problems I have had outside of netDXF, but with ACAD itself and how it handles roundoff errors. It can be a real nasty problem if it is not addressed. I have usually found quick work-arounds for my needs, such as adding a transformation matrix in the obscure dxf codes 1011 and 1013 from the get go, and then pulling them later. They update automatically as the object is transformed and translated by the end user while working.

• Registered Application Name: MILLLISTER
• Code 1011, 3D World space position: (0.00000000 0.00000000 0.00000000)
• Code 1013, 3D World space direction: (1.00000000 0.00000000 0.00000000)
• Code 1013, 3D World space direction: (0.00000000 1.00000000 0.00000000)
• Code 1013, 3D World space direction: (0.00000000 0.00000000 1.00000000)

Aside from getting the full 16 point precision and using that (it appears it can still break because it is really only good to 15, and not really 16, so calc errors are always possible), by making sure that all software involved is working to that precision...

it appears to me your only work-around is actually fixing the problem itself and calculating the unit circle square y vector from the known x vector and then the z vector and then using those calced numbers instead. If you have to check it by finding the dot product and it's wrong, you still need to fix it regardless, so why not just recalc it in your code? It seems like a way forward.

I may have all of this completely wrong. You will get the best advice from the others, but it is seriously high level math they understand from my point of view. Hope it can help though.

Take care

PS. That is the readout from the commandline in ACAD using the lisp command xdlist. In code those numbers are set and read at 16 decimal places.

On a final note, if one adds that matrix data upfront on every object as it is created and has a rendering engine that the values can be changed in, it then becomes a first person shooter video game. Yeah, that can be easily done. I have no real need for it and if one were really wanting that there are far better options to code for and with, but it would be funny.

Thank you for your reply, but maybe you misunderstood my question, thanks for your suggestion.

[airsxue]

Hi, I do not have the knowledge and experience to comment on most items here, and I am not sure I understand your problem properly, but it appears to me your transformation numbers are differing at the 14th decimal place. This is similar to a problems I have had outside of netDXF, but with ACAD itself and how it handles roundoff errors. It can be a real nasty problem if it is not addressed. I have usually found quick work-arounds for my needs, such as adding a transformation matrix in the obscure dxf codes 1011 and 1013 from the get go, and then pulling them later. They update automatically as the object is transformed and translated by the end user while working.

• Registered Application Name: MILLLISTER
• Code 1011, 3D World space position: (0.00000000 0.00000000 0.00000000)
• Code 1013, 3D World space direction: (1.00000000 0.00000000 0.00000000)
• Code 1013, 3D World space direction: (0.00000000 1.00000000 0.00000000)
• Code 1013, 3D World space direction: (0.00000000 0.00000000 1.00000000)

Aside from getting the full 16 point precision and using that (it appears it can still break because it is really only good to 15, and not really 16, so calc errors are always possible), by making sure that all software involved is working to that precision... it appears to me your only work-around is actually fixing the problem itself and calculating the unit circle square y vector from the known x vector and then the z vector and then using those calced numbers instead. If you have to check it by finding the dot product and it's wrong, you still need to fix it regardless, so why not just recalc it in your code? It seems like a way forward. I may have all of this completely wrong. You will get the best advice from the others, but it is seriously high level math they understand from my point of view. Hope it can help though. Take care PS. That is the readout from the commandline in ACAD using the lisp command xdlist. In code those numbers are set and read at 16 decimal places. On a final note, if one adds that matrix data upfront on every object as it is created and has a rendering engine that the values can be changed in, it then becomes a first person shooter video game. Yeah, that can be easily done. I have no real need for it and if one were really wanting that there are far better options to code for and with, but it would be funny.

Thank you for your reply, but maybe you misunderstood my question, thanks for your suggestion.

Thanks so much for all your suggestion,it helps lot.