Czy sensowne jest zaimplementowanie logiki, aby pomijać renderowanie obiektów poza rzutnią, czy też nie powinienem się tym przejmować i pozwolić na to Frameworkowi?
Culling to optymalizacja wydajności. Więc nie ma sensu robić tego tylko ze względu na to. Musisz mieć powód.
GPU (nie XNA Framework) wycina trójkąty i piksele z oślepiająco dużą prędkością. Każdy przesłany trójkąt musi zostać przekształcony (za pomocą modułu cieniującego wierzchołki). Następnie eliminuje te, które wylądują poza ekranem. Następnie wypełnia pozostałe trójkąty, eliminując piksele poza ekranem. Pozostałe piksele są następnie rysowane do bufora tylnego (za pomocą modułu cieniującego piksele).
(Kiedy mówię „wtedy” - robi to wszystko w ogromnie równoległym rurociągu.)
Jest więc bardzo rzadkie i niezwykłe, że może być konieczne wybicie poszczególnych trójkątów. Aby osiągnąć granice wierzchołków, musisz narysować absurdalnie dużą liczbę trójkątów. Aby osiągnąć limity wypełnienia, pobierania tekstur lub cieniowania pikseli, zazwyczaj musisz mieć wysoką złożoność głębi (w takim przypadku wybijanie okienka / wycięcie fragmentu nie pomoże).
Tak więc zazwyczaj geometria poza ekranem jest niewielka lub żadna.
Koszt - szczególnie w kontekście rysowania „obiektów” (zwykle obiektów 3D) - w rzeczywistości polega na przesłaniu tych obiektów do GPU . Prześlij zbyt wiele obiektów, a osiągniesz limit partii (dostajesz kilka tysięcy * partii na ramkę).
Polecam przeczytanie tej odpowiedzi i połączonego pokładu slajdów, aby uzyskać dokładny opis partii.
Z tego powodu, jeśli wdrożysz custing frustum, możesz zmniejszyć liczbę partii przesyłanych do GPU. Jeśli masz ograniczoną partię - może to przekroczyć limit.
Teraz - twoje pytanie dotyczy 2D XNA - więc prawdopodobnie używasz SpriteBatch. To jest trochę inne.
Nie jest błędem, że nazywa się to „Sprite Batch ”. Zajmuje się rysowaniem duszków i robieniem wszystkiego, co w ich mocy, aby przesyłać te duszki do GPU w jak najmniejszej liczbie partii, łącząc je razem.
Ale SpriteBatch będzie zmuszony rozpocząć nową partię, jeśli:
Więc wybijanie jest odpowiednią optymalizacją, jeśli wybierasz się do pierwszej. Jeśli wysyłasz tak dużą liczbę duszków, że kończy się to zbyt dużą ilością partii (prawdopodobnie również zużywasz przepustowość - ale jestem pewien, że najpierw przekroczysz limit partii). Zasadniczo dzieje się tak tylko wtedy, gdy masz naprawdę ogromny świat - dzięki czemu możesz na ogół uciec od bardzo uproszczonego, szybkiego, ale niedokładnego wybijania w tym przypadku.
Teraz - jeśli rysujesz z wystarczającą liczbą zamian tekstur, aby przekroczyć limit partii, a wiele z nich faktycznie znajduje się poza ekranem, a wyrzucenie ich spowoduje przekroczenie limitu partii. Zatem tak - culling to optymalizacja, która zadziała.
Jednak - w tym przypadku lepszą optymalizacją jest zastosowanie atlasów tekstur (aka: arkuszy sprite). Pozwala to zmniejszyć liczbę zamian tekstur, a tym samym partii - niezależnie od tego, co jest wyświetlane na ekranie lub wyłączone. (To jest główny powód, dla którego możesz określić źródłowy prostokąt dla swoich duszków).
(Jak zawsze: jest to wskazówka na temat optymalizacji wydajności. Dlatego powinieneś zmierzyć i zrozumieć własną wydajność gry oraz jakie ograniczenia przekraczasz, zanim wydasz wysiłek na dodanie optymalizacji).
Zgodnie z postem na forach MSDN, środowisko XNA nie wykonuje usuwania frustum:
http://xboxforums.create.msdn.com/forums/p/22763/121897.aspx
Ten post mówi dalej, że jeśli masz wiele obiektów na scenie, warto je rozwinąć.
źródło
Od kilku lat pracuję nad silnikami wokselowymi proceduralnymi w XNA. W większości ramek silniki przekształcają dosłownie setki tysięcy quadów. W moim profilowaniu zauważyłem, że wygładzanie frustum i okluzji powoduje wzrost wydajności.
Profil XNA HiDef (nie Reach) ma klasę OcclusionQuery, która służy do wykonywania Culling okluzji. Culling okluzji usuwa te kwadraty z okienka ekranu, które są ukryte przed innymi quadami.
Inną rzeczą, którą powinieneś wziąć pod uwagę, jest osobne wprowadzanie generacji i mozaiki.
Tak więc, gdy zbliżasz się do bardzo dużej liczby quadów w każdej transformowanej ramce, musisz dokładnie przemyśleć, w jaki sposób możesz zastosować techniki wycinania i wątkowania w celu utrzymania częstotliwości klatek, zmniejszając ruch do shaderów GPU.
źródło