Autor Wątek: System mięśniowy  (Przeczytany 3966 razy)

Offline Kyroman

  • Użytkownik

# Kwiecień 16, 2008, 22:45:20
Witam.
Jestem członkiem małej grupy developerskiej, zajmujemy się obecnie tworzeniem gry cRPG nastawionej na single player, z możliwością gry multi, oraz w przyszłości MMOcRPG w tych samych klimatach. Wymyśliłem kilka systemów, programistą jednak nie jestem i nie potrafię ocenić, do jakiego stopnia jest możliwe wykonanie tego. Szczególnym problemem jest liczenie kolizji. Chciałbym więc, aby ktoś, kto się na tym zna, wypowiedział się. A więc:

System mięśniowy - ten system można zrobić w różnych formach i różne dawałby możliwości. Jak sądzę, niczego nowego tworzyć by nie trzeba, a wykorzystać jedynie to, co jest na porządku dziennym oraz możliwości PhysXa. Wiem, że Ageia zajmuje się obecnie czymś podobnym, jednak z tego co się orientuję ma to być przeznaczone głównie (jeśli nie wyłącznie) do stworzenia realistycznej bezwładności ciała (krok dalej od zwykłych ragdolli). System, który planuję, miałby jednak nieco inne zastosowanie.
Polegałby na zaimplementowaniu do środka modeli organicznych (a więc zarówno człowieka, jak i zwierząt) głównych mięśni i narządów. Byłyby to mięśnie (około 20-30), kości, serca, płuca, wątroba, główne arterie. Decydowałyby one głównie o tym, w jaki sposób model może się poruszać, a więc w wypadku zbytniego wygięcia ciała pod wpływem dużej siły (ragdoll) mogłoby dojść do zerwania ścięgna, a więc noga czy ręka przestałaby funkcjonować jak należy. Dochodzi także możliwość śmierci na tysiąc sposobów :D Tłumaczyć chyba nie trzeba: strzał w serce jest śmiertelny i krwawy, strzał w aortę powoduje spektakularne rozbryzgi krwi, strzał w płuca powolne uduszenie z wyraźnie słyszalnym rzężeniem. Dochodzi także przecięcie mięśni (a więc tak samo jak pisałem wcześniej, ubezwładnienie kończyny) oraz złamanie kości. Możliwości jest wiele, ale głównym problemem jest ilość kolizji, jakie trzeba wyliczyć. Tego właśnie sam ocenić nie umiem, a więc prosiłbym o jakieś wypowiedzi w tej kwestii. Cały aspekt implementacji narządów można ogólnie pominąć, bo zależy mi szczególnie na innym jego wykorzystaniu, które opiszę później. Same narządy miałyby wyglądać mniej więcej tak:
http://img181.imageshack.us/img181/8676/miesienhm5.png
Jak widać, byłyby to proste bryły. Silnik jak mniemam umie liczyć objętość (znaczy się, nie wyobrażam sobie żeby nie umiał ;) ). Każdy element miałby wyznaczone swoje miejsca podczepu (szczególnie jeśli chodzi o mięśnie) oraz ustaloną stałą (no, nie do końca stałą) objętość. Tak więc zmieniając odległość między miejscami podczepu, a jednocześnie zostawiając taką samą objętość, komputer musiałby wyliczyć położenie reszty wierzchołków. Wierzchołki napierałyby także na sam model, a więc musiałoby nastąpić również jego wygięcie - znowu mnóstwo kolizji. Sam nie wiem, co o tym myśleć, bo z jednej strony progerzy mówią, że wyliczanie kolizji jest ciężkie dla komputera, a z drugiej, widząc możliwości PhysXa, nie jestem w stanie im uwierzyć. :D To dawałoby dodatkowy bonus, taki mały "smaczek" - napinka. ;D Zginając rękę, pokazują się "muły" :D Nie wiem czy byłoby to w ogóle zauważalne, w każdym razie robienie takich rzeczy ręcznie w animacji byłoby na pewno trudniejsze.
Ustalona by musiała być także wartość maksymalna odległość między miejscami podczepu, a więc w momencie jej osiągnięcia, kończyna nie mogłaby bardziej się odginać, a w momencie jej przekroczenia, następowałoby - lub nastąpić mogło - zerwanie ścięgna i ubezwładnienie ręki.
To wszystko ze względu na ilość kolizji można pominąć, zależy mi jednak na innym zastosowaniu (nawet bez implementacji narządów). Zmieniałoby ono nieco pojęcie animacji i samego animowania. Polegałoby ono także na wyznaczeniu "możliwości ciała", a więc maksymalnego wygięcia rąk itp. oraz "wskazaniu" modelowi, nie jak ma się poruszyć, a jak może się poruszyć. Model więc nie wykonywałby czynności (animacji), ale dążył do wykonania jej. W zależności od sytuacji wyznaczane byłyby także punkty, do osiągnięcia których dążyłby model. Przykładowo więc podając przedmiot, wyznaczany byłby odpowiedni punkt lub punkty do których mają dążyć dłonie przekazującego i otrzymującego. Drugą rzeczą w tym wypadku byłaby równowaga, a więc ustalenie, do jakiego stopnia model się może wychylić zanim się przewróci oraz ustalenie odruchów, a więc np. podparcie się nogą by uchronić się przed upadkiem, przestąpienie z nogi na nogę itp. Jakie miałby taki system zastosowanie? Ot, przykładowo, karczmarz nalewając piwo do kufla może stać w dowolnej pozycji względem kufla a i tak trafi, kołatając do drzwi można stać metr od nich i się wychylić, siedząc można podeprzeć się łokciem o stojący obok stół. Nic w tym nadzwyczajnego by nie było, gdyby właśnie nie to, że istnieje całkowita dowolność, gdzie ten kufel by się znajdował, na jakiej wysokości ktoś zaczepiłby swoją kołatkę oraz jak wysoki był stół. Ma to oczywiście tysiące innych zastosowań, od mycia się, przez wykuwanie mieczy, zbieranie owoców, podnoszenie przedmiotów, rąbanie drzew, na samej walce kończąc. Zauważcie, że w każdej innej grze takie elementy były albo pomijane, albo następował nienaturalny przeskok, a dana czynność zawsze wyglądała identycznie. Zwróćcie także uwagę na to, że gdyby każdą możliwość wykonywać jako oddzielną animację, byłyby ich setki, a więc cierpi i animator, i dysk gracza, nadal pozostając bez dowolności wykonania czynności.

Miało być kilka systemów, jednak tymczasowo poprzestanę na samym mięśniowym. Prosiłbym o wypowiedzi szczególnie w kwestii ilości kolizji, jakie musiałby obliczyć silnik, jak wpłynęłoby to na grę (który element komputera byłby za to odpowiedzialny? Procesor? Karta?) oraz w kwestii wykorzystania ostatniego z podanych przeze mnie rozwiązań.

Pozdrawiam i z góry dziękuję za odpowiedzi,
Kyroman

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Spider100

  • Użytkownik
    • Strona domowa

# Kwiecień 16, 2008, 23:17:43
Witam!

quote]Jak widać, byłyby to proste bryły. Silnik jak mniemam umie liczyć objętość (znaczy się, nie wyobrażam sobie żeby nie umiał
[/quote]

Czy silnik potrafi liczyć objętość? Nie sądzę by był to jeden z ważniejszych elementów silników fizycznych... ja w swoim implementowałem liczenie objętości dzieląc siatkę na czworościany ale to już nie jest takie hop jak by sie mogło wydawać, a wszytsko tylko po to by zrobić dokładną pływalnośc obiektów w cieczach. gdzie tu brac pod uwagę obiekty dynamicznie zmieniające się ...

Cytuj
Sam nie wiem, co o tym myśleć, bo z jednej strony progerzy mówią, że wyliczanie kolizji jest ciężkie dla komputera, a z drugiej, widząc możliwości PhysXa, nie jestem w stanie im uwierzyć.
Bo jest ciężkie ale Twój problem nie ma za wiele z kolizjami wspólnego.

Moje sugestie:
1. Pomysł jest do bani można uzyskać lepsze efekty mniejszym kosztem
2. Jak już idziemy w mięśnie - to nie objętość bo to nie sa jakieś balony (chyba żę byś piersi chciał modelować) ... tylko lepiej zrobić wiązania za pomocą mocno tłumionych sprężyn podpiętych do lokalnego układu kości. Wtedy obliczenia dyrastycznie spadają i możemy choc troche przewidzieć jak to działa jakie 'sprężyny' są naciągnięte a które ściśnięte czyli dokładnie wiem co się dzieje z siatką.
3. Kolizje dla wnętrzności postaci robić ? Urojony pomysł ... kolizje są kosztowne i trzeba się wystrzegać.
4. Jak postać może się poruszać <- od tego sa ograniczenia stawów które naprawdę mało kosztują obliczeniowo.
5. Podparcie się przed upadkiem ? Nad takimi rzeczami się siedzi i siedzi w kodzie i nic nie wychodzi tu jest biomechanika przejrzyj silnik euphoria (oxford pracował)
6. Żal mi programistów których chcesz tym katować ...

To moja ogólna ocena pomysłu możesz się zgodzić lub nie jednak nie polecam iść w tym kierunku. Próbowałem napisać mechanikę chodzenia postaci opartą częściowo na fizyce i samodzielnej decyzji i bez zastanowienia mogę powiedzieć ze jest to ciężki kawałek chleba do ugryzienia. Robiłem uproszczenia i nie dawało rady, a mięśnie które proponujesz uproszczeniem nie są co znaczy że praca postaci będzie jeszcze trudniejsza :P

pozdrawiam
Spider^*^

Offline Kyroman

  • Użytkownik

# Kwiecień 16, 2008, 23:32:03
Ad 1. Masz jakiś pomysł?
Ad 2. Też można i trzeba się będzie nad tym zastanowić. Daje to jednak rozwiązanie tylko w wypadku drugiej części systemu (samego poruszania), a nie pierwszej, czyli realistycznych obrażeń w walce.
Ad 3. Chciałbym właśnie dowiedzieć się jakie są koszty liczenia kolizji, ile przy obecnych komputerach silnik jest w stanie wyliczyć itp. Dodam tylko, że silnik którego używamy to Chrome Engine 4.
Ad 4. No takie ograniczenia są już przy samym tworzeniu animacji (biped). Jak to wygląda w przypadku ragdolli?
Ad 5. Przyjrzę się, wywiem, pooglądam ;)
Ad 6. Cóż, takie życie, raz się katuje, raz się sprawia przyjemności :P

Z faktu, że rozwiązanie nie jest uproszczeniem zdaję sobie doskonale sprawę, bo nie ma być ono uproszczeniem w żadnym wypadku. Praca, jaką trzeba włożyć, jest rzeczywiście ogromna, ale myślę, że gra jest warta świeczki.

Offline Koko

  • Użytkownik

# Kwiecień 16, 2008, 23:48:33
Mięśnie i narządy to głupi pomysł... lepiej gdybyś zrobił 'kości', podpiął do nich prymitywy i sprawdzał czy nastąpiła kolizja tylko z kośćmi :P

Offline Dab

  • Redaktor
    • blog

# Kwiecień 16, 2008, 23:49:36
Pomysł świetny, ale raczej nierealny.
Złożoność obliczeniowa to jedno, a zabugowanie tego to drugie. Co jeżeli bohaterowi łokieć utknie między kuflem a stołem? ;) Mówiąc poważnie, tego typu rzeczy nawet dla pojazdów mechanicznych są dosyć skomplikowane, nie mówiąc o modelach człowieka.
Realistyczne obrażenia to akurat nie problem, przecież strefy trafień to wynalazek stary jak świat.
Symulując fizycznie animację będzie dodatkowy problem z wyświetleniem tego (łączenia poszczególnych części).

Dodatkowo, jeżeli chcesz robić grę MMO to jak wyobrażasz sobie przesyłanie informacji o dziesiątkach mięśni/organów każdej postaci? :)

Ogólnie gra jest -- oczywiście -- warta świeczki, ale skrajnie nierealna. Zwłaszcza dla "małej grupy developerskiej". Myślisz, że czemu w Crysis nie ma czegoś takiego? :)

Ale żeby nie zniechęcać: proponuję wam zrobić prototyp (na przykład pająka z ośmioma nogami ze spadającymi na niego sześcianami). Wtedy odechce wam się takich rozwiązań (albo wyrośnie potentat na miarę Crytek, czego szczerze życzę).


Odpowiadając jeszcze na inne pytania: póki co liczyłby to CPU. W przypadku PhysX rolę tę mogłaby jednak spełniać karta fizyki (do niedawna), a niebawem jakiś nowy, wypasiony GeForce.
« Ostatnia zmiana: Kwiecień 17, 2008, 00:07:43 wysłana przez Dab »

Offline mwojt

  • Użytkownik

# Kwiecień 16, 2008, 23:58:16
pomysł realny ale nie na taką grę, raczej proponował bym zrobić bijatykę w tym stylu.

Offline voytech

  • Użytkownik

# Kwiecień 17, 2008, 00:06:26
Co do kolizji z narządami to nie powinno być to trudne, dla przykładu objętość serca można przybliżyć sferą, wystarczy przechowywać współrzędne środka i promień. Ten środek można przechowywać w modelu jako jeden werteks przypisany z wagą 1.0 do kości górnego odcinka kręgosłupa i przekształcać go jak pozostałe wierzchołki modelu. Liczenie kolizji ze sferą to chyba najprostrza czynność pod słońcem. Bardziej nieregularne narządy można interpolować kilkoma sferami.

Pamiętam, że w jednej grze FPS opracowano system wykrywania obrażeń na teksturach. To znaczy jedna z tekstur miała zamalowane odpowiednie obszary na czerwono, gdzie obrażenia są śmiertelne. Wystarczyło wyznaczyć trójkąt należący do modelu, w który trafił pocisk a następnie korzystając ze współrzędnych UV pobierało się kolor piksela i na podstawie jego wartości można było określić jaki obszar ciała został uszkodzony (biały - mózg, czerwony - serce, czarny - jelita, itd.)

Nie jest to dokładne ale myślę, że zbyt duża dokładność nie jest potrzebna, bo podczas strzelania na ekranie wiele się dzieje i mało kto zauważy różnicę.

Co do uszkodzeń mięśni, to najłatwiej byłoby opracować oddzielne animacje dla modelu reprezentujące jego aktualny stan zdrowia, tak jak to pewnie robią inni. Oczywiści jest to łatwe dla programisty ale już nie dla animatora bo musi się namęczyć bardziej przy tworzeniu animacji dla modelu na przykład z uszkodzonym mięśniem nogi, ręki, itd. :)

Offline Kyroman

  • Użytkownik

# Kwiecień 17, 2008, 00:32:23
@Koko: Jaki by to miało mieć cel?

@Dab: O takie rzeczy jak utknięcie łokcia bym się akurat nie martwił. Miałoby to się opierać głównie na bezwładności, a więc działać po części podobnie jak ragdolle. Czy zdarza się, że ragdollowi spadającemu z sufitu w karczmie łokieć utknie za kuflem? :P Wydaje mi się, że bardziej liczy się to, co powiedziałeś nieco później - symulacja fizyczna w czasie rzeczywistym. Jeśli chodzi o strefy trafień to sam przyznasz, że wygląda to jak wygląda i jest mało realistyczne.
Jeśli chodzi o MMO, to jak na razie się nim nie przejmujemy, nie wiemy czy w ogóle powstanie. Nie wiadomo także, jakie będą możliwości sprzętowe w momencie ewentualnego wydania. Jeśli zaś patrzeć na dzisiejszy sprzęt, to faktycznie, mało prawdopodobne jest funkcjonowanie takiego systemu w MMO.
Nie wiem czemu Crysis nie ma czegoś takiego, ale nie wiem także, czemu Ageia się zajmuje takimi rzeczami :D
Aha, wspomniałeś o samochodach - słyszałem, że Ageia właśnie zajmuje się robieniem realistycznych zniszczeń w samochodach, uwzględniając właśnie umieszczone wewnątrz elementy.

@Medivo: no do bijatyki mogłoby to być dobre. W naszej grze walka oczywiście też będzie, chociaż ja osobiście staram się, by było jej jak najmniej - jedynie w obronie własnej, nie zabijanie pięciu przeciwników jednym ciosem. Problem pojawia się, gdybyśmy chcieli zrobić jakąś większą bitwę, ale myślę że i to można rozwiązać - sam system mięśniowy działałby tylko dla gracza i tych npców, na których gracz może "zwrócić uwagę", a dla reszty tradycyjne strefy uderzeń itp.

@Voytech: odnośnie ostatniego akapitu - tego właśnie chcę uniknąć. Jeśliby wprowadzić w życie drugą część projektu, możnaby spokojnie zrobić dowolną ilość potencjalnych animacji bez dużego wkładu ze strony animatora (ze strony programistów - owszem). Problemem w wypadku tysięcy zwykłych animacji to pojemność dyskowa (chociaż jak wiemy dyski są coraz większe), w wypadku systemu o którym mówię ten problem znika.

Aha, chciałbym zwrócić jeszcze uwagę na jedną rzecz, tak nieco poza tematem. Nie wiem czy słyszeliście o takiej grze jak Mount&Blade (a warto usłyszeć ;)), w każdym razie przy moim ponad pięcioletnim złomie z teksturami i detalami ustawionymi na max komputer ciął się nawet przy 20 postaciach na ekranie, natomiast przy teksturach ustawionych na 30% gra chodziła płynnie przy 300 postaciach. A trzeba powiedzieć, że dla każdej liczone są kolizje, każda jest podzielona na strefy, są ragdolle. Skłania mnie to do myślenia, że skoro tekstury są coraz większe (np. 2048x2048), modele coraz dokładniejsze (5k poly na postać, 500 na broń), dodaje się coraz więcej map, to równie dobrze można sobie pozwolić na lepszą fizykę i więcej kolizji. Zwróćcie uwagę, że w każdej obecnej grze najważniejsza jest karta graficzna, a procesor może być zazwyczaj sporo słabszy. Nikt się jakoś nie czepia, że co chwilę pojawia się nowy rodzaj map, który komputer także musi przetworzyć. ;)

Offline Dab

  • Redaktor
    • blog

# Kwiecień 17, 2008, 00:47:18
Ale różnica między fizycznie-sterowanym-bohaterem a ragdollem jest taka, że jeżeli ragdoll gdzieś utknie, to co najwyżej gracz zrobi screenshota obrazującego bardzo śmieszne upośledzenie, a w przypadku zacięcia BG sytuacja nie jest już taka zabawna. Nie mówię, że to jest zupełnie nierealne, ale dopracowanie systemu tak, aby działał płynnie zajmie mnóstwo czasu.
Natomiast odruchy i naturalne reakcje przy interakcji z otoczeniem: o ile zaimplementowanie kolizji, jointów itp jest zjadliwe, to przecież nad realistycznym ruchem robotów pracują od wielu lat naukowcy z całego świata i w sumie dopiero niedawno widać postępy. Wątpię, aby udało się coś takiego powtórzyć w małym studio. Tym bardziej, że wtedy liczenia kolizji jest zatrzęsienie (bo trzeba liczyć potencjalne kolizje na całej drodze ruchu).
Wasza grupa ma już w ogóle doświadczenie z symulacjami fizycznymi?

Offline Kyroman

  • Użytkownik

# Kwiecień 17, 2008, 00:52:51
Cytuj
dopracowanie systemu tak, aby działał płynnie zajmie mnóstwo czasu.
Tak jak zapewne dopracowywanie każdego innego systemu. Nie wszystko, co powstało było od razu idealne.

Cytuj
nad realistycznym ruchem robotów pracują od wielu lat naukowcy z całego świata
W tym przypadku różnica jest taka, że w ruchach robotów problemem są same rozwiązania technologiczne. Tutaj zaś mamy coś, co już istnieje - w animacjach przecież odpowiednie węzły poruszają się po ściśle określonych trajektoriach i istnieje to już od wielu lat. Jedyna różnica polega na tym, że, jak mówiłem, komputer nie ma wykonać z góry określonego ruchu, tylko dążyć do wykonania go.

Co do naszych doświadczeń to nie wiem. Część osób w branży siedzi już jakiś czas, ale nie wiem, czy się tym ktoś zajmował.

Offline Dab

  • Redaktor
    • blog

# Kwiecień 17, 2008, 00:55:43
Jeżeli chcesz iść, machając nogami to wiesz, jaki ruch masz wykonać.
Ale jeżeli stoisz przy stole i chcesz podnieść kufel, sprawa nie jest już taka prosta ;)

[edit do poniższego] Myślę, że inaczej widzimy problem ;)
« Ostatnia zmiana: Kwiecień 17, 2008, 00:58:18 wysłana przez Dab »

Offline Kyroman

  • Użytkownik

# Kwiecień 17, 2008, 00:56:57
W kwestii tego, co konkretnie model ma wykonać, sprawa wygląda identycznie jak w przypadku samego tworzenia animacji tradycyjnym sposobem.

Edit do powyższego :P
Cóż, post wydał mi się na tyle jasny, by odpowiedzieć tak a nie inaczej. Jeśli chciałeś przekazać coś innego, to napisz.
« Ostatnia zmiana: Kwiecień 17, 2008, 17:10:37 wysłana przez Kyroman »

Offline Darnoc

  • Użytkownik

# Czerwiec 11, 2008, 15:43:01
Co do twojego systemu mięśniowego to coś takiego zostało stworzone na potrzeby gry MMORPG Conan gdzie zajmował się tym cały zespół świetnych grafików i programistów a gra jest dopiero w fazie beta. Mimo że w wierzę w małe firmy developerskie, to stworzenie tak skomplikowanego systemu mięśniowego jest rzeczą ogromnie skomplikowaną.

Offline puchacz-I

  • Użytkownik

# Czerwiec 11, 2008, 16:07:21
IMHO to wszystko jest do zrobienia, tylko może nieco inaczej niż opisałeś. Podjąłbym się tego za odpowiednią zapłatą ;)
« Ostatnia zmiana: Czerwiec 11, 2008, 16:10:33 wysłana przez I »

Offline Mildanach

  • Użytkownik
    • Mildanach Ent

# Czerwiec 11, 2008, 18:35:43
Podnoszenie kufla to operacja dwufazowa :) najpierw należy złapać ucho, a potem podnieść i przekręcić kufel. W obu przypadkach mamy pozycję-cel, do której dłoń ma dążyć. Iteracyjnie obracamy segmenty w kolejności od korpusu (ramię, przedramię, dłoń, palce), tak żeby w kolejnych cyklach zbliżyć dłoń do celu. O różne takie "przepisy" trzeba by popytać doświadczonych animatorów (albo samemu obserwować naturę;) ).
Symulacja chodu jest trudniejsza w implementacji, ponieważ pracuje całe ciało (dużo segmentów do policzenia), które musi cały czas walczyć, aby zachować równowagę.