Poprzedni temat «» Następny temat
Tworzenie 'Areas', czyli jak nie stracić wzroku.
Autor Wiadomość
Kinski 
Dziecię Bhaala
Zajebójca

Wiek: 38
Posty: 1364
Podziękowano 78 razy
Skąd: Białoruś
Wysłany: 2013-03-05, 15:10   

Za skomplikowane jak dla mnie. Ale przynajmniej dowiedziałem się dlaczego lokacje z Secret of Bone Hill tak choojowo wyglądają.

Cytat:
Search/light/height mapy są to po prostu bitmapy w trybie z paletą, oczywiście lądują one do override. By dużo nie zajmowały nie odpowiadają wielkości naszego obszaru tylko są zminimalizowane tak że 1 piksel odpowiada 16x12 piskli naszej mapy. To oznacza, że możemy ustalać typ terenu z dokładnością takiego prostokąta.


Nie da się w normalnym programie (GIMP, Photoshop) stworzyć poszczególnych plików w określonym rozmiarze i ich później połączyć w edytorze do tworzenia are?
_________________
Varscona.pl | Baldurs Gate - youtube | Children Of Bhaal - youtube | Twitch
Podziękuj autorowi tego posta
 
 
 
viader 

Wiek: 31
Posty: 71
Podziękowania: 15/12
Wysłany: 2013-03-05, 18:19   

Jasne, że się da, jednak jak pisałem ta bitmapa musiałaby być mniej więcej rozmiarów (x/16 , y/12), nie ma punktu porównania z obszarem, ponieważ bitmapa obszaru jest dużo większa (x,y)

Na chłopski rozum wystarczyłoby rozszerzyć w takim razie taką bitmapę(search mape) w edytorze do rozmiarów obszaru, a na koniec roboty zmniejszyć i gotowe :) To rozumowanie nie przewiduje jednak jaki algorytm wykorzystuje program do zmniejszenia i zwiększenia. Po prostu nie można być pewnym czy zadziała to, trzeba to sprawdzić.

Co do lokacji to wyglądają one tak ponieważ ktoś pewnie źle je narysował, nałożył tekstury na bitmapę, koniec kropka, każdy plik .bmp bez utraty jakości można zaimportować do gry i będzie wyglądał tak samo jak po otworzeniu w edytorze graficznym. Niedokładność o której wspomniałem ma skutek. O na przykład, że nie da się w BG dokładnie przechodzić tylko po linach chyba że są rozmiarów schodów - zawsze będzie można z niej zejść ponieważ jest dużo węższa od prostokąta 16x12

Można byłoby się zastanowić nad edytorem do map który byłby sprytnym edytorem, co to znaczy. W ogólnej postaci, graficznej nie różniłby się niczym od zwykłego wstawiania tekstur jak w edytorze HoMM. Ale dodatkowo z każdą teksturą byłby związany poligon i miejsca po których nie można chodzić, my wstawiamy tekstury, a on dostawia poligony i mniej więcej generuje search mapę. Czyli my nawet tego nawet nie widzimy, ustawiamy tylko drzewka, kamyki na planszy, a edytor w tyle odwala całą robotę. Stworzenie takiego czegoś to raczej nie problem, większym problemem jest zebranie bazy danych, czyli w tym przypadku całej masy takich trójzestwów (tekstura, poligon, coś od search mapy). Poligon z gry można wziąść, tego od szerach mapy nie jestem pewny, a tekstury wymagałaby kadrowania. To już dla jednej osoby byłaby katorga. To tak mimochodem co do pomysłu edytora mapek :), chyba zapędzam się zadaleko, jeszcze tylko dam program do poligonów...
Podziękuj autorowi tego posta
 
 
L`f 
Uczeń Gonda


Wiek: 27
Posty: 1381
Podziękowania: 290/154
Wysłany: 2013-03-05, 20:13   

viader napisał/a:
W ogólnej postaci, graficznej nie różniłby się niczym od zwykłego wstawiania tekstur jak w edytorze HoMM. Ale dodatkowo z każdą teksturą byłby związany poligon i miejsca po których nie można chodzić, my wstawiamy tekstury, a on dostawia poligony i mniej więcej generuje search mapę.

Warto tutaj jeszcze wspomnieć o jednej ważnej kwestii, która w obszarach z wielu modów jest pominięta - cienie. To właśnie ich brak w dużej mierze sprawia, że dodatkowe lokacje wyglądają wyjątkowo sztucznie w porównaniu do oryginalnych - widać, które elementy zostały zwyczajnie wklejone na tekstury tła. Przypominam sobie, że z modów z większą ilością obszarów, których zasoby przeglądałem, zwłaszcza SoBH i FfT miały problem z takimi 'wklejkami'.

Sam cień można by było w miarę łatwo zaimplmentować (jako część warstwy z kanałem alfa, pod koniec tworzenia obszaru i tak wszystko by się spłaszczało do *.bmp). O odpowiednią głębię kolorów też nie trzeba się martwić - przy wczytywaniu bitmapy do DLTCEP-a program automatycznie indeksuje kolory do głębi ośmiobitowej w każdym tile'u 64x64 (każdy 'kafelek' ma osobną paletę). Większy problem sprawiłoby na pewno ujednolicenie kierunku cieni, zwłaszcza przy niestandardowych elementów, żeby cały obszar wyglądał naturalnie - może być to kłopotliwe zwłaszcza przy tworzeniu dużej bazy nowych elementów. Warto też pamiętać, że cienie nie zawsze układają się płasko - to, zwłaszcza w obszarach stylizowanych na BG2, byłoby chyba największą trudnością do przejścia (o ile w ogóle byłoby możliwe rozwiązanie tego problemu bez użycia odpowiednich modeli 3D).
_________________
AshfncaeicaliuheangfkacgakfgegcalgfcalhfcamhlhKi~.!
Podziękuj autorowi tego posta
 
 
 
Kinski 
Dziecię Bhaala
Zajebójca

Wiek: 38
Posty: 1364
Podziękowano 78 razy
Skąd: Białoruś
Wysłany: 2013-03-05, 21:50   

viader napisał/a:
Trudno opisać w skrócie to jak to wygląda bo po prostu w pliku .are są wszystkie dane obszaru: skrypty, aktorzy, wejścia, pojemniki, odgłosy, spawn potworów, pułapki info punkty i tak dalej...


Cytat:
Nie da się w normalnym programie (GIMP, Photoshop) stworzyć poszczególnych plików w określonym rozmiarze i ich później połączyć w edytorze do tworzenia are?

Nie wyjaśniłem. Chodzi mi tylko o aspekt graficzny. Skrypty, postaci, odgłosy, pojemniki, wejścia, spawny da się dodać później (na filmie w DLTCP są zakładki do nich). Ale samą bazą jest plik graficzny ->

Cytat:
Do tego trzeba "tylko" zaimportować bitmapę na warstwę główną(WED), zaznaczyć ściany(WED), zaznaczyć dwie flagi(ARE), oraz wypełnić sensownie search mapę(ARE) i można przenieść się konsolą do czystego obszaru.


Czy nie da się poszczególnych plików (WED, WED, ARE, ARE) stworzyć oddzielnie w programie (Phostoshop, GIMP i in.) po czym połączyć w DLTCP? To samo dotyczy poligonów i search map", bo przecież "Search/light/height mapy są to po prostu bitmapy w trybie z paletą". Dotyczy to też cieni. Chodzi o ominięcie procesu zaznaczania niektórych elementów (poligonów, search map). Ostatecznie plik lokacji składałoby się jak kanapkę - po kolei poszczególne warstwy.
Czy każdy z tych plików (WED, WED, ARE, ARE, cienie, poligony itd.) to bitmapa (na filmach importowane są bmp)? Ewentualnie warstwa z zaznaczoną przezroczystością? Jak to wygląda technicznie? Z filmów odnoszę wrażenie, że to bitmapy z ustawionymi paletami 8 bit), gdzie gra interpretuje niektóre kolory jako poligony, cienie, tło (ta zieleń?).
_________________
Varscona.pl | Baldurs Gate - youtube | Children Of Bhaal - youtube | Twitch
Podziękuj autorowi tego posta
 
 
 
viader 

Wiek: 31
Posty: 71
Podziękowania: 15/12
Wysłany: 2013-03-06, 07:17   

Co do dynamicznych cieni to sprawa nie jest taka łatwa ponieważ wszędzie jest rzut izometryczny i różne położenie źródła światła. Można to jednak uprościć tak, że dodatkowo do tekstury byłby plik graficzny z różnymi cieniami, gdy jest kontur na przezroczystym tle, to można z algorytmu cały obszar konturu wypełnić mniej więcej odpowiednikiem koloru cienia na light mapie. Czyli widziałbym to tak, ktoś potrzebuje nowy cień, wrzuca do Gimpa teksturę, dodaje ręcznie cień na oddzielnej warstwie, wrzuca do katalogu, zapisuje warstwę i ma kolejny cień do tekstury. Czyli przy ładowaniu teksturki, musiałoby się pojawiać okno wyboru cienia do niej, jeżeli cieni byłoby więcej niż 1.

@Kinski
Na filmiku tworzyłem tylko search mape, to zielone odpowiadalo trawie/mozna_chodzic to czerwone odpowiadalo blokowi_przez_ktory_nie_mozna_chodzic
Analogicznie tworzyłoby się light_mape i height_mape, kolory oznaczałyby by tylko inne rzeczy.

Tak, tak da się i to bez problemu. Taka najlepsza i największa kanapka by musiała się składać z:

nasza mapka (to co widać w grze) - 1 bitmapa - tryb RGB
search mapa - 1 bitmapa tryb - kolor indeksowany;
light mapa - 1 bitmapa tryb - kolor indeksowany;
height mapa - 1 bitmapa tryb - kolor indeksowany;
poligony - 1 plik .svg

To daje nam 5 warstw i mamy praktycznie cały aspekt graficzny w jednym pliku/edytorze, oczywiście by to działało na końcu w grze, trzeba byłoby zapisać oddzielnie warstwy do poszczególnych plików i użyć choćby mojej wtyczki. Takie rozwiązanie jest chyba fajne :).

PS: Co do tworzenia cieni na podstawie tekstury, to wydaje mi się, że lepsze edytory np Photoshop mają opcje rzutowania tekstury w 3 wymiarach, czym można byłoby teoretycznie szybko cienie trzaskać.
Podziękuj autorowi tego posta
 
 
viader 

Wiek: 31
Posty: 71
Podziękowania: 15/12
Wysłany: 2013-04-25, 10:09   

Chciałbym zwrócić się o pewną pomoc, ponieważ temat ten już mnie drażni. Zrobiłem program, który zamienia svg->wed i jedna osoba zaczęła to testować. Było tak, zaraz wyszło, że jej nie działa, dobra szukam błędu robię poprawki, jej dalej nie działa i tak w kółko. Najgorzej, że mi działa program bez zarzutu i już zaczynam się zastanawiać czy nie działa tej osobie bo program rzeczywiście skopany, czy dlatego, że ona popełnia błąd. Dochodząc do sedna chciałbym by ktoś przetestował program.

Tutaj są 2 programy, jeden działa bez zarzutu
https://dl.dropboxusercontent.com/u/87796468/work.rar

Lista rzeczy do zrobienia:
1. wyeksportowanie .wed z dowolnie działającej mapy.
2. wrzucenie .wed do katalogu from_wed
3. uruchomienie from_wed.exe - powstanie nowy plik z rozszerzeniem .svg
4. zedytowanie svg, w takim stopniu by było widać zmiany w rozmieszczeniu poligonów
5. wrzucenie .wed i .svg do katalogu to_wed
6. uruchomienie to_wed.exe, wpisanie nazwy .svg i nazwy .wed
7. nowy .wed powstanie w katalogu /out z taką samą nazwą jak podaliśmy wyżej

Teraz sposobem jak kto woli, sprawdzić czy nowo powstały .wed jest poprawny, wszystkie drzwi są, wszystkie poligony i tak dalej. Wykonując tą listę kroków, nakręciłem filmik w tragicznej rozdzielczości za co przepraszam.
https://dl.dropboxusercontent.com/u/87796468/to_wed.rar

Za pomoc będę dozgonnie wdzięczny.
Podziękuj autorowi tego posta
 
 
dradiel 
Dziecię Bhaala
Jeździec Shaundakula

Posty: 1595
Podziękowania: 750/107
Wysłany: 2013-04-25, 19:16   

Temat interesuje mnie tak trochę przyszłościowo, więc na razie szczegółowo wgłębiał się w niego nie będę.
Zrobiłem to o co poprosiłeś: wyeksportowałem, poedytowałem trochę w inkscape i spowrotem zapisałem do weda.
Dodane, istniejące lub te zmienione przeze mnie poligony zapisały się poprawnie, ale tylko poligony. Gra się uruchamia na takim pliku, ale od razu rzucił mi się w oczy inny problem, więc zrobiłem ponownie wszystko, ale już bez edytowania, w celu porównania obu wedów (przed i po):
1. Wszystkie drzwi ustawiły się w pozycji otwarte i przestały działać. Porównując pliki .wed widzę, że eksport svg --> wed nie ustawia poprawnie tilesetów
2. Postać schowana za obiektem jest wyświetlana normalnie, jakby była przed nim. Z porównania wynika, że nie poprawnie ustawiane są flagi poligonu. Eksport do .wed w większości przypadków ustawia wszystkie osiem bitów oraz boundix box ma dziwne wartości, nie mające wiele wspólnego z poligonem, którego dotyczy.

Nie wiem jakie problemy ma ten ktoś, kto robił testy a o którym piszesz. Takie same?

Edit:
3. Zauważyłem jeszcze, że po eksporcie do weda wszystkie pozycje wall group zostały wyzerowane a wall polygon index usunięte.
http://iesdp.gibberlings3...ts/wed_v1.3.htm
Podziękuj autorowi tego posta
 
 
Więcej szczegółów
Za tę wypowiedź podziękowali:
viader
viader 

Wiek: 31
Posty: 71
Podziękowania: 15/12
Wysłany: 2013-04-26, 07:47   

Dzięki wielkie! Tyle mi było trzeba, dowiedziałem się nawet więcej niż oczekiwałem :) Osoba robiąca testy, za nic nie mogła otworzyć .wed w jakimś edytorze, dołujące... Wszystkie błędy poprawione, same drobne pomyłki, ale za to czym skutkowały.

Pokolei:
1. Tilemapy od drzwi, pomylona nazwa zmiennej zamiast tile_index dałem index.

2. Boundix box, pomylona kolejność przy wczytywaniu poligonów: było min_x,min_y,max_x,max_y, a nie min_x,max_x,min_y,max_y;

3. Flagi ustawione przy poligonach są poprawnie, przynajmniej w 3 edytorach podglądałem i porównywałem przez dość długi czas.

Teraz, dlaczego postać pojawia się przed poligonem, chociaż poligon ma wszystko dobrze ustawione. Odpowiedzialne są za to wallgroupy, które specjalnie zerowałem. Zapomniałem o tym wspomnieć, trzeba otworzyć .wed w DLTCEP i zapisać, tak by poustawiał wszystkie wallgroupy.

Ostatnia rzecz jaka mi pozostała to od razu wypisywanie poprawnych wallgroup tak by nikt nie musiał sięgać do DLTCEP. Dzisiaj się za to wezmę.

Poprawka
https://dl.dropboxusercontent.com/u/87796468/to_wed_1.1.zip
Podziękuj autorowi tego posta
 
 
viader 

Wiek: 31
Posty: 71
Podziękowania: 15/12
Wysłany: 2013-06-04, 12:06   

Kolejna rzecz której zaczynam nienawidzić, dodawanie drzwi w DLTCEP - a raczej dodatkowych tilesetów, niby wszystko fajnie, póki jest mała area a drzwi jedne na lokacje. Teraz mam większy obszar, z 5 drzwi, na dzień i na noc dodatkowo z oświetleniem. I jeszcze do tego przy każdej poprawce obszaru od Selendisa muszę wszystko od nowa zaczynać...

Operacja z nie wiem już którą wersją DLTCEP
eksport pojedynczych kwadratów do .bmp (do .tis się nie da)
otworzenie każdego kwadracika w edytorze - bo DLTCEP umie zapisać a przeczytać siebie niezbyt
zapisanie kwadracika w edytorze
wczytanie każdego kwadracika do DLTCEP
zapisanie jako tis - da się podmieniać tylko .tisy
otworzenie .area i końcowa podmiana

Kwadracików 60, a nie daj boże by coś się po drodze nie popsuło...
Podziękuj autorowi tego posta
 
 
Hathor 
Sirielle Ontalómë


Posty: 524
Podziękowania: 1/14
Skąd: Himring, Arda
Wysłany: 2018-02-12, 00:56   

Odpowiedź po latach, może się komuś przyda. Dodawanie drzwi jest chyba prostsze w IETME, sama muszę sobie przypomnieć - tutorial:
http://www.shsforums.net/...class-tutorial/

viader napisał/a:
Taki screen jeszcze z roboty, tworzenie poligonów w Inkscape zajęło mi 1,5 godziny, ale poszło by szybciej gdybym skorzystał z jakiejś bazy kształtów drzewek lub z gry powyciągał

Nie zaglądałam tu wtedy, by odpisać na czas, ale może przyda się innym - te drzewka są w gotowcach do IETME. Z nich można zebrać kształty, jak ktoś chce działać w ten sposób. Chociaż mi się wydaje, że to zbyt skomplikowany pomysł, nie musi być zaznaczona każda gałązka, bo w grze i tak tego nie widać.

Ważne, by często zapisywać bo IETME się wywala co trochę. Ktoś też zalecał, by kolejne wersje mapy zapisywać w osobnych folderach - na wypadek gdyby IETME zapisał pliki z błędem. Rzeczywiście zdarza mu się, więc warto mieć kilka kopii. U mnie często psuje search/light/height mapy, co poprawiam w Photoshopie. Też myślałam czy nie zaznaczyć sobie ich kolorami na dużej mapie i nie zmniejszyć, używając kolorów z oryginalnej mapy, ale ostatecznie zostaję przy IETME.

Kinski napisał/a:
Przede wszystkim trzeba by stworzyć bazę obiektów. Tak jak jest w HoMM - drzewa, krzaki, lasy, skały itd.

Taka baza już jest zaczęta - masa obiektów wycięta z BG/IwD. Nie pamiętam czy są w IETME, czy trzeba je ściągnąć osobno, ale są osiągalne. W IETME mozna też zaznaczyć i eksportować elementy jako BMP, aczkolwiek by to dokładnie wyczyścić potrzebny będzie program graficzny.

Tak czy inaczej taki edytor jak w HoMM byłby świetny, o ile dałoby się do niego dodawać własne elementy. Do HoMM 3 niby można (są modyfikacje), ale dla mnie nie tak prosto, jak w przypadku gier IE. Może dlatego, że łatwiej mi robić obrazki, niż kodować cokolwiek, a w IETME się "rysuje" ;)

L`f napisał/a:
Warto tutaj jeszcze wspomnieć o jednej ważnej kwestii, która w obszarach z wielu modów jest pominięta - cienie. To właśnie ich brak w dużej mierze sprawia, że dodatkowe lokacje wyglądają wyjątkowo sztucznie w porównaniu do oryginalnych - widać, które elementy zostały zwyczajnie wklejone na tekstury tła.


Cienie można rysować w IETME, chociaż ja wolę w Photoshopie. Może nie z taką precyzją, jak opisujecie, ale da radę. By były spójne trzeba je dopasować do mapy bazowej z gry, która będzie podstawą przy mapie sklejanej z elementów z gier. Najlepiej użyć oryginalnej grafiki jako bazy do takiej foto-manipulacji. Co innego jak ktoś robi całość w 3D albo rysuje ręcznie. Są jakieś mapy w modach rysowane ręcznie? I jeszcze trzeba zerknąć w jakim kierunku idą cienie postaci, żeby nie zrobić odwrotnie ;) Jak zerkniecie na oryginalne mapy z BG1 też bywa, że nie wszystkie obiekty mają cienie i nie zawsze idą we właściwym kierunku. W BG2 w ogóle są chyba pod innym kątem/odbite lustrzanie w stosunku do BG1.

Tree 07.bmp
Plik ściągnięto 1120 raz(y) 158,54 KB

  
Podziękuj autorce tego posta
 
 
Wyświetl posty z ostatnich:   
Odpowiedz do tematu
Nie możesz pisać nowych tematów
Nie możesz odpowiadać w tematach
Nie możesz zmieniać swoich postów
Nie możesz usuwać swoich postów
Nie możesz głosować w ankietach
Nie możesz załączać plików na tym forum
Możesz ściągać załączniki na tym forum
Dodaj temat do Ulubionych
Wersja do druku

Skocz do:  
Powered by phpBB modified by Przemo © 2003 phpBB Group