[vegelus]

Rozumie ze chodzi o nadawanie przestrzeni BMP
To mi ulecialo z glowy

Co do wymagan systemowych to czmu az Win2000 potrzeba ja pracuje na 98 i jakos nie kwapie sie do przejscia na cos lepszego dopuki nie wymienie kompa. No i jeszcze pozostaje linux.

[anjak]

a to pech z tą w98 , a bmp jest też mi potrzebne

[Piroman1024]

Witam.
Ja również chciałbym coś dodać od siebie do tego projektu o ile to mozliwe.
Mogę coś zrobić w:
-Delphi(Coś do programu głównego)
-OpenGl(wizualizacje)
-GCC na AVR

Czytałem czły wątek jednak nie jestem pewien jakie są założenia ostateczne co do języku programowania.
Z tego co wiem program główny powinien chodzić zarówno pod Windows jak i Linuks.
Pozdrawiam.

[vegelus]

No wszyscy sie uparli na C++ wiec siedze i czytam
Co do wizualizacji to mysle ze moze nam cos wyjsc bardzo fajnego gdyz kilku ludzi juz jest

Napisz moze co chcialbyc i w jaki sposob wizualizowac. Jak nie ma nic napisane to nie ma jak dyskutowac. A jak nie ma dyskusji to nie ma kolejnych krokow do przodu a jak ich nie ma to projekt stoi. A jak projekt stoi to ladachwila moze sie przewrocic . Choc niezupelnie bo z tego co sie oretuje to i tak kilka programow jest w trakcie pisania

[anjak]

Piroman1024, podaj swoje GG/TLEN lub kliknij na moje.
Czy jest ktoś jeszcze kto chce zająć się wyłącznie opengl ?
Wiadomość proszę na maila lub GG

[Piotr Rakowski]

Jak wiecie popełniłem właśnie swój pierwszy program sterujący STEP2CNC więc pozwolę sobie wtrącić swoje 3 grosze. Wczytywanie formatu CDR nie jest dobrym pomysłem z dwóch powodów:

1. format nie jest udostępniony publicznie przez firmę COREL Corp. i można się narazić na niepotrzebne nieprzyjemności,
2. zawiera wiele niepotrzebnych śmieci, których interpretacja będzie niepotrzebnie skomplikowana (w końcu są tam informacje o ustwaieniach programu i obiektach zaimpotowanych - np. bitmapach).

Program Corel pięknie eksportuje do HPGLa i ina tym możecie się operzeć.

Zdecydowanie polecam zrobić interpretację plików IGES i STL - stworzonych specjalnie do zapisu i interpretacji ścieżek modeli 3D.

[Wodzu]

Ja tez jestem za tym zebyscie pracowali nad Igies, parasolid itp. Praktycznie kazdy program jest w stanie sobie poradzic z tymi plikami.

[triera]

wczoraj sprawdzałem jak pięknie eksportuje się hpgl z Corel11
- zmiana wymiaru 1000/1016 = 0,9842519685% wymiaru zadanego
(w porównaniu z CorelDraw9)
zmiana parametrów przy eksporcie:
skalowanie (nawet 200%) i ilości jednostek
nie pomogło - zmian nie zaobserwowano.
Na szczęście mogłem wprowadzić korektę na poziomie
interpretera HPGL.

[Piotr Rakowski]

Dlatego właśnie jeśli swoje działania chcecie oprzeć na programach typu Corel to polegniecie.
Jasne, że jest najpopularniejszy - ale to niczego nie dowodzi. Trzeba sprawdzić jeszcze, jak eksportuje do DXF, bo do WMF też eksportuje "podobnie".

Możecie się przyjżeć bliżej formatowi WMF - bo to "natywny" format Windozy i większość programów wektorowych i CADowskich bez problemu sobie z nim radzi. Ba, Windoza obsługuje schowek w formacie WMF - więc przenosznie przez clipboard jest bardzo proste.

[x]

1. format nie jest udostępniony publicznie przez firmę COREL Corp. i można się narazić na niepotrzebne nieprzyjemności,
2. zawiera wiele niepotrzebnych śmieci, których interpretacja będzie niepotrzebnie skomplikowana (w końcu są tam informacje o ustwaieniach programu i obiektach zaimpotowanych - np. bitmapach).

A znasz jakieś "nieoficjalne" specyfikacje? Latem 2005 nie znalazłszy żadnej pożytecznej dokumentacji rozgryzałem CDR i doszedłem do wnosku, że to może się udać, ale dałem za wygraną przez pliki skompresowane. Prawdopodobnie to jest kompresja Huffmana, ale jak odzyskać drzewo kompresji?

Zdecydowanie polecam zrobić interpretację plików IGES i STL - stworzonych specjalnie do zapisu i interpretacji ścieżek modeli 3D.

STL jest fajny (tylko strasznie dużo dysku zajmuje). DXF v.12 też jest O.K. ale ten format został niestety znacznie "ulepszony" - pdf z opisem najnowszej wersji to cała cegła, większość danych to dla generatora G-kodu śmieci.

No niestety wygląda że projekt zdechł w przedbiegu. Sam mam kilka programów (głównie C++), które utknęły w martwym punkcie. Wina - nadmierne rozbudowanie projektu. Ilość czasu potrzebna do pisania programu rośnie wykładniczo do ilości klas i metod. Teraz staram się działać w duchu weekend-hack ( w rzeczywistości month-hack ).

FLTK ma własne środowisko FLUID do budowania interfejsu, i szkieletu programu w C++. Toporne, ale działa.

Gdyby jeszcze ktoś chciał się bawić, to proponuję pisanie w języku skryptowym - np. Python-ie. Znacznie mniej pracochłonne, szybko widać efekty pracy. Jest wiele modułów, w tym toolkity okienkowe, coś do OpenGL. Działa to i pod Win i pod Lin. Sceptycznie nastawionym mogę powiedzieć, że to wcale nie jest takie głupie. Np. interfejs programu ac3d jest robiony w Tcl/TK (wbudowany interpreter). EMC2 pracujący przecież w reżimie czasu rzeczywistego, także ma interfejsy do wyboru m.in. w TCL, i Python-ie. Te 20% kodu który zajmuje większość czasu procesora można później przepisać w C, i dalej używać jako moduł Python-a.

I zdecydowanie zminimalizować zakładaną ilość właściwości, oraz wybrać lidera który wskaże kierunek, i odwali z 10% roboty. A na starcie 150%.

Do czego ten program właściwie ma służyć? Do modelowania? Wczytywania gotowców i przetwarzania na G-code? Komunikacji z modułem wykonawczym? I przy okazji jeszcze wizualizacja i symulacja?