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.

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

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.

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

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

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.

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

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.

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.

Piotr Rakowski pisze: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?

Piotr Rakowski pisze: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?