[piotrdz]

Ostatnio więcej dzieje sie na IRC niż na forum, więc daję tutaj parę wieści z frontu

Po skończeniu zasadniczej części silnika graficznego, przepisałem kod ładowania modeli. Napisałem też prosty program testowy do ładowania i oglądania modeli. Poniżej kilka screenów z działania.






Okazuje się, że w oryginalnym kodzie było ładowanie modeli w 4 formatach:
- DXF (tylko geometria)
- stary format binarny Colobota #1 (geometria + materiał + 1 tekstura)
- stary format binarny Colobota #2 (geometria + materiał + 1 tekstura + "tryb" wyświetlania)
- nowy format binarny Colobota (geometra + materiał + 2 tekstury + "tryb" wyświetlania)

Zapisywanie było tylko w nowym formacie binarnym Colobota i w zasadzie w grze wykorzystywany jest tylko nowy format binarny.

Było nieco problemów ze starym kodem, jak i formatem Colobota, m. in.:
- Było ograniczenie do 2000 wierzchołków na model -- już to zlikwidowałem, teraz może być do woli
- Druga tekstura jest na sztywno ustawiana na dirtyXX.tga
- Są ograniczenia na nazwy tekstur (końcówka .tga, do 19 znaków)
- Format TGA tekstur jest... no taki sobie -- zamiast RGB jak wszędzie, jest BGR. Proponuję zmianę na PNG.
- Format binarny nie jest przenośny. W szczególności zapisywanie wartości float binarnie. Najlepiej przerobić pliki na format tekstowy - modele zajmą nieco więcej, ale łatwiej będzie je wczytywać czy importować/eksportować do innych formatów. Niedługo napiszę skrypt, który automatycznie będzie przetwarzał format Colobota na taki tekstowy.

W związku z powyższym, proponuję, żeby wypowiedzieli się graficy (jeśli są tacy tutaj ). Trzeba ustalić, jaki format przyjąć, żeby wygodnie się nam pracowało.

A, i jeszcze jedno. Pozwólcie, że na razie pominę wczytywanie z metafile (.dat). Na razie łatwiej, choćby do debugowania, wczytywać modele z osobnych plików. (A nawiasem mówiąc metafile też nie jest przenośny).

[Raptor]

adiblol wspominał coś kiedyś o jakimś bezstratnym i otwartym formacie dla tekstur, jednak za nic nie mogę przypomnieć sobie, jaki był to format. Może był by on szybszy w dekompresji od PNG?

[Mrocza]

Odświeżony tga byłby dobry i zapewne byłoby mniej roboty niż zmiana na png ale może lepiej wybrać właśnie png. Możliwe jest wtedy nawet użycie 48-bitowej głębi koloru (64-bitowej przy RGBA) co daje fajną jakość bez żadnych zniekształceń. A jeżeli nie będzie potrzebna masa kolorów to można by w razie czego użyć skali szarości albo koloru indeksowanego żeby obciąć zbędne dane dla oszczędności. Kompresja też jest bardzo dobra.

[tomangelo]

A może tekstury zapisać jako grafikę wektorową?

[Raptor]

Nie znam się na grafice wektorowej, ale wydaje mi się, że można osiągnąć przez to gorszą wydajność od rastrowych.

[Madman07]

Najlepszy format dla tekstur to taki, w którym możecie dowolnie wybrać ilość kanałów. Naprawde. Trochę spędizłem czasu w tym i wiem, że czasami potrzeba RGB, RGB+A, RGB+A+A bądź nawet 3xRGB+A+A. Może i głupie, ale liczba tekstur na obiekt by się zmniejszyła
Swoją drogą, tekstury w PNG, czy TGA są cool. Zawsze możwcie uzyć otwartych bibliotek FreeImage (PNG+TGA+JPG+JPEG+jeszcze coś tam).

Co do modeli - tekstowy format jest fajny (np obj) ale wolniej się go ładuje. Najlepszy bedzie binarny + konwerter. W razie czego zawsze możecie się wzorować na 3ds, stosunkowo prosty i szeroko obsługiwany format (a i chyba otwarty, skoro sa wszelkie informacjie na wiki jak jest zbudowany).

[piotrdz]

Co do formatu tekstur, to napisałem, że TGA jest nieco głupie, bo SDL_image wcztyuje je jako RGB, a tworząc z tego teksturę muszę dać BGR niewiedzieć czemu. Z PNG nigdy nie miałem takich problemów - daję RGB i jest RGB.

A co do formatu modeli, zaproponowałem format tekstowy, bo tak łatwiej będzie konwertować jak nam się zachce w przyszłości. A inna sprawa to to, że graficy będą pewnie pracowali w swoim formacie, zależnie od tego, z czego będą korzystali (Blender?, 3dsmax?). W przypadku tekstowego formatu, mogę napisać prosty skrypt w awku lub perlu, który przekonwertuje jeden format tekstowy na inny. Z binarnym byłoby już trudniej. Binarny możemy przyjąć na końcu, kiedy będziemy już mieli ostatecznie zdefiniowane co i jak będzie w ostatecznym formacie modeli.

Na razie oczywiście zostawiam tak, jak jest - dyskusja jest bardziej o tym, co będzie później w Colobot 2.

[ Dodano: 31-08-2012, 21:53 ]
Forum oczywiście znowu dopisze to na końcu, nie wiem na ile widoczny będzie ten post.

Anyway, w kodzie CModelFile jest już zrobiony "na gotowo". Dodałem dwa nowe formaty modeli: binarny i tekstowy. Formaty zawierają praktycznie to samo, co poprzedni format binarny Colobota, ale zapisane w bardziej przejrzysty sposób.

Okazuje się, że format tekstowy jest jedynie niewiele większy od binarnego:
- wszystkie modele w starym formacie binarnym - 12 MB (spakowane zipem: 1.3 MB)
- wszystkie modele w nowym formacie tekstowym - 18 MB (spakowane zipem: 1.5 MB)

Proponuję więc na razie użycie formatu tekstowego, a w paczce końcowej - binarnego.
Niedługo zmienię też tak paczkę developerską - stary format binarny na nowy tekstowy.