Czy nadal są zalety używania gl_quads?

OK, rozumiem, że gl_quads są przestarzałe i dlatego nie powinniśmy ich więcej używać. Rozumiem również, że współczesny komputer PC podczas uruchamiania gry za pomocą gl_quads rysuje dwa trójkąty.

Teraz słyszałem, że gra powinna być napisana przy użyciu trójkątów. Zastanawiam się jednak, czy ze względu na specyfikę tego, jak OpenGL czyni ten quad na dwa trójkąty, zawsze korzystniejsze jest używanie quadów?

W szczególności renderuję obecnie wiele niepowiązanych quadów z raczej dużych obiektów buforowych. Jednym z obszarów, na które muszę uważać, jest to, jak duży wektor liczb zmiennoprzecinkowych używam do tworzenia / aktualizacji tych obiektów buforowych (mam całkiem sporo dodatkowych wartości zmiennoprzecinkowych na wierzchołek i wiele wierzchołków w buforze - największe bufory to około 500 KB).

Uderza mnie więc to, że jeśli zmienię obiekty bufora, aby narysować trójkąty, dane wierzchołków będą o 50% większe (sześć wierzchołków, aby narysować kwadrat zamiast 4), i wygenerowanie procesora zajmie o 50% więcej.

Jeśli gl_quady nadal działają, czy dostaję korzyść tutaj, czy też 50% dodatkowej pamięci i czasu procesora jest nadal wykorzystywane w automatycznej konwersji OpenGL na dwa trójkąty?

Sprawdź swoją rzeczywistą grę. Jeśli quady są szybsze, użyj ich. Jeśli nie, nie rób tego.

Można przypuszczać, że w niektórych przypadkach są one wolniejsze, ponieważ niektóre urządzenia nie obsługują quadów, więc sterownik musi wykonać wiele pracy, aby „naprawić” wywołania quadów. Niektóre urządzenia obsługują quady, dokonując podziału na trójkąty w niektórych etapach montażu wejścia o stałej funkcji, więc działa bez znacznego obciążenia. Pojawiły się również pytania dotyczące sposobu, w jaki quady są indeksowane, a nie indeksowane, jak podniesiono, i które lepiej wykorzystują ograniczoną przepustowość transferu magistrali i czas generowania procesora. Mądrość ludowa mówi, aby unikać quadów, co jest dobrą radą, jeśli zaczynasz od zera, a może nie tak bardzo, jeśli Twój kod już działa. Mądrość ludowa mówi, że wiele rzeczy zabija wydajność, pomimo tego, że robią to prawdziwe gry.

Krótko mówiąc, test. Nie zakładaj i nie proś Internetu o porady dotyczące wydajności. Czasami możemy mieć rację, ale częściej albo dostarczymy Ci nieaktualne dane, dane oparte na pewnych szczególnych okolicznościach, w których Cię nie ma, lub wręcz śmieci, które sami pozyskaliśmy z drugiej ręki z Internetu lub współpracowników (którzy sami mogą nie mieć doświadczenie z pierwszej ręki).

Jakie są alternatywy? Cóż, jedną z możliwości jest użycie Geometrów Shaderów , przechodząc przez GL_LINES_ADJACENCYprymityw (4 wierzchołki) i każąc GS przekształcić tę prymityw w pasek trójkąta. Będzie to jednak wolniejsze do renderowania, ponieważ należy założyć, że shadery geometrii są zawsze wolniejsze do renderowania.

Lepszą metodą jest użycie renderowania indeksowanego. Tutaj masz dwie możliwości: GL_TRIANGLESa GL_TRIANGLE_STRIPz prymitywnego restartu. Ten ostatni spowoduje nieco krótszy bufor indeksu (jeden indeks na każdy quad). Możesz użyć tego samego bufora indeksu do dowolnego renderowania quadów, więc nie będziesz musiał aktualizować ani modyfikować bufora indeksu.

Sugerowałbym również użycie niepodpisanych skrótów jako typu indeksu. Jeśli chcesz wyrenderować więcej niż 16384 quadów jednocześnie, wykonaj wiele wywołań renderowania, używając glDrawElementsBaseVertex, aby zrównoważyć indeksy.