[Projekt] StoneQuest lebt noch!

[Schrompf]

Vielleicht findest Du dafür ja ne schicke Lösung. Ich weiß noch aus Splitterwelten-Zeiten, dass Blocker und Portale ne empfindliche Sache sind, die wir mit viel Augenmaß und Feingefühl von Hand platziert haben, damit sie was bringen. Sobald es nur ein paar zuviele werden, kostete es mehr, als es brachte. Du hast zusätzlich das Problem, dass Du auf nahezu beliebigen Raumstrukturen arbeiten musst.

Wobei mir jetzt nach all den Jahren einfällt, dass ich wahrscheinlich auch ein paar 2D-projezierte Testpunkte gegen die 2D-Projektionen aller Occluder hätte testen können. Ich habe damals Silhouetten-Kanten identifiziert, daraus Grenzebenen extrudiert und dann gegen die getestet. Das System war extrem empfindlich gegen "innere" Kanten z.b. zwischen zwei Occludern mit Kontakt zueinander. Man hat z.B. zwei Occluder-Würfel aneinander gesetzt und musste sorgfältig manuell die Kanten markieren, damit die Kante dazwischen keinen schmalen Spalt Sichtbarkeit produziert.

[Zudomon]

Silhouetten-Kanten suche ich bei mir auch für die Occluder-Würfel.
Also in der aktuellen Einstellung im Screen (ohne das Debug rendering usw.) komme ich auf 235 FPS. Mit Occlusion Culling sind es (noch) 135 FPS. In dem Frame sind 98 Occluder aktiv.
Ohne Occlusion sind es etwa 3490 Patches im Frame, mit dann 1710. Das große Problem ist die Menge der Occluder. Weil diese sich ja mit der Anzahl der Patches quadrieren.
Resultiert in 342.020 Tests (Brush gegen Box) für den Frame.

Ich sehe zur Zeit noch 3 große Optimierungsfelder:

1. Reduzieren und verbessern der Occluder
2. Statt gegen einzelne Patches dann ganze Gruppen zu prüfen
3. Auf mehrere Frames verteilen. Da das ganze im Worldspace stattfindet könnte man eventuell sogar im Vorfeld ringsrum schon occluden

Vielleicht gibt es ja auch noch einen Weg, Occluder zu kombinieren, aber ohne die in einen Z-Buffer zu rendern, fällt mir da momentan nichts ein.

Ich bin mir ziemlich sicher, dass der Overhead durch 1-3 extrem reduziert werden kann. Aber selbst wenn die FPS sich nicht ändern sollten, bringt mir das Occlusion Culling den Vorteil, dass es die Anzahl der Patches erheblich reduziert. Da ja jeder Patch eine eigene Textur verwendet, die auch gemanaged und upgedated werden muss, würde zumindest Speicher und Mikrolags reduziert.

EDIT: 2. könnte man sogar noch zu einer umgekehrten Form erweitern... nicht nur die Patches gruppieren, sondern auch die Occluder.

[Zudomon]

Ich hatte nun mit dem zusammenfassen von Occludern begonnen... zu jedem eine Art Screen Boundingbox, wobei ich nicht wirklich im Screenspace umgerechnet habe, nur das dot Produkt der Kamera X und Y Achse. Dann habe ich den Screen in 3x4 Felder aufgeteilt und die Cluster, die da rein fallen benutzt. Durch die Größe hat sich die Menge der Occluder letztendlich aber nur 1/3 bis 1/2. Das gleicht gerade so den Overhead aus. Da hatte ich mir wesentlich mehr versprochen.
Wenn man nun den Screen noch weiter unterteilt, dann könnte man schon fast für jedes kleine Feld schauen, welche Occluder da drin liegen. Wenn man statt das äußere das innere nimmt. Jedenfalls würde das dann doch zu einer Art Z-Buffer mutieren und da ist dann die Frage, ob man es nicht doch probieren sollte. Z-Buffer würde ja bedeuten, dass man im ersten Schritt alle Occluder da rein rendert, im zweiten diesen abtastet. Die Occluder wären kombiniert und was mich eigentlich dann doch motiviert in diese Richtung zu gehen ist, dass man das Occluder * Patches auflöst in Occluder + Patches. Mal gucken...

[Schrompf]

Joa, ein heftiges Thema. Viel Erfolg.

[Zudomon]

Joa, ein heftiges Thema. Viel Erfolg.

Danke!
Ja, vor allem ist die Vorarbeit irgendwie wieder nervig. Bevor ich überhaupt rasterizieren kann, muss ich irgendwie Pixel in einen Buffer bekommen. Damit das nicht ganz blind passiert, und ich vor allem auch sehen kann, ob die Boxen auch die richtige Stelle im Buffer treffen, ist es sinnvoll, diesen auch anzuzeigen.
Der Einfachheit halber also erstmal eine Textur genommen und Fullscreen drüber gerendert. Die wird auch schon per Frame mit einem Zufallsrauschen aktualisiert. Hört sich jetzt eigentlich gar nicht nach so viel Vorarbeit an. :lol: Aber man muss ja erst immer dahin kommen. Zuerst hatte ich "einfach" eine Box als Pixel malen wollen, und hab dann ewig gebraucht, weil ich nicht gesehen habe, dass nach dem Kamerakonstanten setzen die View/Projektionmatrix überschrieben werden, um da noch ein paar andere Dinge zu machen. Und weil ich den Punkt nicht transformiert bekomme habe, dachte ich zunächst, es läge am transposen... so probiert man sich dann tot. Hatte dann die Idee, dass direkt über eine Textur zu lösen und just in diesem Moment klappte es dann endlich, die Box mit den Koordinaten 0 0 0 mit der Inversen zu multiplizieren, damit sie anschließend in den Bildschirmmittelpunkt transformiert wurde. Mir wäre aber da auch nicht ganz klar, wie ich nun das ganze als Pixel skalieren müsste. Deswegen ist die Texturvariante auf jeden Fall besser.

Bild mit Zufallsrauschen Overlay... spektakulär! :D

[marcgfx]

ich muss leider wieder mal zugeben, ich weiss gar nicht was du gerade versuchst zu machen :) . gehe ich recht in der annahme, dass es dir mit der occluder geschichte um die fernsicht geht?

[Zudomon]

ich muss leider wieder mal zugeben, ich weiss gar nicht was du gerade versuchst zu machen :) . gehe ich recht in der annahme, dass es dir mit der occluder geschichte um die fernsicht geht?

Die Fernsicht hängt da teilweise mit drin. Eigentlich geht es einfach darum, alles, was hinter einer Wand ist, direkt vorm senden an die Grafikkarte auszuschließen.
Das hab ich zumindest bis gestern schon einigermaßen stabil und provisorisch umgesetzt. Allerdings ist das berechnen, was auszuschließen ist, noch langsamer, als wenn ich den Kram direkt rendern würde. Der Extremfall ist ja, wenn man in einer Höhle sitzt und in Wirklichkeit hinter den Steinwänden trotzdem die Umgebung mit Vegetation usw. gerendert wird.

Vorher habe ich mich Occluder (also Boxen) gesucht, wo ich sagen kann, dass dahinter garantiert nichts mehr zu sehen ist. Der Occluder wurde z.B. von einer Wand extrahiert. Und jetzt möchte ich die ganzen Occluder in eine extra Textur malen, damit ich darauf hinterher schauen kann, ob eine Fläche gebraucht wird oder nicht. Hab aber heute noch nicht viel daran gemacht.

Auf dem Bild hier siehst du zwei von Hand gesetzte Boxen... die dann später die Occluder repräsentieren. Ist halt einfacher, als wenn da 100 Boxen das Bild zumalen. Die grünen Linien sind die Silhouhetten der Boxen (mit kleinen Normalenpinn der nach innen zeigen muss).
In rot und blau male ich nun anschließend über das Bild. Dieses drüber malen ist in wirklichkeit der Software-Z-Buffer. Er hat eine geringe Auflösung, die später sogar noch geringer wird, damit das schnell geht. Wie man sieht erwische ich schon die Linien und Punkte der grünen Boxen per Software.

[Zudomon]

Noch eine kleine Frage zwischendurch, vielleicht ist noch jemand von euch wach und kann mir das schnell beantworten :D

Wenn ich die Vertices umrechne in Screenspacekoordinaten, dann kann es ja sein, dass die Polygone die Screengrenze oder die Nearplane überschreiten... wie clipt man das am besten? Wird das vorher mit dem Screen gecuted oder transformiert das einfach und clipt das ganze dann im Screenspace?

[Krishty]

Ich vermute, sowas wird rasterisiert und dann verworfen -- weil 1. es beim Clipping typische Z-Artefakte gibt, und 2. ab D3D 10 Depth Clipping optional ist.

[Zudomon]

Ich vermute, sowas wird rasterisiert und dann verworfen -- weil 1. es beim Clipping typische Z-Artefakte gibt, und 2. ab D3D 10 Depth Clipping optional ist.

Okay, danke für den schnellen Tipp! :D

Wichtig ist bei mir ja eigentlich auch nur das schnelle hinklatschen der Boxen, statt akurat zu berechnen. Da will ich dann mal schauen. Die beiden Seiten der Silhouetten zu extrahieren, damit ich dann dazwischen später scanlinen kann.

[Zudomon]

Mir wird gerade empfohlen, fürs Polygonmalen die GDI zu benutzen, die auf WinAPI aufsetzt. Die soll wohl dafür schon optimiert sein. Nun weiß ich nicht, nicht selbst implementieren oder GDI? Hmmm... :?

[Zudomon]

Ich mach mal erstmal Schluss für heute. Also das Rasterizieren klappt eigentlich schon ganz gut, ist aber noch nicht wirklich optimiert.
Was mir derbe Probleme macht ist dann doch das Clipping, insbesondere wenn ein Vertex hinter die Kameraebene fällt. Ich habe so ein bisschen Sorge, dass ich das vielleicht nicht so einfach hinbekomme, weil ich ja nicht auf Dreiecke, sondern Boxen arbeite.
Man sollte das clippen wohl noch Homogenen Space machen, also vor der Perspektivenprojektion. Aber so ganz blicke ich das nicht. Genau aus diesen Gründen, wollte ich eigentlich ein Softwarerasterizer vermeiden... mist.
http://www.gamasutra.com/view/news/1685 ... p#comments
Wenn man die Box einfach skippen würde, dann verliert man viel an späteren Culling. Denn wenn man nah an einer Wand steht und sich dann tangential zur Wand dreht, dann hat man einen solchen Clipping Fall.

Mit der w-Koordinate verstehe ich irgendwie auch nicht so wirklich. Es wird ja am Ende durch w geteilt... das hatte ich bei mir allerdings vernachlässigt und trotzdem stimmen die Software Boxen mit den GPU Boxen überein. Kann ja eigentlich gar nicht sein, wenn w nicht 1 ist und man x und y damit teilt, dann sollten die Punkte doch nicht übereinander liegen. Aber bei mir multipliziere ich einfach den 3D Vertex mit der ViewProjection, multiplizere mit 0,5, addiere 0,5, spiegel die Y Achse und multipliziere mit der Buffer Auflösung. Seltsam.

Hier die wohlgerasterte Box:

Und wie das aussieht, wenn es mangels Clipping failed:

[Zudomon]

Nach einer kleinen Essenspause hatte ich dann doch Motivation nochmal weiter zu machen.

Mir ist zumindest schon mal ein viel einfacherer Renderalgo eingefallen.
Vorher hatte ich den obersten und untersten Punkt der Silhouette ausgemacht und dann vom obersten Punkt alle Kanten lang gegangen und mich bis zu dem untersten Punkt gehangelt... damit hab ich dann die linke und rechte Seite ausgemacht... dann die Kanten in einen linken und rechten Zeilenbuffer geschrieben.
Ist natürlich doof, wenn die Kanten jetzt irgendwo landen wegen dem fehlenden clipping.
Die Artefakte liesen sich zumindest auch schon gut reduzieren, indem ich einfach die X und Y Werte gespiegelt habe, wenn Z < 0 ist.

Die Idee dann war, wenn ich diesen Zeilenbuffer als min und max werte betrachte, dann könnte ich doch direkt jede Kante in diesen min und max buffer rendern. Da brauch ich gar nicht erst Kanten detektieren und eine "geschlossene" Verbindung finden.

EDIT: Wenn ich dann längere Occluder habe, muss ich mich doch auf jeden Fall um ein vernünftiges clipping kümmern, sonst klappt das nicht.

[marcgfx]

Langsam verstehe ich was du machen willst :D . Du renderst die Occluder in eine Textur, auf der du dann überprüfen kannst ob etwas versteckt ist. Hinter den Occludern wird die Geometrie gecullt und muss somit nicht verarbeitet werden, macht Sinn. Was ich noch nicht verstehe ist wie du die Occluder festlegst. Mein naiver Ansatz wäre ein Umkreis in der alles gerendert wird. Dann wird der Umkreis erhöht und dort wo bereits gerendert wurde, wird die Geometrie gecullt. Vermutlich ist das zu stark vereinfacht :oops: ?

[Zudomon]

Ja, hast du richtig verstanden.
Wie ich die Occluder Berechne: https://zfx.info/viewtopic.php?f=10&t=3 ... 540#p54360
Hier war das ganze noch auf einer 2D Ebene: https://zfx.info/viewtopic.php?f=7&t=41 ... 346#p54344
Also ein naiver Ansatz wäre, einfach alle ausgefüllten Voxel im Chunk als Occluder nutzen. Aber wenn zwei Voxel nebeneinander liegen, die ausgefüllt sind, dann kannst die ja mergen. So hab ich da versucht, die größten zusammenhängenden Voxel zu finden.

[Zudomon]

Mühsam ernährt sich das Eichhörnchen...

Ich habe den Renderingalgo nochmal etwas umgestellt und verbessert. Das Clipping geht nun auch, dabei clippe ich nur die Kanten, dessen Vertex unter Z<0.01 fällt. Bisher scheint es gut zu gehen.

Auf dem Bild sieht man 1024 (übereinander) gezeichnete Boxen, die in einen 455x256 gerendert werden. Das ganze läuft in 5 ms ab. Da ich nicht wirklich einen Vergleich habe und ich denke, dass das schon recht schnell ist, belasse ich es erstmal dabei. Allerdings muss ich noch irgendwie die Tiefe mit rein bekommen, die habe ich noch vernachlässigt. Aber auch da reicht ja dann was approximiertes.

[Zudomon]

Da stellt man dann Byte auf Single um, damit man schon mal in Richtung DepthBuffer gehen kann. Baut nochmal ein paar Checks ein, um ein paar Ausnahmen abzufangen usw. und schon ist man bei dem 10 fachen der Renderingzeit für die Boxen. Und da hab ich noch keine Ahnung, wie man dann letztendlich die tiefe für die Box berechnet... man könnte auch auf Dreiecke umsteigen, aber dann müsste im worst case 6 Dreiecke statt eine Box rastern... ich will gar nicht wissen, was das dann alles für overhead ist.
Wenn man für die Box nur die entfernteste Tiefe oder so nimmt, dann hat man gerade bei den großen bzw. langen Boxen dann das Problem, dass die vieles nicht cullen würden.

[Zudomon]

Ich hoffe ja mal, dass das wirklich Sinn macht am ende, was ich mir hier zurecht knobel :D

Hier wird nun zu jedem Vertex der Z-Wert im Homogenous-Space über das Y zu jeder Kante Interpoliert... beim rastern der Scanlines dann werden die Werte dann über X interpoliert. Man bekommt quasi dann in etwa die diagonale Plane innerhalb des Würfels. Ist halt sehr getrickst, aber bestimmt schneller, als es in Dreiecke zu splitten. Eigentlich sollte man das auch hinterher auf Bytewerte speichern können, weil die Tiefe ja eh nur ungefähr drin sein muss und für die Occluder aktuell sowieso nur die betrachtet werden, dessen Mittelpunkt < 24 Units Abstand zur Kamera haben.

[marcgfx]

Sorry, wenn ich noch einmal dumm frage, aber... das was du jetzt machst sind vor allem Tests? Oder machen diese Occluder bereits Sinn? Ich habe deinen Post zum Occluder berechnen noch einmal gelesen und wurde nicht schlau daraus.
Ich habe vom ganzen zu wenig Ahnung, aber ich hätte mir vorgestellt, dass man zuerst den Vordergrund rendert. Dieser Vordergrund könnte ja bereits die Silhouette sein, oder nicht?

Sieht auf alle Fälle kompliziert aus, aber du kriegst das sicher hin!

[Zudomon]

Huhu! Kein Problem wenn du fragst, ich versuche es gerne zu erklären! :D Ist auch alles nicht so trivial wenn man da nicht so in der Materie ist... und mal abgesehen davon, dass ich sicher auch nicht ganz so optimal erkläre, erschließen sich ja auch manche Zwischenschritte nach außen hin überhaupt nicht, weil ich die eben für mich alleine betrachte.

Also nochmal kurz, worum es beim Occlusion Culling geht:
Am ehesten zu Vergleichen ist das mit dem Frustum Culling. Ganz prinzipiell schickt man Objekte zur Grafikkarte, die dann gerendert werden. Jedes Objekt kostet natürlich Rechenleistung, bestehend aus zumeist tausenden von Dreiecken müssen die alle von 3D nach 2D umgerechnet werden um dann dessen Pixel zu malen. Selbst wenn die dann z.B. hinter der Kamera liegen und gar nicht sichtbar wären. Nun wäre die erste Überlegung zu schauen, ob ein Objekt überhaupt im Viewfrustum der Kamera ist, bevor man die Grafikkarte darauf loslässt. Allerdings ist die Grafikkarte sehr gut in dem, was sie tut, deswegen würde es tausendfach länger dauern, wenn man nun jedes Dreieck vorher per CPU prüft, als wenn man es einfach von der Grafikkarte rendern lässt.
Also wird approximiert. Statt das Objekt wird nur noch dessen Boundingbox betrachtet. Mit relativ weniger Rechenaufwand kann man nun schauen, ist die Objektboundingbox überhaupt im Kamerasichtfeld. Das absurde ist, dass selbst dieser kleine Test oftmals noch langsamer ist, als die Grafikkarte einfach rendern zu lassen... deswegen muss man auf Octrees usw. zurückgreifen. Aber ich möchte es an dieser Stelle dabei belassen, damit das ganze erstmal auf einer einfachen Ebene bleibt.
Das Frustum Culling bedeutet also, dass man das Objekt vorher gegen das Kamerasichtfeld prüft und dann übergeht, wenn es nicht im Sichtfeld ist.
Das Occlusion Culling hingegen soll die Objekte ausschließen, die hinter anderen Objekte liegen. Prinzipiell sieht man sowieso nur das, was am nahesten zur Kamera liegt, das macht der Z-Buffer. Aber der Z-Buffer verarbeitet auf Pixelebene ziemlich am Ende der Renderpipeline, nachdem das Objekt längst von der GPU bearbeitet wurde. Ziel von Occlusion Culling ist, das Objekt noch auszuschließen, bevor es überhaupt zur Grafikkarte geschickt wird.
Das ist allerdings wesentlich schwieriger als beim einfachen Frustum Culling.
Man kann sich die Kamera als Punktlichquelle vorstellen, und jetzt muss man rausfinden, was alles im Schatten liegt.
Ein weg wäre, man rendert das Objekt, zumindest in aproximierter Form und fragt die GPU hinterher, wie viele Pixel davon denn sichtbar waren. Schwierig ist das, weil das ganze nicht sehr zuverlässig funktioniert. Denn das Ergebnis steht erst ein paar Frames später fest. Wenn man sich vorstellt, man straft an einer Tunnelöffnung entlang, wo man dann mit einmal einen langen Gang zu Gesicht bekommt, dann weiß die Engine erst ein paar Frames später, dass dieser Gang auch gerendert werden muss. Das ganz verschlimmert sich dann auch noch, wenn man eben hierarchisch prüft, weil ein solche Occlusion Querrie Test für jede Würfelfläche einzeln wäre eben wieder auch ne Menge overhead.
Eigentlich ist es besser, wenn man schon auf der CPU Seite berechnen könnte, ob etwas sichtbar ist oder nicht.
Mein erster Ansatz war nun, Occluder für einen Chunk zu erzeugen. Da kann man ähnlich wie beim Frustum Culling dann einfach prüfen, ob das aufgespannte Occlusion Frustum eine Box dahinter umschließt. Also zu jeder Würfelfläche wird dann auch eine Bounding Box erstellt und mit dem Occlusion Frustum geprüft.
Problematisch ist, dass man das Objekt nur verwerfen darf, wenn es vollkommen von dem Occluder verdeckt wird. Wenn man nun zwei Occluder nebeneinander hat, die sich nicht überlagern, dann könnte es sein, dass die Würfelfläche von dem einen Occluder teilweise und von dem anderen Occluder auch teilweise verdeckt wird. Insgesamt wäre die Würfelfläche vielleicht komplett verdeckt, aber es wird ja immer nur jeder Occluder einzeln getestet.
Wenn man nun 4000 Würfelflächen prüfen muss, und das mit 100 Occludern resultiert das in 400.000 solche Occlusion Frustum Tests. Das heißt, Würfelfläche (W) wird mit Occluderanzahl (O) multipliziert. Besser wäre es, wenn man erstmal alle Occluder sammeln könnte und dann alle Würfelflächen mit dem Sammelsurrium testen könnte. Aus (W) * (O) würde dadurch (W) + (O).
Nun bedeutet dieses Sammeln eigentlich nichts anderes, als alle Occluder in einen Tiefenbuffer zu rendern. Am trivialsten wäre der Test nun, wenn man nun die Würfelfläche auch in diesen Buffer rendert und schaut, wie viele Pixel davon den Tiefentest bestehen würden. (Man überschreibt die Tiefenwerte im Buffer natürlich nicht mehr, die sind nur noch zum testen da dann)

Was nun auf den letzten Bildern zu sehen ist, ist der Versuch, selbst per Hand Boxen in ein Bild zu zeichnen über CPU.

[Zudomon]

Wahrscheinlich komme ich nicht drum herum, die Boxen zumindest als Quads zu rendern... weil gerade bei den größeren Boxen dann der Fehler wegen den Depth Werten, die ich irgendwie, aber sicher nicht korrekt erstelle, zu groß wird. Da klappt dann das Occlusion der Flächen kaum noch.

[marcgfx]

danke für die erklärung zudo! frustum culling kenn ich schon. occlusion scheint von graphik-karten gehandelt zu werden, aber geht wohl in deinem fall nicht (bzw. du willst die daten gar nicht erst schicken).

für die chunks musst du ja auch eine tiefen-reihenfolge finden, oder? 400000 tests hört sich jedenfalls nach verdammt viel an.

evtl die bounding boxes der einzelnen objekte rendern? allerding bräuchte es da wohl eine innere und eine äussere bounding box. die innere verdeckt alles dahinter, die äussere wird benötigt um festzustellen ob das objekt sichtbar sein könnte. ok, auch kompliziert... wie rendert man sowas... äussere halbtransparent? wie findet man anhand vom gerenderten bild raus, was jetzt sichtbar war. ich glaub ich überlass dir das forschen :lol:

[Zudomon]

Du redest von Occlusion Querries... aber die benutze ich ja nicht.

Ich will quasi in Software rendern, und dann schauen, ob ein Pixel von den Würfelflächen den (Software) Z-Buffer Test besteht. Also bis zu diesem Punkt hat das dann quasi gar nichts mehr mit der Grafikkarte zu tun.
Diese 400.000 Test hätte man auch reduzieren können, indem man entweder weniger Occluder prüft, oder/und die Würfelflächen zu größeren Gruppen zusammen fasst. Aber das ist was für später.
Ich habe die 2 Wochen für dieses Thema bereits überschritten, was extremen Motivationsverlust nach sich zieht... ich schaue jetzt noch, ob ich das irgendwie noch ans laufen bekomme.

Statt Würfel oder Quads ist es wohl erstmal am einfachsten, wenn ich wirklich auch Dreiecke rendere... denn da bedeutet das Clipping mit einer Ebene, dass ich das Dreieck verwerfen und entweder 0 - 2 Subdreiecke rendern muss, je nach Fall.

Dreiecksrendering hab ich auch jetzt fertig, Clipping, hier an der X Ebene scheint auch zu gehen. Jetzt noch die Tiefe und ich hoffe, dann ist das nutzbar und nicht viel zu langsam...

[marcgfx]

Ich glaube ich verstehe schon was du erzielen willst, nur verstehe ich den Prozess/dein Konzept noch nicht. Lass dich davon nicht abhalten Zudo, ich bin gespannt auf dein Ergebnis und wünsche dir viel Erfolg mit den Dreiecken ;)

[Zudomon]

Langsam geht es voran.
Das Dreiecksrendering wurde nochmal geändert und nun kann ich zumindest schon mal Vertexfarben interpolieren. Am Ende müssen es zwar nur die Tiefenwerte sein, aber nun will ich schauen, dass es auch vernünftig wird. Eigentlich schade, dass sich dafür später keine Verwendung findet, also fürs Softwarerasterizieren.

Als nächstes möchte ich noch machen, dass eine Textur verwendet wird, damit ich wegen der Perspektivenkorrektur schauen kann.

EDIT: Krass, wenn man schon auf viele Funktionen zurück greifen kann. So hat das samplen aus einer Textur jetzt keine 15 min gekostet.

[Schrompf]

Es geht vorwärts. Schick. Perspektivkorrektur ist für mich irgendwie immernoch ein Buch mit sieben Siegeln, auch wenn ich vermute, dass man das aus der Dreiecksgleichung und der Perspektivischen Projektion wahrscheinlich relativ einfach herleiten kann.

[Zudomon]

Es geht vorwärts. Schick. Perspektivkorrektur ist für mich irgendwie immernoch ein Buch mit sieben Siegeln, auch wenn ich vermute, dass man das aus der Dreiecksgleichung und der Perspektivischen Projektion wahrscheinlich relativ einfach herleiten kann.

Ehrlich gesagt, bin ich beruhigt, dass zu lesen. Ich tue mich da auch schwer, und gäbe es dazu keine Informationen, ich weiß nicht, ob ich da jemals drauf kommen würde.
Soweit ich das verstehe liegt das ganze wohl daran, dass man nicht im Homogenen Space arbeitet, sondern in dieser Perspektivischen interpoliert, wo man quasi alles irgendwie mit 1/Z berechnet.

[Schrompf]

Exakt das 1/Z ist der Fall. Steht z.B. hier: https://en.wikipedia.org/wiki/Texture_m ... orrectness
Die Interpolation mit 1/Z ist zwar ne teure Sache, aber heutzutage bei weitem nicht mehr so schlimm wie anno dunnemals. Da in Deiner Engine bisher nie die Kamera ge-tilt-et wird, kannst Du sogar den Doom-Trick anwenden und jeweils tiefenstabile Zeilen oder Spalten bestimmen. Oder Du bestimmst nur aller 4 Pixel die neuen Gradienten. Gibt jede Menge Möglichkeiten, falls sich die Divisionen tatsächlich als Problem herausstellen sollten.

Aber wie gesagt: aktuelle CPUs sollten keine Probleme mehr mit so ner Division haben. Die Zyklen dafür verblassen doch völlig gegen den Bedarf eines einzigen Cache Misses. Da waren die Jungs früher schlimmer dran, als jede Division ~30 wertvolle Takte gefressen hat und jedes Frame nur 3 Millionen überhaupt zur Verfügung hatte.

[Zudomon]

Deinen Beitrag hab ich jetzt zu spät gesehen. Bei Wiki hatte ich aber auch gelesen und dann noch diverse andere Quellen.
Irgendwo stand auch, dass man statt Z, W nehmen müsste. Es funktionierte alles nicht, bis ich mir mal W angeschaut habe, welches immer 1 war nach der ViewProj. Da habe ich erstmal gemerkt, dass da doch noch gehörig was schief läuft. :lol:
Mich hatte schon gewundert, dass ich nirgends / Z teilen muss, so generell... das war nämlich in meiner Matrixmultiplikation schon drin, dadurch bekomme ich nach der ViewProj da weder für Z noch für W sinnvolle Werte.
Hab nun die Matrixmultiplikation für 4D Vektoren drin und nun funktioniert es, wenn ich Z nehme. Muss dafür allerdings auch noch X und Y von Hand teilen. Also um auf ScreenSpace Koordinaten zu kommen.

Ich mache mir jetzt wegen der Perspektivenkorrektur auch gar nicht so den Kopf. Letztendlich möchte ich ja keinen schönen Softwarerenderer sondern hinterher die Tiefenwerte korrekt berechnen. Da habe ich jetzt lieber die Kanone rausgeholt um auf die Spatzen zu schießen, nicht dass da hinterher wieder Probleme sind. Optimieren kann man das dann hinterher noch.

[Schrompf]

Prrrrima, es geht. Ob Du aber tatsächlich perspektivisch korrekte Tiefenwerte brauchst, ist ne gute Frage. Ohne Perspektivkorrektur werden die Tiefenwerte bisweilen ziemlich danebenliegen. Aber ob das tatsächlich relevant ist für Dich, weil die verdeckten DrawCalls ja doch immer deutlich hinter den Occludern liegen und die sichtbaren DrawCalls zumindest in gewissem Abstand davor, wirst Du wohl ausprobieren müssen.