Autor Wątek: Silnik w Direct3D9, założenia  (Przeczytany 2534 razy)

Offline Oti

  • Użytkownik

# Kwiecień 10, 2011, 20:51:22
Witam. Ostatnimi czasy piszę silnik w D3D9 i właśnie dotarłem do etapu, w którym praktycznie cały rdzeń silnika jest gotowy, teraz czas na dodawanie ficzerów. Przez cały czas, kiedy pisałem ten silnik w głowie zbierały mi się pytania co do różnych zagadnień i chciałbym poznać na nie odpowiedzi:

1. Level of detail.
W jaki sposób rozwiązać spadek szczegółowości obiektów? Kazać grafikom przygotowywać różne wersje modeli pod dany poziom detali, czy zaimplementować jakiś automatyczny algorytm? To pierwsze jest bardzo kłopotliwe, a drugie, jak słyszałem, niedoskonałe-obiło mi się o uszy, że nie ma idealnego algorytmu, mogą one dziurawić i masakrować meshe. W jaki sposób Wy rozwiązaliście to w swoich silnikach?

2. Shader Model.
Piszę ten silnik na bardzo słabym komputerze, z jednordzeniowym procesorem 1.8ghz i 512 MB RAMu, w który włożyłem kilkakrotnie za dobrą kartę-GeForce 7600GS 256MB. W większości gry, które wymagają takiego procesora i takiej ilości RAMu jak u mnie potrzebują wiele słabszej karty graficznej, która w takiej sytuacji bardzo poprawia u mnie wydajność. Chciałbym, żeby mój silnik działał bezproblemowo na komputerach mniej-więcej tej samej klasy co mój i tu mam problem. Jako, że nie uśmiecha mi się pisać mechaniki silnika oddzielnie dla SM 2.0 i 3.0(wiem, większość będzie bardzo podobna, ale jednak nie wszystko uda mi się upchnąć w 'dwójce') chciałbym zapytać Was, czy shader model 3.0 jako minimalny to nie za wysoko? Czy może jednak przemęczyć się i zaimplementować obsługę obu wersji SM?

3. Post process.
W poprzednich projektach nigdy nie implementowałem żadnych efektów post process i myślę, że czas to naprawić. Generalnie mam wizję jak mógłbym to zrealizować, problem mam tylko z jednym. Zauważyłem, że w D3D9 powierzchnie tworzone jako render targety nie obsługują MSAA. Da się to jakoś ominąć? Format inny niż A8R8G8B8? Bo skończyły mi się pomysły.

To by było na tyle, choć mam wrażenie, że jeszcze o czymś zapomniałem(najwyżej dopiszę później). Z góry dzięki za wszelkie wskazówki.

Offline Mr. Spam

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

Offline pi1er

  • antyspam
  • Użytkownik
    • Mój devblog!

# Kwiecień 10, 2011, 20:59:16
Cytuj
Chciałbym, żeby mój silnik działał bezproblemowo na komputerach mniej-więcej tej samej klasy co mój i tu mam problem. Jako, że nie uśmiecha mi się pisać mechaniki silnika oddzielnie dla SM 2.0 i 3.0(wiem, większość będzie bardzo podobna, ale jednak nie wszystko uda mi się upchnąć w 'dwójce') chciałbym zapytać Was, czy shader model 3.0 jako minimalny to nie za wysoko? Czy może jednak przemęczyć się i zaimplementować obsługę obu wersji SM?

Sam siedzę na kompie ze zintegrowanym GMAx3100, który ma Shadery 2.0. Przyznam szczerze, że większość gier właśnie przez to mi nie działa. Jednak jestem zdania, że nie ma co się przejmować starymi kartami graficznymi. IMO powinieneś śmiało iść w SM 3.0 i olać 2.0.

Offline rm-f

  • Użytkownik
    • Tu trolluje

# Kwiecień 10, 2011, 21:36:20
Wszystko zależy jaką grę robisz... powiedz to się coś podpowie.


Cytuj
Sam siedzę na kompie ze zintegrowanym GMAx3100, który ma Shadery 2.0.
3.0 na Viście :-)

A tu linuxowe info: glewinfo/glxinfo
http://www.nopaste.pl/10cv
http://www.nopaste.pl/10cx
« Ostatnia zmiana: Kwiecień 10, 2011, 21:38:44 wysłana przez świrus »

Offline Oti

  • Użytkownik

# Kwiecień 11, 2011, 10:14:02
Wszystko zależy jaką grę robisz... powiedz to się coś podpowie.
Póki co nie robię żadnej gry, najpierw wziąłem się za silnik pod nią. Planowałem coś robić, ale teraz nie jestem pewien czy będzie mi się chciało robić coś tak prostego. Może zrobię jakąś samochodówkę, czy coś. Serio, jeszcze nie wiem. Mogę powiedzieć, jakie ficzery chcę mieć silniku:

Cytuj
postprocess: bloom, gaussian blur, motion blur i inne prostsze efekty(monochrome, edge detection), wczytywanie meshy z OBJ i z wlasnego, prostego formatu, meshe z obsluga wielu materialow, normal mapping: parallax i bump, odbicia plaszczyznowe i szescienne, specular mapy, oswietlenie per pixel dla wszystkich 3 rodzajow swiate, miekkie cienie(SM+PCF, dla swiatel kierunkowych CSM a dla punktowych cubic shadow mapping), kilka wygodnych w uzyciu rodzajow kamery(FPP, TPP, statyczna, jakas animacyjna oparta na krzywych beziera), konsola i wpisywanie do niej komend, miekkie, oswietlone particle, jezyk skryptowy, filtrowanie anizotropowe i mipmapy
Część jest, na część mam już jakąś wizję, a nad resztą będę jeszcze główkował. Ale tak jak teraz patrzę na tą rozpiskę, to chyba nie ma opcji zrealizowania tych rzeczy na SM 2.0(chodzi mi o oświetlenie, miekkie cienie i normal mapping w jednym pixel shaderze), więc raczej ograniczę się do 3.0. Nadal jednak chciałbym poznać odpowiedzi na pozostałe pytania.

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Kwiecień 11, 2011, 10:35:46
LoD lepiej chyba zrobić "ręcznie", to znaczy przygotowywać osobne siatki dla niższych poziomów szczegółowości. Ewentualnie można potem te siatki zrobić jakimś algorytmem czy to w programie do modelowania typu 3ds Max, czy w twoim własnym, specjalnym programie. Tak czy inaczej nie ma chyba sensu wbudowywać upraszczania siatek do silnika gry.

Shader Model 3 jako minimalne wymaganie sprzętowe moim zdaniem będzie OK. Mam wrażenie, że większość obecnie wydawanych gier ma właśnie takie. W razie wątpliwości co do tego, jaki sprzęt mają obecnie gracze PC, zawsze warto zajrzeć do aktualnej wersji Steam Hardware Survey:
http://store.steampowered.com/hwsurvey

Offline Pomnico

  • Użytkownik
    • Magic-Ars

# Kwiecień 11, 2011, 10:45:50
To czy jest sens robić wsparcie dla starszych kart graficznych zależy od tego, jakiego typu gierki masz zamiar na nim robić. Jeśli celujesz w gry typu casual, wówczas wsparcie dla SM 2.0 wydaje mi się obowiązkowe. Po prostu duży procent osób grających w takie gry ma słabe, często zintegrowane karty graficzne.

Offline niby_koder

  • Użytkownik

# Kwiecień 11, 2011, 14:56:53
1. Przydałby się wbudowany w silnik algorytm zmniejszania szczegółowości (gęstości) siatki.
2. Nie ma co siedzieć na SM 2.0. Z tego co wiem to teraz wszystkie gry wykorzystują tą właśnie wersje 3.0 jako minimalną, a z resztą SM 3.0 jest bardziej rozbudowany i zawiera znacznie ciekawsze efekty.
3. A lookałeś do dokumentacji direx'a może tam coś o tym piszą.

Pozdrawiam

Offline Pomnico

  • Użytkownik
    • Magic-Ars

# Kwiecień 11, 2011, 15:17:24
Na rynku AAA - jak najbardziej, a 3.0 a nie wyższy to chyba tylko dlatego że na Windows XP nie ma wsparcia dla DirectX obsługującego SM > 3.0. Jednak w przypadku gier typu casual tendencja jest trochę inna. Tutaj można sobie zobaczyć statystyki użycia Unity3D (dość popularny silnik):
http://unity3d.com/webplayer/hwstats/pages/web-2010Q2-shadergen.html
wynika z nich że w ponad 40% przypadków obsługiwany SM < 3.0, natomiast w 15% SM < 2.0.
Nie są to co prawda statystyki graczy casual, jednak tacy gracze mają zazwyczaj najstarsze generacje sprzętu.

Jeszcze raz powtarzam - wszystko zależy od tego, do kogo chce się kierować swój produkt.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Kwiecień 11, 2011, 16:57:25
Cytuj
Zauważyłem, że w D3D9 powierzchnie tworzone jako render targety nie obsługują MSAA. Da się to jakoś ominąć?
Definitywnie obsługują (o ile w ogóle karta to obsługuje). Może zrobiłeś coś nietypowego w tym przypadku? (np. próbowałeś tworzyć RT jako teksturę, zamiast jako zwykły surface)

Cytuj
Czy może jednak przemęczyć się i zaimplementować obsługę obu wersji SM?
Proste rozwiązanie: implementujesz podstawową funkcjonalność w SM 2.0, a zbędne bajery możesz robić w 3.0. W końcu kto mówił, że wersji shaderów nie można mieszać ze sobą?

Offline Oti

  • Użytkownik

# Kwiecień 11, 2011, 17:25:08
Cytuj
Zauważyłem, że w D3D9 powierzchnie tworzone jako render targety nie obsługują MSAA. Da się to jakoś ominąć?
Definitywnie obsługują (o ile w ogóle karta to obsługuje). Może zrobiłeś coś nietypowego w tym przypadku? (np. próbowałeś tworzyć RT jako teksturę, zamiast jako zwykły surface)
Tak, tworzyłem RT jako teksturę i nie do końca rozumiem po co mógłym tworzyć render target bez tekstury(Bo generalnie z tego co wiem, to RT tworzy się, by móc potem jego zawartość na coś nałożyć, np. na full-screen quad w przypadku post processu). Zawsze tworzę teksturę, a później 'podpinam' pod nią powierzchnię.

Cytuj
Czy może jednak przemęczyć się i zaimplementować obsługę obu wersji SM?
Proste rozwiązanie: implementujesz podstawową funkcjonalność w SM 2.0, a zbędne bajery możesz robić w 3.0. W końcu kto mówił, że wersji shaderów nie można mieszać ze sobą?
Problem może być w tym, że zdecydowałem się korzystać z jednego, dużego shadera podzielonego przy użyciu preprocesora(metoda opisana przez Rega tutaj: http://warsztat.gd/articles.php?x=view&id=271 ), musiałbym tworzyć wtedy dwa takie duże shadery(choć tak na dobrą sprawę to duży byłby tylko ten od 3.0, z drugim może nie byłoby takiego wielkiego problemu).

A jeśli chodzi o odbiorców moich gier, to chciałem napisać na tym silniku jakieś casuale(jakaś prosta gra w bilard na początek, a później chciałem zrobić drugą, lepszą część brick breakera 3d, czyli projekty które mają realną szansę zostać ukończone przez jednoosobowy zespół), ale jednak chciałbym zrobić jakiś progress i myślałem nad stworzeniem samochodówki 3D(trudny projekt i wątpię, że udałoby mi się go skończyć, ale jednak myślę, że warto by było spróbować), albo jakiegoś FPSa, ale problemem może być to, że w silniku nie mam zaimplementowanej żadnej animacji ani specjalnie nie ciągnie mnie do robienia jej(głównie przez zaawansowaną matematykę przy animacji na kościach)-może w następnej generacji silnika, bo jak znam życie, to po zrobieniu maksymalnie kilku gier i tak będę musiał/chciał napisać lepszy silnik.

LoD lepiej chyba zrobić "ręcznie", to znaczy przygotowywać osobne siatki dla niższych poziomów szczegółowości. Ewentualnie można potem te siatki zrobić jakimś algorytmem czy to w programie do modelowania typu 3ds Max, czy w twoim własnym, specjalnym programie. Tak czy inaczej nie ma chyba sensu wbudowywać upraszczania siatek do silnika gry.
Ok, dzięki, tak zrobię. :)

Offline K'Aviash

  • Użytkownik

# Kwiecień 11, 2011, 18:55:01
Problem może być w tym, że zdecydowałem się korzystać z jednego, dużego shadera podzielonego przy użyciu preprocesora(metoda opisana przez Rega tutaj: http://warsztat.gd/articles.php?x=view&id=271 ), musiałbym tworzyć wtedy dwa takie duże shadery(choć tak na dobrą sprawę to duży byłby tylko ten od 3.0, z drugim może nie byłoby takiego wielkiego problemu).
Zawsze możesz przepisac ;)

Offline Dab

  • Redaktor
    • blog

# Kwiecień 11, 2011, 21:38:27
Przede wszystkim zdecyduj się co chcesz robić. Po liście proponowanych ficzerów wygląda mi to raczej na BBB (czyli AAA w warunkach domowych) -- jeżeli tak to nie ma się co pchać w SM 2.0, zresztą osobiście bym nie schodził nawet poniżej OpenGL 3/DX10.

Jeżeli casuale to w ogóle shadery olać albo dać je jako opcję (np. jakiś ekstra postprocess). Natomiast w casualowym silniku ważniejsze jest wsparcie innych platform (Mac/Linux/mobilne), toteż postawiłbym zdecydowanie na OpenGL (kompatybilnym z OpenGL ES), ew. z wsparciem DX9 dla deakceleratorów Intela.

Offline Oti

  • Użytkownik

# Kwiecień 11, 2011, 22:02:01
zresztą osobiście bym nie schodził nawet poniżej OpenGL 3/DX10.
No ja też chętnie pisałbym już w czymś nowszym niż DX9, ale niestety aktualnie nie mam możlwości finansowych by wejść w posiadanie komputera obsługującego coś nowszego(i na takową możliwość póki co się nie zanosi). Ale myślę, że nie marnuję czasu pisząc w 'dziewiątce'.

Jeżeli casuale to w ogóle shadery olać albo dać je jako opcję (np. jakiś ekstra postprocess). Natomiast w casualowym silniku ważniejsze jest wsparcie innych platform (Mac/Linux/mobilne), toteż postawiłbym zdecydowanie na OpenGL (kompatybilnym z OpenGL ES), ew. z wsparciem DX9 dla deakceleratorów Intela.
Aha, to widzę, że póki co nie wejdę na rynek casuali. ;) Bo jakoś nie lubię babrać się ze zmianami API, testowaniem aplikacji na różnych platformach, etc. Dzięki za informacje.

Offline Limal

  • Użytkownik
    • http://wolnik.co.uk

# Kwiecień 11, 2011, 22:36:12
Oti, nie przejmuj się. Jesteś w doborowym towarzystwie. Wiedźmin 2 używa DirectX 9.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Kwiecień 11, 2011, 23:46:28
Cytuj
Tak, tworzyłem RT jako teksturę i nie do końca rozumiem po co mógłym tworzyć render target bez tekstury(Bo generalnie z tego co wiem, to RT tworzy się, by móc potem jego zawartość na coś nałożyć, np. na full-screen quad w przypadku post processu).
Jeżeli nie ma MSAA, to możesz robić od razu RT jako teksturę. Jeżeli MSAA jest, to nie możesz, bo tekstury w DX9 nie mogą być multisamplowane (teksel to jeden kolor, a nie kilka próbek). Żeby postprocessować MSAA musisz zrobić rendertarget jako zwykły surface, wyrenderować do niego, a potem zrobić StretchRect do tekstury o takim samym rozmiarze. Podczas StretchRect nastąpi tzw. resolve (próbki MSAA zostaną połączone w jeden kolor) i wynik, już nie multisamplowany, będzie gotowy do użycia w teksturze.

Cytuj
Zawsze tworzę teksturę, a później 'podpinam' pod nią powierzchnię.
Powierzchnie tworzą się same przy tworzeniu tekstury.