Żeby tworzenie misji nie zjadało całego życia, bądź nie wypalało po serii frustrujących doświadczeń z Dromedem, fandom Thiefa potrzebuje nowego edytora. Pisałem już o tym kilka lat temu:
https://www.ttlg.com/forums/showthread. ... MIS+format
Poziom entuzjazmu - możecie sobie wyobrazić bez czytania.

Oczywiście jest to przedsięwzięcie potężne, szczególnie dla osób dłubiących hobbystycznie po godzinach, ale nie niemożliwe. Jeśli umiecie programować i kręci Was geometria 3D, to dajcie znać, jakby co. Póki co, drążę temat samotnie, w ślimaczym tempie...

A nie lepiej by było przeportować T2 na jakiś otwarty współczesny silnik z gotowymi narzędziami? Ktoś już się zajął przenoszeniem Thiefa na Unity: https://ibb.co/B6HBYjG

Do tego Unity ma dostać bardzo wszechstronny zestaw narzędzi do dziergania BSP: https://www.youtube.com/watch?v=ugjXKbFWX4Q

Może dałoby się to jakoś połączyć?

_________________
Builder Compound Asset Pack – models and textures for TDM

Co to znaczy że drążysz temat? Masz już jakieś przymiarki w postaci kodu?



Ktoś już dawno temu również zaczął przenoszenie Thiefa na Ogre3D:

https://github.com/volca02/openDarkEngine/

Nawet swego czasu rozważałem wejście do projektu i udało mi się skompilować i uruchomić całość:

https://github.com/ktalik/openDarkEngin ... t-41424672

To zmotywowało maintainera do utworzenia ładnej listy tasków:
https://github.com/volca02/openDarkEngine/issues

Niestety prace szybko porzuciłem ze względu na brak czasu. Teraz wygląda na to, że czasu jest trochę więcej. Gdyby ktoś chciał dołączyć do prac, moglibyśmy od nowa razem to rozgryźć i zobaczyć co dalej z tym da się zrobić.

Proszę moda o przeniesienie dyskusji do nowego wątku

Pamiętam to co robił Volca, szkoda że to utknęło w miejscu. Nowy edytor mógłby przyciągnąć kolejnych mapperów. Ale do takich inicjatyw rzeczywiście potrzeba zespołu.

_________________
Builder Compound Asset Pack – models and textures for TDM

Masz może źródło tego obrazka? Jestem ciekaw, czy ktoś faktycznie zaimportował geometrie tego levelu do Unity bezpośrednio z pliku .MIS, czy to po prostu zaimportowany .obj. Sądząc po nazwie grupy 'wr_export', skłaniam się ku tej drugiej opcji, ponieważ nowy Dromed ma komendę wr_export_obj, która zapisuje teren levelu jako model obj.
Takie coś to jest przysłowiowe 5 minut roboty.

Ja kiedyś napisałem skrypt do 3dsmax, który importował worldrep wraz z teksturami i światłami. (UV'ki trochę nie grały, ale nigdy tego nie poprawiłem). Idea była taka, żeby spróbować wypalić lepsze lightmapy w 3dsmax'ie, ale jak to się mówi - apetyt zaczął rosnąć wraz z jedzeniem i tak po mału ewoluował pomysł utworzenia pełnoprawnego edytora.

Co do Unity - tak, aktualnie jest to jedna z dwóch głównych opcji, które rozważam. Pierwsze przymiarki już zrobiłem, ale rzeczywistość nie jest taka różowa. Po pierwsze, nie wierzę, że gdyby utworzyć narzędzia rozszerzające Unity, ludzie by byli zainteresowani używaniem tego edytora do pracy nad fanmisjami. Unity sam w sobie jest wystarczająco skomplikowany, a dodatkowo uczyć się customowych narzędzi dla NewDarka i nie mylić ich z natywnymi - to za dużo dla nowicjuszy bądź hobbystów. Jeśli już, to potrzebny jest dedykowany edytor, który ma tylko tyle opcji, ile jest potrzebnych.
Dlatego mój pomysł jest taki (jedna z opcji), żeby utworzyć edytor za pomocą Unity, tak jakby to była "gra". Ale taka opcja, choć brzmi fajnie, to otwiera znowu puszkę pandory, ponieważ wiele rozwiązań, które dziala w edytorze, nie działa w runtime - np. wypalanie lightmap. Tak samo ładowanie tekstur - w runtime'ie Unity potrafi ładować tylko jpg i bodajże png i chyba ddsy za pomocą nieudokumentowanych funkcji. Importer formatów takich jak gif, pcx, tga trzeba by napisać samemu.
Do tego cały UI by trzeba pisać od nowa - zadanie tyleż ekscytujące, co strasznie skomplikowane i mające znamiona odkrywania Ameryki.
A najważniejsze, to to, że architektura silnika Unity jest zgoła inna od architektury dark engine'u, a więc ciągle trzeba by naginać jeden silnik do symulacji innego i de facto wiele systemów by trzeba napisać od nowa, np. obsługę bsp i portali do ukrywania niewidocznych fragmentów mapy.

Dlatego też rozważam napisanie edytora w jakimś frameworku typu Qt, który da mi solidny UI i musiałbym 'tylko' napisać renderer od podstaw. Ale tu się kłania C++ i OpenGL bądź DirectX, w czym na tą chwilę nie mam doświadczenia.

Pełny port - czyli coś takiego jak OPDE moim zdaniem nie ma sensu. Bo zaprzęgać Unity i akceptować ciągle ograniczenia typu brak bardziej zaawansowanych animacji czy staroświecka fizyka... Wprowadzanie nowocześniejszych rozwiązań z kolei zerwałoby z kompatybilnością istniejących misji. Wówczas już lepiej napisać grę thiefo-podobną od podstaw, ale tutaj byśmy powtarzali to, czym jest The Dark Mod...

Sorry, za osobny post, ale się trochę rozpisałem...
To nie jest BSP - to jest bardzo fajne narzędzie do modelowania, ale nieprzydatne z punktu widzenia architektury silnika dark engine. Dark Engine ma widzialny świat reprezentowany za pomocą tzw. komórek (cells), które są prostymi bryłami wypukłymi (czyli np. pokój w kształcie litery L jest reprezentowany przez dwa przylegające prostopadłościany).

Już bliższy Dromedowi jest ten plugin do Unity, który działa w oparciu o brushe:
https://assetstore.unity.com/packages/t ... -csg-69542

ale to też nie tworzy takiej struktury jaką wymaga silnik i też nie tworzy BSP, czyli struktury służącej do optymalizacji wyświetlania ścianek.
Można się tym zainspirować, ale całą obsługę brushy, portalizację i optymalizację trzeba by napisać od zera.


Z tego co wiem, to Volca nie miał specjalnie planów tworzenia nowego edytora. Może w przyszłości - on chciał napisać przede wszystkim silnik, który by działał na innych platformach niż Windows i na nowoczesnym sprzęcie i być może wprowadzić pewne usprawnienia. Część z tych rzeczy została osiągnięta przez New Dark'a, stąd pewnie strata zapału.


Nie wiedziałem, że miałeś z tym projektem jakąś styczność.
Ja na tą chwilę, nie jestem kompetentny w C++, więc na niewiele bym się przydał.
Volca pomógł mi natomiast w napisaniu tego skryptu do 3dsmaxa, o którym wcześniej wspomniałem.


No, coś tam robiłem w Unity. Ostatnio też zacząłem pisać moduły w pythonie do czytania i zapisywania plików dark engine'owych (mis, gam, cow), żeby pomóc jednemu gościowi z TTLG (Terra) w uratowaniu jego misji. Jego plik został uszkodzony, ale to, co zostało, to udało się uratować, czyli brushe, listę tekstur, linki i część właściwości obiektów. Muszę jeszcze dokończyć tą operację i przeprowadzić parę bardziej chirurgicznych zabiegów...

Ale teraz głównie dążę do pełnego zrozumienia formatu .MIS i GAM. O tyle o ile WorldRep jest dobrze udokumentowany, o tyle fragmenty odpowiedzialne np. za AI Pathfinding albo system fizyki są ciągle nierozszyfrowane. Są to głównie fragmenty, które są wynikiem kompilacji misji. Kod źródłowy na pewno tu się przyda. W każdym razie dopóki format każdego fragmentu pliku nie jest znany, dopóty nie ma co nawet myśleć o pełnym edytorze.
Wielki Budowniczy powtarzał, że fundamenty są najważniejsze!

Myślę, że nawet jak nie osiągnę głównego celu, to będę w stanie stworzyć narzędzia pomocnicze, służące np. do kopiowania obiektów pomiędzy misjami lub gamesysami, itp...

Niestety mam tylko link do wątku na TTLG, musiałbyś pogadać bezpośrednio z autorem: https://www.ttlg.com/forums/showthread.php?t=149581

Co do dylematu to w pełni rozumiem. To trochę tak jakby portować coś do najnowszego UnrealEngine, podczas kiedy należałoby po prostu korzystać z tego co tam jest i dopisać mechanikę, tak jak to się stało z TDM (który, nawiasem mówiąc, też już jest mocno stary jeżeli chodzi o narzędzia).

Do tego dochodzi też problem praw autorskich. Nie wiem na ile bezpieczne jest dopisywanie kodu do DromEda albo tworzenie rzeczy na jego bazie, ale zakładam, że bezpieczniejsze niż wciąganie cudzych assetów do cudzego silnika.

_________________
Builder Compound Asset Pack – models and textures for TDM

Ah, nie wiedziałem, że to taka świeżość. Nie wygląda to na nic zaawansowanego.


Myślę, że to nie byłoby bezpieczne, z punktu widzenia zdrowia psychicznego. :D
Jeśli już używać kodu źródłowego, to tylko do rozszyfrowania nieznanych mechanizmów i struktur danych, ale edytor jako tako by trzeba napisać od nowa.

Poplułem się poranną kawą

W sumie to nie wiem, czy faktycznie przenosiny do nowego silnika są potrzebne. Lepsza technologia to większa szczegółowość otoczenia, czyli znacznie więcej pracy dla jednej osoby. Może faktycznie lepiej pomyśleć nad lepszymi narzędziami do tego, co już jest.

_________________
Builder Compound Asset Pack – models and textures for TDM

Temat nawinął się w ramach tematu tworzenia fanmisji nie zaś samej gry. Co do gry, zaryzykuję stwierdzeniem, że nasza mała społeczność hobbystów miałaby podzielone opinie na temat ewentualnego nowego silnika i pewnie racja, że finalnie projekt zmierzałby w stronę podobną do TDM. Wg mnie edytor można tworzyć całkowicie oddzielnie od silnika, zwłaszcza że jego użycie nie jest wymagane na etapie edycji. Portalizację jak i całe budowanie misji można by uruchomić headless.



Juliusz?





Qt + Python = dołączam do projektu Gratuluję wyboru dobrej technologii. Sam mam w nich spore doświadczenie, tak więc z łatwością mogę pomóc.

Dorzuciłbym do tego Panda3D do podglądu 3D i mamy nowy projekt. Co sądzisz? Chciałbym rzucić okiem na moduły w Pythonie Umieram z ciekawości.

Generalnie tak, ale testowanie misji musi być w miarę interaktywne. Może nie potrzeba silnika do samego testowania terenu (wystarczy na początek prosty fly mode), ale do testownia rozgrywki - już tak.
Ale jest na to sposób - można zaprzęgnąć Dromeda do automatycznego odpalania konkretnych fanmisji i przejścia w game mode. (stosuję to do testowania nowych ruchów z poziomu 3dsmaxa). Byłoby to trochę wolniejsze - misję wpierw trzeba zapisać, otworzyć Dromeda, wczytać plik mis i dopiero gramy. Ale nie powinno być źle.


To fajnie, że masz doświadczenie w Pythonie i Qt (używasz PySide ? ). Ale do pełnego edytora to raczej nie wystarczy. Ja zamierzam wykorzystać Pythona do narzędzi pomocniczych, które w ramach treningu robię po drodze.
Do pełnego edytora to jednak musiałby być jakiś język zaczynający się na C. Myślę też o C#, bo mam z nim pewne doświadczenie z Unity, aczkolwiek na tą chwilę nie istnieje w pełni funkcjonalny binding Qt dla C#.
A co do Pandy3D - patrzyłem na nią dosłownie kilka dni temu. Nie przekonała mnie Panda póki co - taki trochę PyGame dla 3D. Czyli dobre do nauki i zabawy, ale chyba nie wystarczy do konkretnego projektu - mam na myśli wydajność. Poza tym, są problemy z integracją z PySide'em właśnie.


Spoko, udostępnię to wkrótce.
A znasz już biblioteki i narzędzia napisane przez Telliameda, dostępne na tej stronie?
https://whoopdedo.org/projects.php?dark
Konkretnie chodzi mi o te:
- DarkLib
- DarkUtils
- i właśnie Python
Ja od tego wyszedłem.

A jeszcze zapytam - jak stoisz z matematyką i geometrią 3D?
Do największych wyzwań należeć będzie:
- portalizacja (i optymizacja)
- wypalanie lightmap
- rendering całego levelu
- różne shadery (może nie na poziomie dzisiejszych AAA, ale zawsze)
- tworzenie AI Pathfinding database
Powyższe muszą nie tylko działać, ale też działać szybko.
Sam edytor, czyli projektowanie interfejsu itp. to myślę, że to będzie sama przyjemność.


No, jak masz czas i entuzjazm, to jasne - połączmy siły.

Jeszcze a propos Pandy3D - po kolejnym zerknięciu - w sumie, to nie jest słaby silnik, tylko może nie ma zbyt wielu porządnych projektów na nim zrobionych. Biorąc pod uwagę łatwość programowania, może to być dobre do prototypowania - zawsze jest możliwość napisania fragmentów też w C++.

Natomiast problem chyba jest tej natury, że jest to... silnik do gier - a więc aplikacja ze swoją pętlą główną i jako taka może wchodzić w konflikt z applikacją Qt.
To, czego byśmy potrzebowali, to biblioteka graficzna, którą byśmy wykorzystywali tylko do renderowania obrazków, natomiast obsługa interfejsu, klawiszy, myszy itp. byłaby po stronie Qt.

Dlatego patrzę teraz na DirectPython11 albo na PyOpenGL. Trzeba by porównać ich wydajności i możliowści. Jako, że odbiorcami Thiefa są tylko użytkownicy Windowsa, to nie trzeba się starać o wieloplatformowość.
Tymniemniej, byłbym bardzo zaskoczony, jeśli taki edytor dałoby się napisać w pythonie, z pewnymi tylko wtrąceniami w C++ / C#...

Nie będzie źle. Spróbowałbym odpalić w tle odpowiednie komendy z dromeda a całość byłaby transparentna dla użytkownika.

To tyczy się zarówno uruchomienia game mode jak i portalizacji, światła, pathfinding itp. Za dużo rzeczy aby startować z konkurencyjnym edytorem i czekać by był w pełni funkcjonalny dopiero jak wszystkie powyższe funkcje będą zapewnione. W pierwszej wersji celowałbym w bindowanie do oryginalnych funkcji. Mogę zrobić rozeznanie czy będzie z tym dużo problemu.

Gdy edytor będzie działający, wtedy można pomyśleć o napisanie własnej implementacji powyższych narzędzi budowania. Jednak to w co celowałbym w pierwszej kolejności to użyteczność, przystępność i zróżnicowanie edytora pod względem UI. Taki był główny motyw rozpoczętej dyskusji i jest to też chyba jedyna motywacja mojego zainteresowania.

Skoro pytasz, w PySide pisze się tak samo jak w PyQt, więc z tym doswiadczenie mam. Nie wiem skąd u ciebie taki nacisk na języki C. W przypadku Qt, dla mnie to nie ma większej różnicy czy Python czy C++. Wiem tylko że w Pythonie prace nad projektem będą szły kilka razy szybciej, a to będzie się dało odczuć przy projekcie nad którym będzie się siedzieć w wolnym czasie.


Jest trochę konkretniejszych projektów w Panda3D. Nie wiem czy do podglądu jest potrzebna tak duża wydajność. Jeśli jakieś dwie biblioteki nie będą razem grały to może być cokolwiek innego co pozwoli na narysowanie ścian brushy i modeli obiektów.



To jest wykonalne, ale zostawiłbym to jako ostateczność. Ale znowu, nie wiem skąd taki nacisk na wydajność. Statyczny podgląd 3D edytora nie powinien mieć dużych wymagań. Jeśli wybór padnie na Qt, to trzeba wybrać coś dobrego pod tą platformę. Może to byłby właśnie OpenGL, ale tego jeszcze nie wiem.



Teraz już znam :D

Muszę powiedzieć że czekają mnie 2-3 wieczory eksperymentowania z tym kodem. Chcę wypróbować czy pewne elementy mojego conceptu mają rację bytu i wtedy możemy dalej rozmawiać. Widać byłem do tyłu z programistyczną częścią userów TTLG.

Co do rozmawiania to dałem już info moderatorowi, przez przycisk raportowania, by wydzielił temat. Trochę się zrobił offtopic

Jako "proof of concept" - jasne. Pewne elementy UI można usprawnić, pozostając w pełni kompatybilnym z Dromedem. I pierwsza wersja mogłaby tak działać.

Natomiast moje plany sięgają dużo dalej. Chciałbym wycisnąć maks. z silnika, co stety-niestety wiązałoby się z utratą kompatybilności z Dromedem. Trik polega na tym, że brushe nie są potrzebne do grania, a jedynie do budowania. Dlatego ja myślę o edytorze mającym nieco inny format pliku, a na potrzeby testów i właściwego grania, misja byłaby eksportowana do formatu .mis.


Tak jak wyżej - myślę już o produkcie ostatecznym, który musiałby w pełni zastąpić Dromeda w budowaniu.
- Płynne poruszanie się po scenie 3D, wraz z meshami.
- opcjonalnie: animowane tekstury i cząsteczki, dla pełnego poglądu wizualnego misji
- Portalizacja i inne obliczenia. W Dromedzie nie można wielce narzekać na prędkość. New Dark także skrócił czas budowania. Jeśli portalizacja miałaby wydłużyć się kilkukrotnie (a w czystym Pythonie to pewnie i ze stukrotnie), to raczej by taki edytor się nie przyjął)
Poza tym ciągnie mnie do programowania w C++ (bądź C#), więc każdy powód do nauki dobry.

Inna sprawa, że Pythona zacząłem brać pod uwagę dopiero jakieś 3-4 tygodnie temu, kiedy zacząłem rekonstruować uszkodzony plik .cow. Może się przyda bardziej, niż myślę. Jestem otwarty.


W tym dziale chyba zawsze był problem z aktywnością moderatorów... Kto wie - może się pojawi.

Ponieważ te posty wisiały już długo, to pozwoliłem sobie interweniować. Tytuł tematu może być?

_________________
Builder Compound Asset Pack – models and textures for TDM

Może być! Dzięki.

_________________
Portfolio 3D - www.juliuszk.com
Art Blog - juliuszk.blogspot.ie

Tekstury i obiekty dla dromedowców.