Scan Conversion technique in Tool-path Generation

[sajjadul-wematter]

Hello

The process of toggle point generation for the tool-path is similar to the concept of rasterization in computer graphics image generation. The goal of the 3D printing engine is to generate discrete points on the boundary contours at which materials would be deposited.

While going through the scan conversion technique, I found out the issue of boundary pixels as mentioned in the Book - "Computer Graphics - Principles and Practice"(Details on page 92).

1. The scan conversion can be applied to arbitrary polygon .
2. Bottom-left vertex is rendered twice and this special case with a special case as mentioned later in the book.
3. The rule causes each span to be missing its rightmost pixel and each rectangle to be missing its topmost row.

The above issues are virtually copied from the book I mentioned.

My query is that - if the scan conversion concept is used in CURA how the 2nd and 3rd issues are dealt within the framework , which classes do I have to look into ?

Thanks

[BagelOrb]

I'm not familiar with a lot of the concepts you are referring to, but let me try to answer your questions before reading up on them.

While the engine does use integer arithmetic, that doesn't necessarily mean the concept of rasterizarion is applicable. We might just as well have used floating points.

No material is deposited on the boundary of the model, but an offset of half the nozzle size inward.

Because of rounding errors etc we glue the lines which result from slicing all faces to each other by just snapping the endpoints together. The minimal rounding error which we can possibly achieve is 0.5 in integer arithmetic, so a boundary case of 1 pixel is most probably negligible.

I think the problems you mention don't really play a role in our application.

You could look at https://github.com/Ultimaker/CuraEngine/blob/master/src/slicer.cpp However, it's not documented up to standard yet :S Op 3 jun. 2016 23:54 schreef "sajis997" notifications@github.com:

Hello

The process of toggle point generation for the tool-path is similar to the concept of rasterization in computer graphics image generation. The goal of the 3D printing engine is to generate discrete points on the boundary contours at which materials would be deposited.

While going through the scan conversion technique, I found out the issue of boundary pixels as mentioned in the Book - "Computer Graphics - Principles and Practice"(Details on page 92).

1. The scan conversion can be applied to arbitrary polygon .
2. Bottom-left vertex is rendered twice and this special case with a special case as mentioned later in the book.
3. The rule causes each span to be missing its rightmost pixel and each rectangle to be missing its topmost row.

The above issues are virtually copied from the book I mentioned.

My query is that - if the scan conversion concept is used in CURA how the 2nd and 3rd issues are dealt within the framework , which classes do I have to look into ?

Thanks

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/CuraEngine/issues/347, or mute the thread https://github.com/notifications/unsubscribe/AIe9ERtW_bf-T7Bm4V_K1wvkPdALJhRuks5qIKKFgaJpZM4It8Jw .

[BagelOrb]

Perhaps you should ask the frontend team about how they render models. This repo is about converting 3d models to machine instructions. https://github.com/Ultimaker/Cura Op 4 jun. 2016 13:31 schreef "Tim Kuipers" t.kuipers@ultimaker.com:

I'm not familiar with a lot of the concepts you are referring to, but let me try to answer your questions before reading up on them.

While the engine does use integer arithmetic, that doesn't necessarily mean the concept of rasterizarion is applicable. We might just as well have used floating points.

No material is deposited on the boundary of the model, but an offset of half the nozzle size inward.

Because of rounding errors etc we glue the lines which result from slicing all faces to each other by just snapping the endpoints together. The minimal rounding error which we can possibly achieve is 0.5 in integer arithmetic, so a boundary case of 1 pixel is most probably negligible.

I think the problems you mention don't really play a role in our application.

You could look at https://github.com/Ultimaker/CuraEngine/blob/master/src/slicer.cpp However, it's not documented up to standard yet :S Op 3 jun. 2016 23:54 schreef "sajis997" notifications@github.com:

Hello

The process of toggle point generation for the tool-path is similar to the concept of rasterization in computer graphics image generation. The goal of the 3D printing engine is to generate discrete points on the boundary contours at which materials would be deposited.

While going through the scan conversion technique, I found out the issue of boundary pixels as mentioned in the Book - "Computer Graphics - Principles and Practice"(Details on page 92).

1. The scan conversion can be applied to arbitrary polygon .
2. Bottom-left vertex is rendered twice and this special case with a special case as mentioned later in the book.
3. The rule causes each span to be missing its rightmost pixel and each rectangle to be missing its topmost row.

The above issues are virtually copied from the book I mentioned.

My query is that - if the scan conversion concept is used in CURA how the 2nd and 3rd issues are dealt within the framework , which classes do I have to look into ?

Thanks

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/CuraEngine/issues/347, or mute the thread https://github.com/notifications/unsubscribe/AIe9ERtW_bf-T7Bm4V_K1wvkPdALJhRuks5qIKKFgaJpZM4It8Jw .

[sajjadul-wematter]

Thanks for the feedback,

It is not about rendering at all. It is indeed about filling polygon contours. And I am trying to understand the underlying concept behind it. I believe that , CURA engine does the filling process with melted materials for each and every layer.

I have found that the scan conversion technique from computer graphics is usually borrowed to do the job of polygon contour filling in additive manufacturing. I am trying to get into the algorithm that you might have implemented in your engine.

[BagelOrb]

Fdm printers are less like 2d matrix printers and more like laser cutters in that it doesn't specify which pixels/voxels are on, but it specifies the positions at which the print head should be.

I think you should look for slicers for resin printers, rather than fdmprinters.

Cura essentially works with polygons and performs offsets and ray-polygon intersections.

Even if the boundary case you talk about does occur in the engine, it most probably is neglected because it will only cause a defect of 1 micron, which is way less than all other defects and inaccuracies involved. Op 4 jun. 2016 13:53 schreef "sajis997" notifications@github.com:

Thanks for the feedback,

It is not about rendering at all. It is indeed about filling polygon contours. And I am trying to understand the underlying concept behind it. I believe that , CURA engine does the filling process with melted materials for each and every layer.

I have found that the scan conversion technique from computer graphics is usually borrowed to do the job of polygon contour filling in additive manufacturing. I am trying to get into the algorithm that you might have implemented in your engine.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/CuraEngine/issues/347#issuecomment-223751627, or mute the thread https://github.com/notifications/unsubscribe/AIe9ERert7LZf8O07l0PCNWsTUT2oUgRks5qIWdSgaJpZM4It8Jw .

[DDDirk]

No material is deposited on the boundary of the model, but an offset of half the nozzle size inward.

That would explain why prints are often slightly bigger than the model, about 0,1 mm or less. Which is a problem if things have to fit precisely. The reason is that although it is mathematically correct, in reality the roads are rounded at the edges, so the middle sticks out a bit, while the top and bottom bend inwards. If the outer wall would be printed 0,1 mm further inward that would solve the problem. And increase the adhesion with the inner wall because there is a slight overlap. Someone else tested this too, and said the print was stronger (I don't know what overlap he used). However, this might depend on many factors, so maybe a more conservative overlap would be advisable. I tested this once with several overlaps and even with an overlap of just 0,025 mm there was an improved adhesion between the walls. And with an overlap of a whopping 0,375 mm the total wall size was 0,45 mm (0,4 mm nozzle size). Mind you, this was with a nominal extrusion speed of 5 mm³/s (on an Ultimaker 2), so there probably was underextrusion.

[BagelOrb]

Indeed that explains that. The fact is that the boundary of a print is a volume rather than a surface, due to the layers being rounded.

You can apply the horizontal expansion to solve that, or the outer wall inset to offset only the outer wall. To get a good overlap with the infill you can change the infill overlap, and there will be a separate skin overlap in a future release. Op 4 jun. 2016 15:48 schreef "Dirk van der Made" notifications@github.com:

No material is deposited on the boundary of the model, but an offset of half the nozzle size inward. That would explain why prints are often slightly bigger than the model, about 0,1 mm or less. Which is a problem if things have to fit precisely. The reason is that although it is mathematically correct, in reality the roads are rounded at the edges, so the middle sticks out a bit, while the top and bottom bend inwards. If the outer wall would be printed 0,1 mm further inward that would solve the problem. And increase the adhesion with the inner wall because there is a slight overlap. Someone else tested this too, and said the print was stronger (I don't know what overlap he used). However, this might depend on many factors, so maybe a more conservative overlap would be advisable. I tested this once with several overlaps and even with an overlap of just 0,025 mm there was an improved adhesion between the walls. And with an overlap of a whopping 0,375 mm the total wall size was 0,45 mm (0,4 mm nozzle size). Mind you, this was with a nominal extrusion speed of 5 mm³/s (on an Ultimaker 2), so there probably was underextrusion.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/CuraEngine/issues/347#issuecomment-223756607, or mute the thread https://github.com/notifications/unsubscribe/AIe9Eff3eEyiKNatEgXU4NSQHOXwm9Foks5qIYIQgaJpZM4It8Jw .