an welcher Stelle im Programm findet das Culling statt?
-
jo, ich sitz hier grad an nem schönen brainstorming, und frag mich, an welcher stelle im programm das culling auf die Objekte angewendet wird.
werden die objekte direkt dem culling unterzogen, nachdem die programmlogik sie übergeben hat? oder Wird das einzelne Objekt erst gecullt, wenn der Indexbuffer zum zeichnen angefordert wird?
oder ganz woanders? oder beides?(erst ein primäres culling, ob das objekt Überhaupt sichtbar ist,wenn nicht, sofort verwerfen,und dann kurz vor dem zeichenvogang ein genaueres culling)?
ist es überhaupt so wichtig, wo man culling betreibt, oder reicht einfach die tatsache, dass objekte gecullt werden, bevor die graka sich drum kümmern muss?
-
Eine allgemeingültige Antwort wird es hier wohl nicht geben. Aber ich denke Backface-Culling wird am sinnvollsten an den folgenden Zeitpunkten ausgeführt:
-
Nach der View Projection und dem Reject Culling (ob alle Vertices eines Dreiecks außerhalb einer Seite des View-Frustums liegen) vollzogen
-
Zu Beginn des Triangle Setups
Ich denke, es ist für den Entwickler nicht so wichtig, WANN genau das Culling durchgeführt wird - die Architekten der jeweiligen Hardware werden das schon effizient implementiert haben.
-
-
es geht um softwareseitiges culling, nicht um hardwareseitiges(sorry, wenns nich so ganz klar wurde).
Man übergibt der hardware nich so ebend 200000 Dreiecke und sagt mach du mal^^
-
allgemein gesagt sollte man culling so früh wie möglich durchführen. denn man sparrt sich viele folgeberechnungen.
bsp.
1. man kann alles nicht reinladen was z.b. 2*sichtweite (der kamera) weit weg ist und den zur verfügung stehenden speicher für die nahe dinge opfern. (range culling) oder indem man die level in sektoren aufteilt und nur die nahesten reinlädt (sehr gut zu sehen bei "Baldurs Gate Dark Alliance", weil dort die sektoren manchmal sogar erst nachgeladen werden, wenn sie schon im frustum sein sollten und man deswegen "popping" sieht)
2. man kann danach erstmal alle objekte die kreisförmig um das view-frustum sind heraus'picken', das kann man z.b. mittesl eine sphere machen, sieh auch flipcode
3. danach kann man für die übrigen objekte ein frustum-culling durchführen.
4. für die jetzt noch gebliebenen könnte man einen software occlusion culler nutzen um alle objekte die auf jeden fall nicht zu sehen sein werden noch rauszuwerfen.
5. nach der transformation der objekte kann man nun mittesl backface culling die rückseiten-polygone entfernen (lustigerweise ist das laut nvidia in naher zukunft nicht mehr so sehr für die verminderung vom overdraw wichtig, sondern damit das Triangle-setup entlastet wird, weil es immer mehr pipes für VS und PS gibt, aber immer noch nur ein TriangleSetup.)
6. nun führt man auf den einzelnen pixeln ein z-occlusion culling durch, das machen ATI karten mittels eines hierarchischen z-buffers und nvidia karten mittels vieler z-check-pipes (immerhin 32pixel/takt)
7. was auch immer an pixel jetzt noch bleibt, es wird durch die "tapezierungs" geschoben. also z.b. pixelshader oder auch nur die texture combiner.
natürlich ist das nur ein möglicher weg das zu lösen, eine portalengine führt vieles anders aus als eine raytracing engine...
wichtig ist, wie ich im ersten satz sagte, dass man so früh wie möglich, so billig wie mögilch, unnötige dinge von den folgenden stages einer rendering pipeline fernhällt, denn schlussendlich würde vielleicht nur der z-buffer und das trianglesetup für das culling ausreichen, aber die effiziens würde meißtens extrem niedrig sein in relation zum oben beschriebenen.
rapso->greets();
-
ich habs mir auch so ähnlich vorgestellt:
ich übergeb ein objekt mit den daten der view matrix(ob schon als matrix oder noch basisdaten weis ich nicht, muss ich ma schaun womit man besser rechnen kann) und die einzelnen modelldaten der grafike engine.
dann werden die einzelnen objekte mittels frustum culling gecullt.nun die frage, da ich ein modulares system machen will,muss ich wissen, wo ich in etwa den rest des cullings hinverlegen soll(in bezug auf shadow Volume Mapping,ich darf zb kein backface culling durchführen,bevor die shadow volumes durch sind).
-
rapso schrieb:
allgemein gesagt sollte man culling so früh wie möglich durchführen. denn man sparrt sich viele folgeberechnungen.
Um das evtl. etwas zu präzisieren: Man sollte alles wegcullen, bei dem Folgeberechnungen aufwendiger sind, als der Culling-Test.
Bye, TGGC \-/
-
ähm zu punkt 5 noch ne frage: was meinst du mit transformation? sollte man sozusagen die objekte schon drehen? frisst das nicht verdammt viel zeit?
-
otze schrieb:
ähm zu punkt 5 noch ne frage: was meinst du mit transformation? sollte man sozusagen die objekte schon drehen? frisst das nicht verdammt viel zeit?
damit meine ich
for_each vertex in object vertexdest = transformmatrix * vertexsource;das zieht eine matrix * vertex multiplikation pro vertex.
ich weiß aber nicht genau was du mit "verdammt viel zeit" meinst... alles zieht zeit, verdammt viel in relation zu was? und was dachtest du, dass als alternative gemacht werden sollte?
rapso->greets();
-
ich dachte eigentlich immer, dass beim zeichnen das untransformierte modell +transformationsmatrix*worldmatrix übergeben wird, weil das ja "kostenlos" ist,da die grafikkarte die vertices eh transformiert,auch wenns nur ne transformation mit der identitätsmatrix ist.
und verglichen dazu ist halt die software transformation teuer.
-
ab dem transformieren passiert ja auch alles in hardware, also backface culling. ich wollte nur noch erwähnen wann genau das passiert
punkt 5 ist also schon komplett hardware
rapso->greets();
-
ahso, dachte erst ab 6, weil backface culling auch gut in software durchzuführen ist
