jonas7 schrieb:
Dann ist es eben die Engine die bei einem statischen Level daraus 14 Dreiecke macht.
Engines die BSP Bäume verwenden tun das z.B.
Hat aber mit der GPU nix zu tun, das originale Dreieck das zerteilt wurde existiert dabei normalerweise nichtmal mehr auf dem Install-Datenträger -- es wurde im Build-Prozess des Spiels bereits vernichtet.
jonas7 schrieb:
Meine Frage ist nun, wie das bei dynamischen Objekten ist.
Und die hat dir dot beantwortet. Was war daran jetzt unverständlich?
Nochmal: abgesehen von Clipping etc. rendert die GPU einfach das was ihr gegeben wird. Durchdringungen bzw. allgemein Verdeckungen werden dabei über den Z-Buffer gehandhabt. Wenn sämtliche Dreiecke die sich einen Pixel teilen von hinten nach vorne gerendert werden, wird dabei auch wirklich für jedes Dreieck der Pixelshader neu ausgeführt.
Weswegen es sich auch auszahlen kann seine Objekte grob von vorne nach hinten zu sortieren, damit der Pixelshaderdurchlauf für die verdeckten Dreiecke über Early-Z verhindert werden kann.
Bzw. Deferred Shading schlägt in die selbe Kerbe: der erste Pass, der auch für Fragments die dann eh wieder "übermalt" werden ausgeführt werden muss, ist relativ billig. Die teuren Lichtberechnungen werden dann nur mehr für die Fragments ausgeführt die wirklich sichtbar sind.
jonas7 schrieb:
jonas7 schrieb:
Wieviele Dreiecke werden da gebildet, wenn
1. der Würfel die Fläche berührt
2. in die Fläche eintaucht?
In allen diesen Fällen immer gleich viele...
Auf dynamische Objekte bezogen?
Ja. Und auch auf statische.
Es sei denn die Engine macht da irgendwas. Und in dem Fall hinge es davon ab was die Engine genau macht.
Bei BSP kann das z.B. völlig beliebig sein. BSP zerteilt dir auch laufend Dreiecke die sich mit überhaupt nix überschneiden.
D.h. entweder ist die Antwort "es bleiben gleich viele" oder, wenn du z.B. ne BSP Engine meinst, ist die Antwort "beliebig viele, hängt ganz von der Szene ab".
