Jak mogę używać wielu siatek na jednostkę bez rozbijania jednego elementu jednego typu na jednostkę?

11

Właśnie zmieniamy silnik gry oparty na hierarchii na silnik gry oparty na komponentach. Mój problem polega na tym, że kiedy ładuję model, który ma hierarchię siatek, i rozumiem, że jednostka w systemie opartym na komponentach nie może mieć wielu komponentów tego samego typu, ale potrzebuję „meshComponent” dla każdego siatka w modelu. Jak więc mogę rozwiązać ten problem?

Na tej stronie wdrożyli silnik gry oparty na komponentach: http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

architecture component-based

— Mathias Hölzl
źródło

Myślę, że to jest zbyt zlokalizowane.

— jcora

4

Myślę, że to ogólne pytanie. Czy obiekt gry może mieć wiele instancji tego samego komponentu?

— Mathias Hölzl

Tak, mogłoby być, gdyby tak zapytano. Wydaje mi się, że szukał odpowiedzi na bardzo konkretny problem.

— jcora

4

„... jednostka w systemie opartym na komponentach nie może mieć wielu komponentów tego samego typu ...” - dlaczego nie?

— Den

Nie wydaje mi się, żeby to było zbyt zlokalizowane. Na przykład w UE3 SkeletalMeshActorma tylko jeden SkeletalMeshComponent. Jest to powszechny problem, który można rozwiązać na wiele różnych sposobów.

— sam hocevar,

13

Komponent Pozycja może mieć logikę „rodzic / potomek”, w której jakakolwiek Istota z Pozycją może mieć rodzica, a ich pozycja jest względem ich rodzica. Zamiast mieć kilka siatek na tej samej encji, możesz utworzyć więcej niż jedną encję, każda z własną siatką i połączyć je ze sobą. Możesz nawet zmusić dzieci-byty do słuchania ich wydarzeń nadrzędnych (lub dowolnego innego systemu komunikacji między jednostkami) i odpowiednio zareagować.

— Łukasz B.
źródło

Mam więc hierarchię bytów, które mają składniki i są połączone z nimi. Czy nadal jest to silnik gry oparty na komponentach =)

— Mathias Hölzl

@ MathiasHölzl to pytanie? Ten rodzaj hierarchii nie jest tym samym, co problematyczna hierarchia w OOP. To tylko graficzna hierarchia, encje podrzędne nie odziedziczą funkcjonalności po rodzicach i nie sprawią ci kłopotów, zwykle tak jest i tak (z drzewem rzeczy do renderowania). Możesz również przejść z odpowiedzią Asakerona na twój problem, mając listę siatek, nie rozumiem, jak to jest problematyczne. Może nie rozumiem twojego pytania?

— Łukasz B.

-1 Nie jestem pewien, czy tak naprawdę należy. Jeśli potrzebujesz komponentu obsługującego hierarchię siatek, dlaczego nie mieć takiej, ModelComponentktóra zawiera hierarchię siatek? Podział bytu tylko na to brzmi jak złe rozwiązanie problemu. Zobacz odpowiedzi Asakerona i Byte56.

— Laurent Couvidou

@LaurentCouvidou Nie rozumiem, dlaczego używanie więcej niż jednego Podmiotu byłoby niewłaściwe, wydaje mi się, że to dobre rozwiązanie dla mnie. Chciałem tylko podać inną alternatywę niż listę siatek, choć zgadzam się, że lista siatek również byłaby dobrym rozwiązaniem.

— Łukasz B.

@LukeB. Ponieważ ta grupa siatki może odpowiadać jednemu bytowi jako całości, z komponentami zależnymi od tego, np. AI, dźwięk, fizyka ... W ten sposób otrzymujesz wykres sceny i wszystkie jego dziwactwa.

— Laurent Couvidou

8

Twój meshComponent może zawierać listę oczek. Nie jestem pewien, jak wdrażasz silnik, ale system może łatwo iterować wszystkie siatki i po prostu je rysować.

— Asakeron
źródło

1

Siatka ma również takie elementy, jak transformacja, fizyka, grafika ...

— Mathias Hölzl

1

Więc siatka jest bytem? Czy wszystko jest częścią? Moim zdaniem, transformacja, fizyka i grafika powinny być komponentami bytu, a nie siatki, siatka jest jedynie opisem wierzchołków.

— Łukasz B.

1

Tak, powinien to być komponent, ale komponenty nie mogą mieć komponentów, więc trudno jest wdrożyć hierarchię modelu.

— Mathias Hölzl

1

Uważam, że powinieneś podać więcej informacji o tym, jak zamierzasz zbudować silnik, aby uzyskać lepsze odpowiedzi. Systemy elementów encji można wdrażać na wiele sposobów, sprawdź tę odpowiedź przez Kylotan, aby uzyskać więcej informacji na ten temat.

— Asakeron

4

Utworzyłbym mój komponent siatki z listą obiektów siatki. Każdy obiekt siatki ma dane siatki wraz z odsunięciem. Podczas rysowania system rysowania przyjmuje pozycję z komponentu pozycji, a następnie rysuje każdą siatkę w komponencie siatki w pozycji + przesunięcie.

Możesz mieć wiele siatek wewnątrz komponentu siatki, jednocześnie mówiąc z jednym komponentem siatki na jednostkę.

— MichaelHouse
źródło

1

TLDR: Na początek komponent składa się z wielu siatek.

Zgadzam się z Asakeron / Byte56 / Laurent, że potrzebny jest inny poziom pośrednictwa między parami siatka / materiał a samą istotą. Zamiast patrzeć na GraphicsComponent jako wierzchołki i materiały, pomyśl o nim jak o kropli pikseli na końcowym rastrze - to, jak się tam dostanie, jest szczegółem implementacji i niczym więcej.

Dużo o tym myślałem w moim projekcie i myślę, że optymalnym rozwiązaniem jest uczynienie GraphicsComponent składnikiem o wiele wyższym, obejmującym większość funkcjonalności tradycyjnego obiektu „Model” - ponieważ ta funkcja nie jest opcjonalna! Aby renderować te wielokąty o wiele więcej niż tylko dane buforowe, potrzebny jest moduł cieniujący, taki jak:

Pozycja, o której wspomniałeś
Dane skórowania / animacji
Aktualny przebieg (np. Jeśli używasz dwuprzebiegowego alfa)
Informacje o rzucaniu cienia (jeśli to robisz)
Informacje o tym, jak i kiedy aktualizować materiał
Funkcja wyrównywania

Dotyczy to tylko zasobów 3D, bez uwzględnienia układów cząsteczkowych, billboardów itp. Ale wszystko to dotyczy tylko grafiki / kodu renderującego - nie wpływa na fizykę, dźwięk ani skrypty, więc ma sens komponent Grafika / Rendering.

Skończyło się na:

Model : Entity, IHasGraphicsComponent, IHasSkeleton, IHasAnimationStore     //This is the 'game object' - it is passed to the GraphicsController
    ModelComponent : GraphicsComponent                      //This is the actual graphics component, used by the GraphicsController in the context of the game object.
        ModelComponentPart : GraphicsComponent              //This is also a graphics component
            Mesh                                        //These are implementation details
            Material
        ModelComponentPart : GraphicsComponent
            Mesh
            Material
    Skeleton
    Animations

W tym:

Model to dowolny zasób gry, który ma komponent graficzny.
ModelComponent jest analogiczny do tradycyjnego modelu i tak naprawdę jest w przypadku zasobów 3D. Kontroler GraphicsComponent (jeśli używasz wzorca Model-Widok-Kontroler) jest odpowiedzialny za ustalenie rodzaju zasobu graficznego i prawidłowe rysowanie (zwróć uwagę, że ModelComponent jest podklasą GraphicsComponent).

W moim przypadku było też kilka kompromisów dotyczących prostoty i wstecznej kompatybilności, ponieważ każdy GraphicsComponent jest również Entity, a Entity przechowuje dane pozycji bezpośrednio, więc są obliczane tylko w jednym miejscu, ale idea jest taka sama: GraphicsComponent obsługuje to, co jest potrzebne do narysowania przedmiotu - wszystkiego, co jest potrzebne - nie tylko tego, co pochodzi od modelarza.

— sebf
źródło