Programy z korekcją średnicy narzędzia

• Cytuj
• Cytuj

#11

Post napisał: Piotr Rakowski » 11 mar 2011, 07:42

Nareszcie jakiś fajny temat na forum Offsety i clippingi to moja obsesja - ponieważ nie do końca umiem sobie z nimi poradzić. A co powiecie na krzywe? (np. sklejane lub Beziera). Czy któryś z Was "gryzł" już temat ich offsetu?

• Cytuj
• Cytuj

#12

Post napisał: prokopcio » 11 mar 2011, 08:45

• Cytuj
• Cytuj

#13

Post napisał: grg12 » 11 mar 2011, 18:30

Piotr Rakowski pisze:Nareszcie jakiś fajny temat na forum Offsety i clippingi to moja obsesja - ponieważ nie do końca umiem sobie z nimi poradzić. A co powiecie na krzywe? (np. sklejane lub Beziera). Czy któryś z Was "gryzł" już temat ich offsetu?

Zaimplementowałem "na chama" - podczas wczytywania rozkładam na proste odcinki i wszystkie następne operacje wykonuje na nich. Wyszedłem z założenia że skoro G-code nie wspiera splineów (a przynajmniej nic o tym nie wiem) więc w końcu i tak bym musiał podzielić na kawałki. Implementacja samych splineów okazała się zdumiewająco prosta - wystarczyły informacje z wikipedii (oczywiście ciężko mój dekoder uznać za specjalnie precyzyjny ale kształty które pokazuje mój program wyglądają bardzo podobnie do tego co widać w programie CAD generującym dxf - więcej nie wymagam).
W tej chwili próbuję zaimplementować dodawanie "łuków wejściowych" (nie wiem jak się to poprawnie nazywa - kawałek łuku po którym narzędzie "wjeżdża" na krzywą) - niestety z braku czasu robota idzie baaaardzo wolno. W dalszej perspektywie - automatyczne rozpoznawanie "wysp" - takich jak wewnętrzna pętla w literce "e" - żeby program podczas "wypełniania" automatycznie je omijał

• Cytuj
• Cytuj

#14

Post napisał: Piotr Rakowski » 12 mar 2011, 06:52

Ja robię tak samo. Zamieniam Beziera na wielobok (kwantyzacja) i dopiero robię offset. Jednakże po takim offsecie trudno jest już cokolwiek zrobić - pamiętajcie, że ja robię to na poziomie eduCADa (cncCADa), a więc każda ścieżka podlegać może jeszcze dalszym modyfikacjom. Z pewnością są metody na offset Beziera - vide Corel, czy Ilustrator. Są to tzw. metody heurystyczne (co by to nie znaczyło ). Tyle, że moja wiedza matematyczna tu się kończy...

• Cytuj
• Cytuj

#15

Post napisał: cosimo » 12 mar 2011, 08:11

Jak napisał cosimo - najwredniejsze są literki. Niektórych w prosty sposób nie da się "zapełnić" bo zawierają wewnętrzne elementy których nie można zamazać (np "e" poniżej) - trzeba analizować kolizje z już istniejącymi krzywymi.

O „wredności” czcionek pisałem trochę w innym kontekście. Chodziło mi krzyżowanie się kolejnych wektorów (patrz obrazek). Zjawisko to nagminnie występuje w literkach, które importuje jako HPGL – pewnie ze względu na ograniczoną rozdzielczość tego formatu – w DXF-ie to chyba zjawisko marginalne - i zastanawiam się czy też masz ten problem.

• Cytuj
• Cytuj

#16

Post napisał: prokopcio » 12 mar 2011, 08:52

• Cytuj
• Cytuj

#17

Post napisał: pitsa » 12 mar 2011, 08:58

Spróbuj zamiast "wektorów" przenosić punkty węzłowe linii przesuniętej na podstawie dwóch "wektorów"-odcinków i dopiero potem łączyć w odcinki.



Lewe wierzchołki prostokątów - stąd bierz współrzędne do wyliczenia przesunięcia.
Środek prawego boku prostokąta - tutaj wstaw punkt.

• Cytuj
• Cytuj

#18

Post napisał: prokopcio » 12 mar 2011, 09:49

• Cytuj
• Cytuj

#19

Post napisał: grg12 » 12 mar 2011, 12:13

Ja przenoszę całe wektory i łuki, sprawdzam jaki jest kąt pomiędzy następującymi po sobie elementami i jeśli jest otwarty dodaje łuk łączący (środek łuku zawsze wypada w punkcie łączący oryginalne wektory, promień jest równy offsetowi - pozostaje wyliczyć kąty). To załatwia problem elementów które podczas przesuwania ulegają "rozsunięciu" - pozostają segmenty które się krzyżują - te "załatwiam" w następnej fazie - podczas wielkiego cięcia "każdy z każdym" i usuwania śmiecia. Przy pierwszych próbach przecinałem tylko następujące po sobie elementy - ale szybko się okazało że to na nic - jeśli offset jest większy niż długość segmentu punkt "przecięcia" może wypaść poza "następnym" segmentem - czasem wypada w drugim z kolei, czasem w setnym. Szczególnie upierdliwe są pod tym względem spline (bo jeśli ustawić wysoką dokładność odwzorowania podczas kwantyzacji powstają tysiące króciutkich odcinków) i litery. Kolejny problem - figury z "przewężeniem" np. dwa duże okręgi połączone cienką "rurą" - przy offsecie większym niż połowa grubości rury rozpadają się kilka mniejszych figur. W załączniku mój zbiór figur testowych
Głowna wada tego rozwiązania to wymagana moc obliczeniowa - "wielkie cięcie" i późniejsze wyszukiwanie połączonych łańcuchów zajmuje sporo czasu.

• Cytuj
• Cytuj

#20

Post napisał: prokopcio » 12 mar 2011, 13:24

grg12 pisze:Przy pierwszych próbach przecinałem tylko następujące po sobie elementy - ale szybko się okazało że to na nic - jeśli offset jest większy niż długość segmentu punkt "przecięcia" może wypaść poza "następnym" segmentem - czasem wypada w drugim z kolei, czasem w setnym.

niestety nikt nie mówił, że życie programisty jest proste trzeba sprawdzać każdy z każdym i dodatkowo jeszcze z każdą krawędzią "oryginału" czy nie jesteśmy za blisko sąsiedniego detalu - zwłaszcza o innej korekcji bo nie możemy liczyć na to, że punkty przecięć ofsetów dadzą nam nowy prawidłowy punkt... i jeszcze wiele więcej warunków - podoba mi się bardzo uproszczony sposób "ścięcia" daleko wybiegających wierzchołków zastosowany przez cosimo, odpada problem kwantyzacji wycinka okręgu który może bardzo znacznie namnożyć tysiące mikroskopijnych odcinków, natomiast zmniejszając rozdzielczość można "uszkodzić" obrabiany wierzchołek... jednak to uproszczenia ma poważną wadę jaką jest znaczne spowolnienie obróbki ponieważ po "pseudo łuku" można przejechać znacznie szybciej niż po takim uproszczonym "łamaniu"... jednak sposób bardzo mi się podoba.

[ Dodano: 2011-03-12, 13:26 ]
a wszystko razem....

grg12 pisze:zajmuje sporo czasu.