prokopcio pisze: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...

Tak tylko dodam - okręgów nie kwantyzuję, tylko elipsy i spline. G-code obsługuje okręgi i łuki (oraz spirale) więc nie było takiej potrzeby.

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.

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ł

W swoim DXFKorniku zastosowałem rozwiązanie "siłowe" - na podstawie oryginalnej krzywej (złożonej z odcinków prostej i łuków) generuję przesuniętą krzywą dodając gdzie trzeba kawałki łuku (to czy są potrzebne oraz ich parametry można wyliczyć na podstawie kąta pomiędzy łączonymi fragmentami). Początkowo "krzywa" jest w strzępach a na dodatek zawiera sporo niepotrzebnych fragmentów. Następnie następuje przycinanie - każdy z każdym - i odrzucanie zbędnych segmentów na podstawie kąta przecięcie. Jeśli popatrzysz na wygenerowane odcinki zobaczysz że mają dwie strony - złą (położoną od strony oryginalnej krzywej) i dobrą. Wszystko co jest po "złej" stronie wylatuje a to co zostaje jest łączone w pętle (niektóre krzywe generują po "offsetowaniu" rozpadają się na kilka części).
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. Cały czas pracuję nad swoim programikiem a końca nie widać

prokopcio pisze:witam.
Kombinuję z interpolacją kołową na "szczytach" bo kiedyś widziałem coś podobnego w profesjonalnym programie ale wymiękam przy niektórych kształtach. Widzę, że kol. cosimo wybrał metodę o wiele prostszą i wg mnie bardzo słuszną - odpada wiele problemów jak np ustalanie rozdzielczości krzywej itp. wygląda imponująco i zastanowię się właśnie nad twoim rozwiązaniem bo wydaje się bardzo "ekonomiczne"...

Kiedy "interpolacja kołowa" jest dość prosta - zamiast wydłużać oryginalne linie i zastanawiać się gdzie się przetną przesówamy je o offset i łączymy końce kawałkiem okręgu (i tu się zaczynają schody bo trzeba się pozbyć niepotrzebnych fragmentów obwiedni)