Autor Wątek: Klasy w mini frameworku  (Przeczytany 1327 razy)

Offline KeeL

  • Użytkownik

# Czerwiec 21, 2012, 00:47:53
Witam,

Mam do was mała prośbę o pomoc.
Do tej pory mam mały rozgardiasz w kodzie i nie mam pomysłu jak go uporządkować. Tak więc mam klasy:
-tekstury
-shaderów
-modelu
-kamery
I teraz tu mam do was pytanie, gdzie wy byście ustawiali zmienne uniform np dla kamery. Dodać funkcje która będzie pobierać lokacje zmiennej albo pobierać referencje do klasy shadera?
Co zrobić z macierzą modelu? Trzymać ją przy modelu i za każdą zmianą modelu zmieniać tą macierz w kamerze?

PS Wiem, że pytania są trochę głupie, aczkolwiek mam straszny rozgardiasz w kodzie i jak napisałem brak pomysłu na uporządkowanie go.
Dzięki za odpowiedz KeeL

Offline Mr. Spam

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

Offline LizarD

  • Użytkownik

  • +1
# Czerwiec 21, 2012, 01:30:47
Nie wiem czemu ale mam wrażenie że chcesz w klasach mieć pełno referencji do zmiennych, żeby nie przekazywać ich ciągle jako argumenty....
Zmienne kamery? Ja bym napisał osobną klasę reprezentującą kamerę ( ale widzę że to już masz ) w której masz metodę getMatView() getMatProj() getMatViewProj(), i przy przesyłaniu macierzy do shadera wywołujesz te metody. Jak będziesz tak korzystał z referencji to będziesz miał problem przy przełączeniu się na inną kamerę a tak wywołasz tą metodą na innym obiekcie i tyle.

Macierz modelu powinieneś trzymać w klasie modelu i aktualizować ją w przypadku zmiany pozycji, obrotu, skalowania modelu. Nie w kamerze, ta macierz modelu to chyba macierz świata, dla każdego modelu inna więc po co masz ją trzymać w kamerze, przekazuj ją do shadera przy rysowaniu modelu i tyle.

A jak to uporządkować ? Na czystej kartce A4 narysuj sobie taki schemat blokowy swojego frameworka tzn z jakich klas ma się składać, napisz sobie za to te klasy mają odpowiadać no i pisz

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

  • +1
# Czerwiec 21, 2012, 09:34:54
Wszystkie klasy jakie wypisałeś to klasy określające jakieś dane. Nie powinny więc mieć metod, które z tymi danymi nie mają dużego związku.

Tak więc:
- tekstura: powinna udostępniać id tekstury i/lub metodę do jej bindowania,
- shader: powinien udostępniać id programu i/lub metodę do jego włączenia,
- model: powinien udostępniać dane modelu, id VBO i metodę do jego przypięcia (z gl*Pointer),
- kamera: powinna udostępniać macierz i inne dane kamery (pozycja, wektory kierunkowe, frustum planes itp), zajmować się ich przeliczaniem i ewentualnie wołać glUniform (ale location podawane jest za każdym razem z zewnątrz)

Słabymi opcjami natomiast są (przykłady):
- trzymać macierz modelu w modelu (nieprzydatne, bo ta macierz ciągle się zmienia a jeden model może być wyświetlany wiele razy),
- wyciągać lokacje uniformów w klasach tekstury/kamery (to wykracza poza ich kompetencje)


Ale to tylko moje odczucie. :)

Cytuj
Co zrobić z macierzą modelu? Trzymać ją przy modelu i za każdą zmianą modelu zmieniać tą macierz w kamerze?
Ja bym jej nigdzie nie trzymał tylko produkował za każdym razem podczas renderowania kolejnych obiektów.

Cytuj
Macierz modelu powinieneś trzymać w klasie modelu i aktualizować ją w przypadku zmiany pozycji, obrotu, skalowania modelu.
Nieprawda.

Trzeba rozróżnić dwa pojęcia:
- model - dane graficzne (VB/indeksy) wyeksportowane z programu graficznego,
- obiekt - coś co występuje w świecie gry i się rysuje na ekranie, wiele obiektów może korzystać ze wspólnego modelu

Nie będziesz chyba N razy wczytywał modelu, jeżeli korzysta z niego N obiektów, nie? To trzeba rozdzielić. :)

Offline KeeL

  • Użytkownik

# Czerwiec 21, 2012, 13:17:45
@Krzysiek K.
Klasy o których wspomniałem mam mniej więcej to co napisałeś, nie które trochę bardziej rozszerzone.

Zastosuję to co napisałeś, czyli dodam metodę, która będzie przyjmowała lokalizację danej zmiennej uniform.

Hmm a co do macierzy modelu - może mi się coś uda wymyślić ;).

Offline LizarD

  • Użytkownik

# Czerwiec 21, 2012, 16:28:49
@Krzysiek K.
O to mi chodziło tylko jasno tego nie wyraziłem. Osobna klasa w której jest przechowywana siatka modelu a osobna klasa reprezentująca jakiś obiekt w świecie i ta klasa zawiera wskaźnik na obiekt klasy z siatką, i właśnie w niej trzymał bym macierz świata.

Klasa Model <- przechowuje siatkę
Klasa OBJ <- przechowuje wskaźnik na klasę Model, macierz świata i inne...