Autor Wątek: Silnik - hierarchiczna struktura obietków  (Przeczytany 8358 razy)

agent_J

  • Gość
# Marzec 04, 2006, 10:31:14
Kiedyś próbowałem pisać symulator miasta - samochody, ludzie, budynki i inne. Wpadłem na taki pomysł, żeby zastosować hierarchiczną strukturę obiektów. Każdy obiekt może znajdować się "wewnątrz" innego, przykładowo gdy wsiadamy do auta, obiekt reprezentujący gracza jest wstawiany do obiektu reprezentującego samochód. Chodziło mi o to, żeby silnik robił jak najwięcej za programistę, np. jeśli samochód porusza się, to obiekty znadujące się w samochodzie również się poruszają. Współrzędne każdego obiektu są wzgledem obiektu nadrzędnego (np. jak samochód jedzie, to obiekty wewnątrz razem z samochodem), również wszelkie siły działające na obiekt podrzędny są "konwertowane" z obiektu nadrzędnego.

Offline Mr. Spam

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

Offline Piotr

  • Użytkownik

# Marzec 04, 2006, 10:34:36
Według mnie pomysł dobry, a próbowałeś to zaprogramować ?

agent_J

  • Gość
# Marzec 04, 2006, 10:49:39
Według mnie pomysł dobry, a próbowałeś to zaprogramować ?
No właśnie ostatnio nie mam czasu. W następny weekend planuję się za to zabrać.

Offline Spider100

  • Użytkownik
    • Strona domowa

# Marzec 04, 2006, 11:34:38
Witam !

Pewnie że dobry pomysł, takie coś napisałem specjalnie na potrzeby animatora i teraz mogę wykorzystywać w każdym projekcie.

Po prostu wszystkie obiekty na scenie mają swojego rodzica i dzieci.
Dodatkowo zawierają pozycję i rotacje w lokalnym (czyli ten względem którego są przenoszone) oraz globalnym układzie współrzędnych.

Obliczenia na scenie przechodzi się od podstawowego rodzica(na całą grę może być taki tylko jeden) przez każde jego dziecko rekurencyjnie. Wystarczy kolejno mnożyć macierze :) Później można  dodawać ciekawe zabawki np. IK

Co prawda nie napisałem jeszcze do tego fizyki, ale przy okazji rag dolla coś ciekawego powstanie :) 

Powodzenia ;)
Pozdrawiam!
Spider ^*^

agent_J

  • Gość
# Marzec 04, 2006, 12:59:13
No właśnie zawsze mi się marzył silnik, w którym wstawiam obiekty na scenę i definiuję interakcje między nimi, a resztę robi silnik.

Offline Koshmaar

  • Użytkownik
    • Homepage

# Marzec 04, 2006, 14:06:28
Cytuj
hodziło mi o to, żeby silnik robił jak najwięcej za programistę, np. jeśli samochód porusza się, to obiekty znadujące się w samochodzie również się poruszają. Współrzędne każdego obiektu są wzgledem obiektu nadrzędnego (np. jak samochód jedzie, to obiekty wewnątrz razem z samochodem), również wszelkie siły działające na obiekt podrzędny są "konwertowane" z obiektu nadrzędnego.

Takie coś zwie się scene graph, a poczytać o tym więcej można np. tutaj: http://www.gamedev.net/community/forums/topic.asp?topic_id=349829 :-)

Dodatkowo polecam jeszcze tego linka: http://www.openscenegraph.org/ , ściągnij dokumentację i poczytaj - jest dość pouczająca :-)

agent_J

  • Gość
# Marzec 04, 2006, 14:15:01
Takie coś zwie się scene graph, a poczytać o tym więcej można np. tutaj: http://www.gamedev.net/community/forums/topic.asp?topic_id=349829 :-)

Dodatkowo polecam jeszcze tego linka: http://www.openscenegraph.org/ , ściągnij dokumentację i poczytaj - jest dość pouczająca :-)

Mimo, że takie coś jest to jednak wolałbym napisać sam bez wcześniejszego przeglądania dokumentacji
innych projektów. Dopiero jak się nie uda to poczytam :)

Offline migajek

  • Użytkownik

# Marzec 04, 2006, 14:44:21
hmm ale chyba tak powinien po prostu wygladac silnik? :P w sumie nigdy nie mialem stycznosci z silinikami Warsztatowymi, a jedyny wogole silnik jakim bawilem sie dluzej niz tydzien to TV3D ->i przynajmniej tam kazdy obiekt mial metode ConnectTo -> czyli "laczylo" sie go z innym meshem (mozna bylo ustalic na co reaguje; m.in. zmiana pozycji, obrot, skalowanie)

Offline SauRooN

  • Użytkownik

# Marzec 04, 2006, 15:00:25
No to jest podstawa silnika. Np. w Ogrze jest hierarchiczne drzewko SceneNode'ów, cała scena jest w nim umieszczona - obiekty, światła, particle systemy, kamery, itd. Wszystkie one są podpięte pod któryś węzeł drzewa. Widoczność jest określana na poziomie drzewa (bounding volumes są powiązane ze SceneNode'ami). Każdy SceneNode może mieć wiele dzieci. Dzieckiem SceneNode'a może być zarówno inny SceneNode, jak i dowolny obiekt (Entity), światło itd. (wtedy są to liście drzewa). Wszelkie transformacje są obliczane na zasadzie stosu macierzy od root'a do liścia. Wszelkie operacje na takiej strukturze są bardzo wygodne - np. żeby wyłączyć jakiś budynek/sektor czy cokolwiek innego (ukryć go), wystarczy poprostu odpiąć jego SceneNode'a od jego rodzica. W moim silniku zastosowałem identyczne rozwiązanie.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Marzec 04, 2006, 21:20:28
Cytuj
No to jest podstawa silnika.
A ja w swoim mam, póki co, zupełnie płaską strukturę. Widoczność jest zarządzana na podstawie obszarów (przy pomocy prostego drzewka BSP sprawdzam, których obszarów dotyka obiekt) i wszystko dzieje sie automatycznie. Moim zdaniem to właśnie jest podstawą silnika, ponieważ naturalnie obiekty są niezależne (ludzie w budynku nie różnią się przecież od tych na ulicy). :)

Offline SauRooN

  • Użytkownik

# Marzec 05, 2006, 00:12:12
W podejściu z drzewkiem node'ów są tym bardziej niezależne :)
A tak btw. (to już jest osobna kwestia) - można mieć 2 różne scene managery (przykładowo: jeden do indoor'ów, np. na BSP i drugi do outdoor'ów na np. Octree) i w trakcie gry przełączać się między nimi w zależności od tego, czy postać łazi po budynkach czy nie. Cała struktura obiektów pozostaje ta sama. Nie wiem czy osiągnąłbyś to przy Twojej strukturze silnika, a nawet jeśli, to podejrzewam, że nie byłby to zbyt elastyczny system. Myślałem swego czasu o tym, czy dałoby się to osiągnąć bez takiej struktury, ale nie wymyśliłem żadnego zadowalającego rozwiązania.
« Ostatnia zmiana: Marzec 05, 2006, 00:13:58 wysłana przez SauRooN »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Marzec 05, 2006, 00:37:46
Cytuj
można mieć 2 różne scene managery (przykładowo: jeden do indoor'ów, np. na BSP i drugi do outdoor'ów na np. Octree)
W takim przypadku ja bym je starał się po prostu połączyć - na przykład BSP może być nodem w octtree, albo octtree może być nodem w BSP, albo zupełnie zgeneralizowane drzewo, gdzie każdy węzeł może dzielić przestrzeń według płaszczyzny albo na 4 ćwiartki (chociaż to już moze być niepraktyczne). :) Ogólnie nie jestem przeciwny wszelkiego rodzaju hierarchii obiektów (u mnie jest drzewko BSP->Obszary->Obiekty), tyle że silnik powinien to całkowicie ukrywać przed użytkownikiem, poza przypadkami, gdzie hierarchia ma inne przyczyny (np. postać trzyma broń). :)

Offline SauRooN

  • Użytkownik

# Marzec 05, 2006, 05:35:31
Połączenie ich byłoby dobre tylko jeśli założysz, że każda gra korzystająca z tego silnika będzie miała i indoor i outdoor. Natomiast jeśli w pewnym momencie zdecydujesz się na napisanie gierki typowo indoor albo typowo outdoor, to najprawdopodobniej na tym stracisz (niepotrzebne dane, niepotrzebne obliczenia). Wiem że zasadniczo nie przepadasz za zbyt ogólnymi i wszechstronnymi silnikami, ale w tej kwestii jednak warto porządnie oddzielić obsługę indoor od outdoor.

Co do ukrywania hierarchii przed użytkownikiem, to nie zgadzam się z Tobą. Hierarchia scene node'ów jest świetnym sposobem na zarządzanie sceną, zarówno dla programistów, jak i grafików. Posłużę się przykładem systemu budynków w naszym projekcie FW. Każdy budynek podpięty jest pod dany sektor. Budynek się składa z pięter, każde piętro z pomieszczeń i podłogi, każde pomieszczenia ze ścian. Kiedy postać gracza wchodzi do budynku, ukrywamy wszystkie wyższe piętra. Ukrycie ich == odpięcie ich scene node'ów od node'a budynku. Podczas przechodzenia między piętrami przepinamy tylko odpowiednie node'y. To jak widzisz jest już element GameSystemu, a nie silnika graficznego, a nadal korzystamy z dobrodziejstw tej hierarchii. Takich przykładów jest wiele (np. silnik fizyczny może korzystać z tej hierarchii do własnych celów).

Offline DarkJarek

  • Użytkownik
    • DarkJarek HomePage

# Marzec 05, 2006, 08:09:30
Ciekawy pomysł, jabym tu nawet widział możliwość optymalizacji kolizji między obiektami.

agent_J

  • Gość
# Marzec 05, 2006, 08:36:27
Co do kolizji, to sprawa jest prosta, bo bada się tylko kolizję z obiektami we wspólnym węźle rodzicu, a dodatkowo można sobie sortować węzły przy wstawianiu np. według z,x,y. Kolizji z węzłami dziećmi nie sprawdzamy, tylko one sobie najwyżej sprawdzają ze sobą albo z węzłem rodzicem.

Jeszcze sobie wymyśliłem kilka propertiesów takiego podświata:
- klej - przykładowo jeśli jeden model przysunie się blisko do drugiego, to się "przyklei" i stanie się jego częścią
- wejście i wyjście - czy da się wejść albo wyjść z jednego podświata do drugiego