Awesome LISP gives different results of multiple PC's

[adelin_farcas]

Hello awesome community!

I'm seeking for your guidance in a interesting problem.

My team is currently testing and running a LISP made by the Guru - Lee Mac called "Outline Objects" https://lee-mac.com/outlineobjects.html. (I would attach the lsp file but there are only 3 maximum)

We are getting close to the desired end-result (creating outlines of the tools) but it seems like the LISP gives different results of different PC's. On one PC it works perfectly, on others it creates small closed polylines and disrupts the general outline. Can you offer us some guidance on why this may occur?

Note: The file is coming in as a DXF with multiple polyline segments. We're using PEDIT / M / With a 0.05 Join with Extend to transform the shapes into closed polylines before running the script.

We believe it may be due to the fact that the "dis" & "zoomwindow" may be calculated screen-based measurement, and the output of each graphics gard may offer different results. But we're not sure, that's why we are posting here.

I'm adding all the DWG's in the attachments. Thank you!

[TomBeauford]

Always worked fine for me but I only work using the WCS Lee mentions in his code. Maybe a UCS coordinate system current in the drawing caused the incorrect results?

[Kent1Cooper]

Is it affected by Zoom level?

[AshRAECSolutions]

@adelin_farcas 

Actually if Lisp not give desired result that mean's .  Current Data is not same as Sample data which used to Create Lisp.

So In this case your Data is required a preprocess after that you can use this Lisp 

Data have some issue 

Dangle found in Data mean Lwpolylines not connected properly. 

If you have "adedwgclean" which belongs to Map version of autocad will help you also distance between vertex is close to 0 which is not requried. 

you can check attached png file. 

Hope so this will fix issue.

[adelin_farcas]

Hey Tom! Thanks for the idea.
I've tested are the UCS orientation and set to World, but no changes have been made to the result of the script. Thanks for writing!

[adelin_farcas]

Hey Ken!
I've tested with multiple Zoom Levels and it would seem like it does not affect it. Thanks for the idea!

[adelin_farcas]

The Ash! This was a good one, with awesome ideas.

Your observation is correct, when the DXF, is exported and reaches us, it will have interrupted polylines. Before trying the script we're Joining the Polylines PEDIT / M / Join (Extend JoinType) / 0.2 fuzz to join everything, and afterwards we run the script.

[AshRAECSolutions]

@adelin_farcas 

Thank you so much for your kind words! we are glad you found the ideas presented here to be awesome. Your acknowledgment means a lot to us, and we appreciate your validation of our observation. If there's anything else we are happy to help.

[adelin_farcas]

The only thing is that the issue still persists on different resolutions even after PEDIT/JOIN and transforming them into closed poluylines. It would seem like different resolutions/windows scalin affects somhow the script calculations. We're still investigating, any other ideas are appreciated!

[AshRAECSolutions]

Actually  First issue is resolved now. now lwpolyline are connected properly.

But still one issue are there as we informed vertex are so close to each other and when Lisp process lwpolyline those vertex stop Lisp to create proper polygon.

So you need to some how make these polylines light weight mean's reduce number of vertex without shape distorted. 

Than everything will work fine.  

[Kent1Cooper · Accepted solution]

---

@AshRAECSolutions wrote:

....

So you need to some how make these polylines light weight mean's reduce number of vertex without shape distorted. 

....  

---

A Polyline being "lightweight" has nothing to do with how many vertices there are, but rather how the information about it is stored.  The same Polyline can be either "heavy" or "lightweight" without any difference in the shape or number of vertices.  Since all the Polylines in the sample drawing seem to be made of line segments only, it is not possible to reduce the number of vertices without changing the shape at all.  It's a question of how much change in the shape is allowable.

The attached PLDIET.lsp with its PLD command will reduce vertices.  [There are links for it in several places in this Forum, but downloads from the linked website are currently not working, so I attach it here.]  That means skipping over the locations of some vertices, so that line segments run between vertices that were not originally adjacent.  Fewer vertices means longer segments, and greater "kinkiness" in areas of "curvature."  Here are a couple of results for comparison, from a portion of the sample drawing, with different values for the maximum length to straighten in the PLD command:

How "distorted" are you willing to have your shapes become?

If you are looking to have portions like that turned into arc segments, PLD will not do that.  I couldn't say whether that could be automated, but it would be quite a challenge, if it's possible at all.

[The only way vertices can be removed in a Polyline of only line segments without changing the shape at all is when there are intermediate vertices along a stretch of collinear line segments.  PLD will remove those, anyway, regardless of your maximum-length setting.]

[AshRAECSolutions]

Kent, we appreciate your insights and agree that this particular aspect poses a challenge. handle lwpolyline object like  arc, as you pointed out, isn't something that PLD can handle. It's a nuanced task and could potentially be quite complex to automate.

[adelin_farcas]

Hey Kent!

Thank you for the insights, we already started to look into PLDiet and it is awesome that we understand it more now.

This is actually a feaseable solution:
- Joining with PEDIT the lines
- Overkill for all (so we don't have any 0 lenght lines)
- PLDiet
- Outline

We've seen great results with this approach, and we are basing our investigation on these findings. From my point of view it's a resolved solution, and I'm appreciative of all the explanations!

[david.waight]

I think you definitely need to get a cleaner .dxf file from the originator to make your life easier.

I haven't used this program myself but it looks like it might give you a much tidier file to work with.

https://tcicorp.com/curvefit/

They do a plug in for Autocad, as well as a standalone version

I tried using the BOUNDARY command (in a .dwg clone and not Autocad) and it managed to create a result similar to your final file, but obviously, it still suffers with far too many vectors.

I presume from the shapes this is a foam fitment which you will either be routing or waterjet cutting?

[adelin_farcas]

Hey David!

Exactly, this will be a foam fitment which will be used in waterjet cutting.

I understand that we would need a cleaner dxf. The only thing is that we're converting a drawn SVG to DXF with a 3rd part tool, which offeres us the DXF with interrupted lines. Afterwards we try to manipulate them so that the outline can be sent to waterjet.

[david.waight]

Hi Adelin,

I don't know what your 3rd party tool is or what created your .svg in the first place, but as a test, I drew a squiggle in Inkscape (free program whose native file format is .svg) and then exported it as a .dxf and a .pdf both from within Inkscape.

Both files were imported into my CAD program and after flattening the splines and exploding everything into lines and arcs everything that was originally curved (albeit now multiple shorter arcs) was still curved and the straight lines were lines.

Incidentally, the .pdf was lighter on its entity count than the .dxf.

Attached are the original Inkscape .svg and the resulting .dwg file.