DXF importer creates bad arcs representation #76908

Open
opened 2020-05-20 12:32:08 +02:00 by Vaclav Cermak · 20 comments

System Information
Operating system: Linux-5.6.11-050611-generic-x86_64-with-debian-bullseye-sid 64 Bits
Graphics card: GeForce GTX TITAN X/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 440.64

Blender Version
Broken: v2.82, v3.2
Worked: Never

Short description of error

Arcs are improperly converted to curves when imported from DXF, they are not perfectly circular.

The DXF specification doesn't mandate the use of any curve type, it just says that there is an arc with a specific radius, center, and angle. How the software draw or represents that arc is up to it. Currently, the importer represents arcs as Bezier curves, but it computes their handles wrong, which is what the report demonstrates. So a fix would then change the importer to compute the bezier handle correctly. However, as suggested by the user, since NURBS can represent arcs better (Bezier curves are approximations), then it maybe worth it to change the importer to import NURBS instead.

See http://docs.autodesk.com/ACD/2011/ENU/filesDXF/WS1a9193826455f5ff18cb41610ec0a2e719-7a35.htm.

Exact steps for others to reproduce the error

I have created a simple DXF file containing one circle and one arc. Both have common center at point [0,100] and radius 100. If I import them by Blender importer, the resulting arc does not match the circle.

dxf_import-01.dxf dxf_import.blend

**System Information** Operating system: Linux-5.6.11-050611-generic-x86_64-with-debian-bullseye-sid 64 Bits Graphics card: GeForce GTX TITAN X/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 440.64 **Blender Version** Broken: v2.82, v3.2 Worked: Never **Short description of error** Arcs are improperly converted to curves when imported from DXF, they are not perfectly circular. The DXF specification doesn't mandate the use of any curve type, it just says that there is an arc with a specific radius, center, and angle. How the software draw or represents that arc is up to it. Currently, the importer represents arcs as Bezier curves, but it computes their handles wrong, which is what the report demonstrates. So a fix would then change the importer to compute the bezier handle correctly. However, as suggested by the user, since NURBS can represent arcs better (Bezier curves are approximations), then it maybe worth it to change the importer to import NURBS instead. See http://docs.autodesk.com/ACD/2011/ENU/filesDXF/WS1a9193826455f5ff18cb41610ec0a2e719-7a35.htm. **Exact steps for others to reproduce the error** I have created a simple DXF file containing one circle and one arc. Both have common center at point [0,100] and radius 100. If I import them by Blender importer, the resulting arc does not match the circle. [dxf_import-01.dxf](https://archive.blender.org/developer/F8544665/dxf_import-01.dxf) [dxf_import.blend](https://archive.blender.org/developer/F8544666/dxf_import.blend)
Author

Added subscriber: @VaclavCermak

Added subscriber: @VaclavCermak

Added subscriber: @rjg

Added subscriber: @rjg

Changed status from 'Needs Triage' to: 'Needs User Info'

Changed status from 'Needs Triage' to: 'Needs User Info'

How did you create the *.dxf file and are you certain that your expectation with regards to the arc are valid according to the file format specification?

How did you create the `*.dxf` file and are you certain that your expectation with regards to the arc are valid according to the file format specification?
Author

DXF was simply drawn in BricsCAD (https://www.bricsys.com) and exported from it. So I assume that the file is valid, but I haven't checked it except reopening in BricsCAD.

DXF was simply drawn in BricsCAD (https://www.bricsys.com) and exported from it. So I assume that the file is valid, but I haven't checked it except reopening in BricsCAD.

Changed status from 'Needs User Info' to: 'Needs Triage'

Changed status from 'Needs User Info' to: 'Needs Triage'
Member

Added subscriber: @OmarEmaraDev

Added subscriber: @OmarEmaraDev
Member

Changed status from 'Needs Triage' to: 'Needs User Info'

Changed status from 'Needs Triage' to: 'Needs User Info'
Member

The imported files looks like this for me. There is a tiny difference at 270, and that difference exist when I tested the files on other software. So this doesn't seem like a Blender specific issue.
Is this the difference you are describing?

20220309-134125.png

The imported files looks like this for me. There is a tiny difference at 270, and that difference exist when I tested the files on other software. So this doesn't seem like a Blender specific issue. Is this the difference you are describing? ![20220309-134125.png](https://archive.blender.org/developer/F12913311/20220309-134125.png)
Author

Yes, its probably that difference. The curve should go exactly through [0, 0] point and it does not.

To be honest, I created it two years ago and I don't remember the exact reason for reporting it. It was probably when I imported some site plan with lot of detailed roads and their arcs were somewhat misplaced and didn't fit to other parts of that plan.

Yes, its probably that difference. The curve should go exactly through [0, 0] point and it does not. To be honest, I created it two years ago and I don't remember the exact reason for reporting it. It was probably when I imported some site plan with lot of detailed roads and their arcs were somewhat misplaced and didn't fit to other parts of that plan.
Member

Changed status from 'Needs User Info' to: 'Confirmed'

Changed status from 'Needs User Info' to: 'Confirmed'
Member

The difference looks much larger in Blnder when compared to other software indeed. So looks like an import issue.

The difference looks much larger in Blnder when compared to other software indeed. So looks like an import issue.
Author

I'am not sure, if a circular arc can be exactly represented by bezier curves at all (I think not), so it may be fundamental problem, not some bug in calculating curve coeficients. It may be solved by using nurbs curves instead bezier ones then.

I'am not sure, if a circular arc can be exactly represented by bezier curves at all (I think not), so it may be fundamental problem, not some bug in calculating curve coeficients. It may be solved by using nurbs curves instead bezier ones then.
Member

That is true, but small arcs can be approximated very well with bezier curves, so I doubt this is an intrinsic limitation.

That is true, but small arcs can be approximated very well with bezier curves, so I doubt this is an intrinsic limitation.
Author

Agreed, but...

At first, something convinced me to create this task. Unfortunately I can't remember what it was exactly. But it means, that there was a situation, when this limitation had its own impact.

And second, is there any reason not to use nurbs? When we have the opportunity to represent imported geometry exactly, why not to use it?

Agreed, but... At first, something convinced me to create this task. Unfortunately I can't remember what it was exactly. But it means, that there was a situation, when this limitation had its own impact. And second, is there any reason not to use nurbs? When we have the opportunity to represent imported geometry exactly, why not to use it?
Author

As for that "impact", if I import a site plan, arcs forming roads have typically big sizes. Even with small error they may be misplaced from other point element imported from the same site plan (trees, streetlights etc.) significantly. Maybe this was the problem.

Now I'am converting all arcs and circles to polylines with some CAD utility before import to Blender, so I haven't met this problem for a while. It is clumsy, however.

As for that "impact", if I import a site plan, arcs forming roads have typically big sizes. Even with small error they may be misplaced from other point element imported from the same site plan (trees, streetlights etc.) significantly. Maybe this was the problem. Now I'am converting all arcs and circles to polylines with some CAD utility before import to Blender, so I haven't met this problem for a while. It is clumsy, however.
Member

Perhaps Nurbs could be used as a better option, but that is up to the maintainers of the add-on, so we should just wait and see what they think about that.

Perhaps Nurbs could be used as a better option, but that is up to the maintainers of the add-on, so we should just wait and see what they think about that.
Author

Or we may try to dive into it and create a patch, it shouldn't be so hard ;-) But first I want to discuss, if there are any reasons not to use nurbs. Maybe I'am missing something.

Or we may try to dive into it and create a patch, it shouldn't be so hard ;-) But first I want to discuss, if there are any reasons not to use nurbs. Maybe I'am missing something.
Member

@VaclavCermak Feel free to try to create a patch that uses NURBS to import acrs to fix this issue. Or if proven harder than expected, maybe try fixing the bezier computations first. Let us know if you need any help doing that.

@VaclavCermak Feel free to try to create a patch that uses NURBS to import acrs to fix this issue. Or if proven harder than expected, maybe try fixing the bezier computations first. Let us know if you need any help doing that.
Author

Fine, I'll try that. I have looked into the source and I think that I know how and where I should add it.

Fine, I'll try that. I have looked into the source and I think that I know how and where I should add it.
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender-addons#76908
No description provided.