Grafika bazy

Uwaga! Ta strona może zawierać nieaktualne już informacje o projektowaniu VMB z użyciem Python oraz Django CMS (jako początkowych założeń projektu). Obecnie VMB jest projektowane przez Drupal CMS, PHP, jQuery, itp. Informacja na ten temat.

Poniższy tekst został napisany przez kilka osób w formie wiki.

Grafika przedstawiająca bazę z zewnątrz i jej wnętrza powinna być staranna i atrakcyjna. Przykład: http://projekty.wm.com.pl/domy/036/036-aksonometria.jpg

// STOLLO:

Dla mnie git - przykład z aksonometrią bardzo dobry co do zasady. Grafikę chciałbym nawet bardziej rozbestwioną ;) Chodzi o to, żeby nie wyglądała jak prosty render z ArchiCAD'a ;)
Decydując się na aksonometrię a nie na widok "z góry" wchodzimy w problem z-bufora. Jeśli założymy, że Awatar ma być reprezentowany przez ludzika, nie zaś przez kropkę, ładujemy się w problem "co zakrywa co" podczas rysowania pomieszczenia. Nie możemy całkowicie zrezygnować z reprezentacji Awatara na planszy, bo nie będzie wiadomo kto jeszcze przebywa w tym samym pomieszczeniu. Powinni wypowiedzieć się graficy i programiści, czy z-bufor jest do zrealizowania. //stollo

Taki widok moze i jest fajny, ale raczej nie do zrobienia w gierce online w przegladarce. Mysle max tego co mozemy zrobic teraz (a to i tak nie bedzie super latwe) to widok 2d z gory, z prostym podzialem na pomieszczenia.


Ogolnie jak ja to widzę:

image mapa zrobiona w htmlu (im prostsza baza tym latwiej bedzie to zrobic), http://en.wikipedia.org/wiki/Image_map
// dokladnie, jestem za.

do tego jquery + css to zaznaczania pomiesczen i dodawania na mapie przedmiotow , cos w stylu tego : http://www.netzgesta.de/mapper/ i tego http://davidlynch.org/js/maphilight/docs/ .
// uhm, ciekawe.

na stronie gdzies widzialem taki plan widziany z gory, mysle nadalby sie na poczatek (i moze na dluzej) //slawek
// dokladnie, do pierwszych wersji makiety robimy w taki właśnie sposób.


Ale ładne wyrenderowane obrazki 3d to sa obrazki 2d z z pseudo 3d widokiem i mozemy je traktowac dokladnie tak samo jak zwykly obrazek 2d i nanosić na niego imege map html. Np. własnie na tego typu obrazku:
http://projekty.wm.com.pl/domy/036/036-aksonometria.jpg
My traktujemy to jak zwykły img, a gracz ma poczucie widoku 3d, a gra lepiej wygląda. // bartek

Abyśmy mogli łatwiej zrealizować to podejscie, które wydaje mi się bardziej atrakcyjne niż rzut z góry, to musimy się zdecydować na pewne uproszczenia:
1) wdoki ogólne, jak widok zewnętrznego obszaru oraz widok całej bazy, muszą być zrobione tylko w jednym rzucie, a nie po jednym dla każdej strony świata. Wówczas robimy tylko jedną mapę html, a nie 4. Bo do każdej strony świata musiała by być oddzielna mapa html. Zresztą widok całej bazy i tak może być zrobiony z góry (albo pod lekkim kątem z góry, żeby było widać 3d - będzie ładniej).

2) To samo musiało by się tyczyć widoków dla każdego pomieszczenia. Widok 3d, ale taki, żeby było widać wszystkie obiekty. Wówczas mamy do zrobinia tylko jedną mapę html dla każdego pomieszczenia.

Z powyższych założeń wynika, że musielibyśmy zrezygnować z wdoków z 4 stron N,S,E,W i zostać tylko przy jednym.
W przyszłości moglibyśmy zawsze rozwinąć widoki o kolejne strony świata.

Myślę, że dalibyśmy radę na jednym widoku.


// STOLLO:

Pytania i wątpliwości:

  • Jak będziemy renderować awatara w widoku pseudo-3D?
  • Co w przypadku, kiedy w jednym pomieszczeniu znajdować się będzie kilka awatarów?
  • Co ze sprzętem przenośnym? (zestawy typu narzędziowy, medyczny, geo itp.)
  • Czy nie lepiej byłoby od samego początku wprowadzić współrzędne i składać grafikę z layerów?
    • layer1 - render bazy/pomieszczenia jako tło dla przedmiotów/awatarów
    • layer2 - przedmioty/awatary najdalej w z-buforze (w/g współrzędnych)
    • ...
    • layerN - przedmioty/awatary najbliżej w z-buforze (w/g współrzędnych)
    • layerN+1 - render bazy/pomieszczenia zakrywający częściowo wszystkie layery poniżej niego.

      Podejście wymagałoby grafik z przezroczystością (PNG) po stronie serwera. Wynikowy plik mógłby być JPG-iem (biorąc pod uwagę problemy niektórych browserów z prawidłowym wyświetlaniem grafik PNG). Mapy musiałyby być tworzone dynamicznie, co - teoretycznie - nie powinno być problemem, biorąc pod uwagę, ze konkretny sprzęt/awatar ma konkretny wygląd (a więc i mapę), zaś współrzędne mapy można przepisywać ze współrzędnych obiektu w czasie renderowania poszczególnych layerów.

Widok pseudo-3D z całą pewnością byłby o niebo bardziej atrakcyjny wizualnie od widoku "z góry". Dla ułatwienia możemy przyjąć uproszczenie, że przedmioty w widokach nie będą skalowane wraz z oddalaniem od kamery (efekt długiej ogniskowej - spłaszczenie perspektywy bez wyraźnej różnicy w wielkości). Dodatkowo ułatwi nam to tworzenie map (w sensie html-owym).

Czy nie lepiej byłoby od samego początku wprowadzić współrzędne i składać grafikę z layerów?
Na to pytanie odpowiadam innym cytatem:
jquery + css to zaznaczania pomiesczen i dodawania na mapie przedmiotow

Współrzędne oraz warstwy (layers) mogą być realizowane własnie przez CSS:
Pozycjonowanie/Współrzędne: http://webmaster.helion.pl/kurshtml/style/pozyc_absolutne.htm
a dokładniej cecha: {position: absolute;}

Warstwy także przez CSS, czyli tzw. stos z-index: http://webmaster.helion.pl/kurshtml/style/stos.htm

Podejście wymagałoby grafik z przezroczystością (PNG) po stronie serwera. Wynikowy plik mógłby być JPG-iem (biorąc pod uwagę problemy niektórych browserów z prawidłowym wyświetlaniem grafik PNG). Mapy musiałyby być tworzone dynamicznie
To prawda, że w starszych wersjach niektórych przeglądarek, przeźroczysty .png jest źle wyświetlany. Jednak jeśli w wymaganiach do gry podamy minimalną wersje przeglądarek, jakie może mieć gracz, to problem z dynamicznym tworzeniem wynikowych obrazów .jpg mamy z głowy. Zresztą uważam, że i tak powinniśmy szukać innych rozwiązań niż tworzenie dynamicznie plików graficznych po stronie serwera - nie jest to ładne rozwiązanie.
Jeśli mielibyśmy nakładać na siebie warstwy, to .png jest dla mnie w chwili obecnej najlepszym rozwiązaniem.

...Mysle max tego co mozemy zrobic teraz (a to i tak nie bedzie super latwe) to widok 2d z gory, z prostym podzialem na pomieszczenia.
Widok z góry ma tą zaletę, że jest uniwersalny i nawet jeśli zrobimy widok z innej perspektywy, to widok z góry może być jako dodatkowy punkt widzenia. Będzie na nim widać dobrze wszystkie urządzenia i inne obiekty, także realizacja układu współrzędnych jest łatwiejsza w tym przypadku.
Widok z góry wyglądałby dużo bardziej atrakcyjnie, gdyby wprowadzić do niego iluzję 3d, poprzez oświetlenie i cienie. Jednak na początek wystarczy prosty widok 2d z góry, a jak dodamy iluzję 3d to układ współrzędnych i tak nam się nie zmieni, co jest ważne przy dalszym rozwoju.

Współrzędne oraz warstwy (layers) mogą być realizowane własnie przez CSS
Nie widzę tego... Raz, że interpretacja CSS bywa w przypadku niektórych przeglądarek zadziwiająca, dwa, że jeśli chcemy składać layery po stronie klienta, potrzeba będzie przesłać dużo większą ilość danych (bitmapy luzem) niż składając obrazek po stronie serwera.

[...] nie jest to ładne rozwiązanie.
Dlaczego? W moje ocenie mniej eleganckie będzie jak się warstwy rozjadą po stronie klienta.

$FM->Read("First_chapters"); w moim przypadku generuje błąd :D

Jeśli idzie o CSS z pozycjonowaniem elementów z użyciem: position: absolute, to przeglądarki radzą sobie z tym bardzo dobrze:
stos:
http://www.w3schools.com/Css/pr_pos_z-index.asp
http://www.smashingmagazine.com/2009/09/15/the-z-index-css-property-a-co...
pozycjonowanie:
http://www.w3schools.com/Css/pr_class_position.asp

jeśli chcemy składać layery po stronie klienta, potrzeba będzie przesłać dużo większą ilość danych (bitmapy luzem) niż składając obrazek po stronie serwera.

Nie sądzę, żeby przesyłanie małych obrazków było problemem. Być może powinniśmy przetestować oba rozwiązania w makiecie v0.2 albo v0.3.

Mamy więc, w tym momencie, dwie propozycje rozwiązania grafiki (przydadzą się jeszcze inne):
- Tworzenie widoków przy pomocy gotowych, generowanych na serwerze plików graficznych.
- Tworzenie widoków przy pomocy składania obrazu z mniejszych obrazów za pomocą CSS: z-index oraz position: relative.

Jeśli chodzi o tworzenie obrazków po stronie serwera, znasz może jakieś strony gdzie o tym piszą?

Nie sądzę, żeby przesyłanie małych obrazków było problemem.
Małych obrazków (awatary, przedmioty) nie, jednak trzeba pamiętać, że do przesłania jest zarówno "tło", jak i "pierwszy plan" pomieszczenia, a więc już dwa pełnowymiarowe obrazki, zamiast jednego kompozytu.

Być może powinniśmy przetestować oba rozwiązania w makiecie v0.2 albo v0.3.
Bardzo dobry pomysł.

Jeśli chodzi o tworzenie obrazków po stronie serwera, znasz może jakieś strony gdzie o tym piszą?
Dla PHP: http://www.php.net/manual/en/ref.image.php, a szczególnie funkcje imagecopymerge, imagecreatefrompng oraz imagejpeg lub imagepng.
Założę się, że Python ma również bardzo zacną bibliotekę do zabawy bitmapami. Niestety z Pythona jestem noga, nad czym ubolewam. Myślę, że jakiś z pytonowych modułów powinien ogarniać wszystkie potrzebne nam funkcje, bo tak na prawdę potrzebujemy tylko możliwości załadowania bitmapy do zmiennej, możliwości kopiowania bitmapy na bitmapę z uwzględnieniem przezroczystości oraz możliwości wyprowadzenia kompozytu do przeglądarki (ewentualnie na dysk serwera).

$FM->Read("First_chapters"); w moim przypadku generuje błąd :D

Widok z góry ma tą zaletę, że jest uniwersalny i nawet jeśli zrobimy widok z innej perspektywy, to widok z góry może być jako dodatkowy punkt widzenia.

Myślę, że w makiecie v0.2 moglibyśmy już potestować z grafiką, ale na widoku z góry.