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

Offline Majtek

  • Użytkownik

# Marzec 05, 2006, 11:57:05
Ja mam teren przechowywany w zmodyfikowanym octree i mam problem. Otóż mam wysokość noda idealnia na max dla terenu, do terenu mam przypinane inne obiekty które są renderowane jak jest widoczny nod. Teraz jak kamerą zjedziemy tak aby teren był niewidoczny ale obiekty na nim jeszcze powinny to i tak ich niewidać. I co mam zrobić przechowywać obiekty w nowym octree czy czymś podobnym?

Offline Mr. Spam

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

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Marzec 05, 2006, 14:06:01
Pomysł wydaje się bardzo fajny. Tylko czy macie na myśli takie rozwiązanie, w którym jednakowo traktujecie np. ludziki znajdujące się w pojeździe czy na platformie, jak i części jednej postaci, np. hitboxy ludzika i trzymana przez niego broń?

Ja myślałem kiedyś o takim superogólnym rozwiązaniu, w którym świat gry byłby jedną wielką obiektową bazą danych, w której można byłoby definiować dowolne klasy, ich pola różnych typów i związki między nimi znane z obiektowości - głównie dziedziczenie i zawieranie. Oczywiście taka baza musiałaby być wydajna i jakoś tak zoptymalizowana, żeby jej czas odpowiedzi był bardzo szybki, a nie rzędu całych sekund jak w zwykłych bazach danych. Chodzi po porostu o sposób myślenia o tym. Co sądzicie o takim podejściu?

Offline SauRooN

  • Użytkownik

# Marzec 05, 2006, 14:38:42
Cytat: Majtek
Ja mam teren przechowywany w zmodyfikowanym octree i mam problem. Otóż mam wysokość noda idealnia na max dla terenu, do terenu mam przypinane inne obiekty które są renderowane jak jest widoczny nod. Teraz jak kamerą zjedziemy tak aby teren był niewidoczny ale obiekty na nim jeszcze powinny to i tak ich niewidać. I co mam zrobić przechowywać obiekty w nowym octree czy czymś podobnym?
A nie możesz poprostu dać wyższego node'a na teren?

Pomysł wydaje się bardzo fajny. Tylko czy macie na myśli takie rozwiązanie, w którym jednakowo traktujecie np. ludziki znajdujące się w pojeździe czy na platformie, jak i części jednej postaci, np. hitboxy ludzika i trzymana przez niego broń?
Dlaczego nie? Przecież wszystkie obiekty mają wspólnego przodka.

Offline Majtek

  • Użytkownik

# Marzec 05, 2006, 16:47:21
jak będzie nod wyższy to chociaż terenu nie będzie widać to będzie on renderowany wię to troche niepasuje.

Offline SauRooN

  • Użytkownik

# Marzec 05, 2006, 17:52:15
No to tworzysz odpowiednio dużego node'a na sektor, w którym jest dany teren (i wyższy od niego), a dopiero do niego dołączasz node'a terenu i drugiego node'a, który będzie parentem dla wszystkich obiektów na tym terenie. Wtedy przy sprawdzaniu widoczności przejdziesz przez node'a sektora, a głębiej node terenu nie przejdzie testu, a node z obiektami przejdzie.

agent_J

  • Gość
# Marzec 05, 2006, 20:49:07
Pomysł wydaje się bardzo fajny. Tylko czy macie na myśli takie rozwiązanie, w którym jednakowo traktujecie np. ludziki znajdujące się w pojeździe czy na platformie, jak i części jednej postaci, np. hitboxy ludzika i trzymana przez niego broń?

Ja myślałem kiedyś o takim superogólnym rozwiązaniu, w którym świat gry byłby jedną wielką obiektową bazą danych, w której można byłoby definiować dowolne klasy, ich pola różnych typów i związki między nimi znane z obiektowości - głównie dziedziczenie i zawieranie. Oczywiście taka baza musiałaby być wydajna i jakoś tak zoptymalizowana, żeby jej czas odpowiedzi był bardzo szybki, a nie rzędu całych sekund jak w zwykłych bazach danych. Chodzi po porostu o sposób myślenia o tym. Co sądzicie o takim podejściu?

Po prostu ludzik też się może składać z node'a o typie sceny, elementy ludzika to będą podrzędne węzły, również broń będzie węzłem "przyklejonym" do łapy ludzika. Cała logika renderowania ma się opierać na węzłach, a rzeczy jak sterowanie szkieletem ludzika to kolejny moduł. Przykładowo ludzik podnosi łapę, to jeśli node broni jest "sklejony" z węzłem łapy, to broń też się odpowiednio przesunie lub obróci z łapą ludzika.
Jeśli ludzik podskoczy (cały węzeł nadrzędny), to reszta węzłów podrzędnych się automatycznie przesunie.

Offline Radko

  • Użytkownik

# Kwiecień 18, 2006, 16:47:12
Jest taka złota myśl "Object will be always an object". Oznacza to mnie więcej tyle, że jeśli masz postać, to nie twórz sztucznej hierarchi z tego powodu ze postać jest w środku samochodu. Równie dobrze możesz tworzyć hierarchie dla postaci która jest na ruchomych schodach, na ruchomej platformie, spada na spadochronie itd itp. Postać zawsze zostanie postacią. Jeśli np. jest to kabriolet, to możesz strzelić do postaci i zabić kierowcę a nie samochód. Oznacza to, że hierarchia growa zawsze jest taka sama, zawsze postać i samochód są odddzielne. Natomiast możesz wprowadzić dodatkowe hierarchie do renderingu, albo do fizyki. Wtedy 2 oddzielne obiekty są przedstawione graficznie w tym samym miejscu. Najlepiej nie łączyć hierarchii growej z renderignu. Postać można przyczepić do dowolnego punktu bez specjalnej organizacji w logice gry.


Ja myślałem kiedyś o takim superogólnym rozwiązaniu, w którym świat gry byłby jedną wielką obiektową bazą danych (...) Co sądzicie o takim podejściu?

Jest to dobre podejście, są prezentacje omawiające Dynamic Hierarchy oraz Component Centric gdzie wszystko się definiuje na podobnej zasadzie co bazy danych (ma to zwlaszcza wtedy sens gdy musimy zdefiniować 1000 różnych wersji obiektów). Ale tak jak we wszystkim, trzeba mieć umiar. Sam przez jakiś czas pracowałem nad takim mega-super-uniwersalnym enginie, gdzie wszystko może otrzymać dowolną cechę i być dowolnym dzieckiem dowolnego obiektu, ale zaczeły powstawać spore problemy z tym związane głównie związane z tym, że żeby stworzyć prosty obiekt, to trzeba mieć tytuł prof.doc.hab. Po pewnym czasie dochodzi się do prostej konkluzji, że świat zawsze pozostanie światem, postać postacią, a budynek budynkiem.


Po prostu ludzik też się może składać z node'a o typie sceny, elementy ludzika to będą podrzędne węzły, również broń będzie węzłem "przyklejonym" do łapy ludzika. Cała logika renderowania ma się opierać na węzłach, a rzeczy jak sterowanie szkieletem ludzika to kolejny moduł. Przykładowo ludzik podnosi łapę, to jeśli node broni jest "sklejony" z węzłem łapy, to broń też się odpowiednio przesunie lub obróci z łapą ludzika.
Jeśli ludzik podskoczy (cały węzeł nadrzędny), to reszta węzłów podrzędnych się automatycznie przesunie.

To że ludzik składa się z node'ów, jest dość naturalne gdyż każdy grafik będzie składac postać z jakiejś tam hierarchii typu głowa, ręka, palec itd. Ale nie łącz hierarchii wyświetlania, z hierarchią gry. Daje to zbyt duże ograniczenia. Zamiast tego, stwórz system który potrafi przypisywać dynamicznie cechy obiektom. Dla przykładu karabin na początku jest w skrzyni. Gracz może wyjąć karabin ze skrzyni i wsadzić go do ekwipunku. Karabin może też się przyczepić do pleców stanowiąc jakiś element stroju. Może też być trzymany w ręce. Ponadto karabin można poprostu wyrzucić na ziemię. To gdzie się narysuje, jest zależne od hierarchii wyświetlania, ale to co można z nim zrobić jest niezależne od wyświetlania. Karabin pozostaje karabinem niezależnie, a o tym co można w danym momencie zrobic z karabinem decyduje jego cecha użycia (karabin przyczepiony do noda "prawa_dlon" może strzelać, ale karabin przyczepiony do noda "plecy" już nie). I to cecha decyduje gdzie ma się karabin wyświetlić, a nie żeby wyświetlanie miało decydować czy można strzelać.

// EDIT by Q8 - jak to zauwazyl kolega novo nalezy edytowac posty a nie pisac kolejne pod soba
« Ostatnia zmiana: Kwiecień 18, 2006, 20:00:50 wysłana przez Queight »