Cholerka - rzeczywiście temat zmierza w kierunku takim, że chyba trzeba będzie założyć nowy wątek.

OK - piszemy w jednym wątku, ale szeroko.

Nie chodzi o to, że lustra nie mamy wbudowanego - bo rzeczywiście nie chciałem nawet tej możliwości w pierwszej wersji biblioteki wprowadzać, tylko przyponimam, że nie umawailiśmy się na lustra.

Podejrzewałem, że mniej więcej tak jest to (w sensie rozkłądu na wspólną krawędź) robione w Sigma Nest. A teraz mam jeszcze kilka dodatkowych pytań:

1. Oglądałem na Youtube kilka filmów przygotowanych przez autorów programu. Wszędzie, gdzie wykonywany jest jakiś nesting używają w zasadzie jednego "rodzaju" rozkładu, który nazwał bym "move-left-big-elements-first". Czyli zawsze duże elementy są układane, jako pierwsze, a małe wypełniają przestrzenie. Dlaczego włąśne ten algorytm? Czy on jest wg. Was najlepszy, nejefektywniejszy? - bo w mojej ocenie ten jest jedynie szybki...

2. Bardzo sprytnie pokazywane są rozkłady mega prostych elementów składających się z odcinków, łuków i otworów. A co ze splinami? Jak Sigma Nest radzi sobie z taką postacią zapisu? I jeśli radzi to jak, od razu kwantyzuje (przed rozkładem)?

3. Skoro masz wbudowany ten system ciącia na wspólną krawędź to jak zostaną wycięte identyczne kwadraty ułożone na płycie i dosunięte wspólnymi bokami?

Pytasz jak długo - od "pomysłu do pierwszych nestingów" nie minęło więcej, niż 3 miesiące. Do momentu pojawienia się 1-wersji skończonej biblioteki 1/2 roku.

Teraz właśnie testuję wersję 1.3, w której mam:

- pierwsze 8 algorytmów nestingu szczegółowego, na obszary ograniczone prostokątem albo DOWOLNYM WIELOBOKIEM (to o czym pisałem w tym drugim wątku) - te są bardziej efektywne, ale o "długim" czasie działania. Tych używałem do moich prób z tego wątku;

- drugie 8 algorytmów na wersję na obszary ograniczone jednym wymiarem np. szerokością, a nieograniczone drugim - o możliwie nieskończenie długim czasie działania - takie, jakimi chwalił się kol. Andryjan (pisał coś, że może ustalić, np. że rozkład ma trwać przez 20 minut) - te są o krótszym czasie działania (oczywiście, jeśli wszystkie elementy zmieszczą się już na układanym obszarze), ale za to efektywność może być mniejsza - używam ich np. do szybiego rozkładu "nieskomplikowanych" elementów, oraz rozkładu na długe "pasy" materiału.

Jak szybkiego? Na moim starym laptopie sprzed 4 lat (Celeron M) rozkład w sumie 100 elementów (6 różnych i zbudowanych nie tylko z prostokątów) na płycie 3000x1500 trwa 1 SEKUNDĘ!

Pozdrawiam, PR

No może pisałeś - nie zwróciłem uwagi.

Pozwoliłem sobie na taką zabawę - obróciłem obiekty wejściowe dokładnie tak, jak to zrobił Twój program i dopiero włączyłem nesting automatyczny. Mój algorytm 6 dał radę na polu 178x115 mm. Więc ciut lepiej, niż Twój.

Wyjaśnij mi, co rozumiesz przez wspólną linię cięcia? Chodzi o wspólną krawędź kilku obiektów? Jeśli tak to odpowiem że jeszcze nie. Jestem na wstępnym etapie tworzenia programu do nestingu. Tyle, że pamiętaj, że ja mam program typu CAD-Corel, do którego napisałem CAMa. Jeśli już to nesting będzie bez odsuwania obiektów o szerokość rzazu, a na etapie postprocesora - w trakcie tworzenia G-kodów (czy pliku ESSI) będzie włączane sprawdzanie, czy dany wektor został już wykonany, czy nie. Jeśli był - będzie pomijany.

Powiedz mi raczej czy program Sigma Nest ma wbudowane frog-jumpy?

Nooo - kol. Sigma-nest - jesteś trochę nie w porządku, bo umówiliśmy się na coś, a Ty tego nie dotrzymałeś! Obroty miały być najgęściej co 90 stopni, a Ty wrzuciłeś obroty dowolne! Tak więc ten przykład nie jest odzwierciedlający ustaleń.

Ja załączniki wrzucam na swój serwer i podlinkowuję. Najpewniejsze...

Mój algorytm nr 8 dał sobie radę nawet na polu 184x116 Wbrew oczekiwaniom obroty co 180 stopni zadziałały lepiej, niż co 90 stopni. Ciekawe...

Przeskalowałem całość tak, żeby litera T miała 44.98x55.29 (skala 108.542%).

Ułożenie tego na 190x108,62 było dla moich algorytmów niewykonalne. Mój najlepszy wynik to zmieszczenie wszystkiego na polu 185x119 mm. Dały radę 2 z 10 algorytmów.

Ja dałem 120x190 i 124x190 w moich przykładach.

Kol. Pitsa - ten zapis do DXF w Inkscape to porażka! Nie dość, że wszystko zapisywane jest w calach (obraz jest gigantyczny), to jeszcze wszystkie krzywie upraszcza do nieforemnych wieloboków.

Sprawdź plik nesting.dxf kolegi, który włączył się do wątku. Po wczytaniu jego wymiary są dokładnie takie, jakie podaje w poście. Stąd na nim bazowałem. Żebyś sprawdził, czy wymiary są zachowane: litera T ma wymiary po wczytaniu (około) 51x41,5 mm.

Na moich zrzutach są wersje uproszczone obiektów, bo mam do dyspozycji tylko starego Celerona i inaczej obliczenia trwałyby długo (rzędu kilka minut każda wersja układu).

Kol. Cosmio - mam nadzieję, że nic nie wycieknie, bo słono zapłaciłem za tę bibliotekę
Panowie - jej Twórcy - pracowali na moje zlecenie...

Twój "ręczny" nesting jest super, ale mam wrażenie, że pomagałeś trochę obiektom. Szczególnie te łuki są poobracane o niewielkie (i to różne) kąty. Takich rzeczy moje funkcje nie biorą pod uwagę. Maksymalnie (najgęściej) obroty co 90 stopni. Im więcej obrotów - tym więcej danych wejściowych i tym dłuższe operacje nestingu.

Niech się wypowiedzą przedstawiciele DUŻYCH firm od nestingu. Jakie możliwości mają SIGMA-NEST i np. Wrykrys?

Nie działałem na pliku SVG - nie mam możliwości zaimportowania go. Wziąłęm wersję udostępnioną przez kol. "jarbia" w pliku nesting.dxf.

Jak rozumiem układ miał być wykonany na polu 120x190? Takie 2 zrobiłem.

Wyniki poniżej (procent zajęcia powierzchni):



A jeśli układ jest zrobiony na 124x190 to zajęcie powierzchni spada do 56,5%.