spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Nunja, quake z.B. kann dank BSP zumindest die Maps theoretisch ohne Overdraw rendern. Was den Rest angeht ist das schwer zu sagen um ehrlich zu sein. Früher hat man afaik tatsächlich noch mit Visibility-Algorithmen auf Ebene von Primitiven gearbeitet da die Rasterisierung am meisten Performance gefressen hat. Damals hat man eben auch versucht möglichst ohne Overdraw zu arbeiten und solche Dinge, da jeder Pixel der berechnet und dann übermalt wurde vergeudete CPU Cycles bedeutet hat. Heute wird man einfach einen Depth-Buffer verwenden. Depth-Buffering ist übrigens auch einfach sowas wie ein Painters-Algorithmus, nur eben auf Pixelebene

Ist denn tatsächlich das Depth-Buffering dein Bottleneck? Wie hast du das denn gemessen? Und warum denkst du dass du mit einem Painters-Algo da was rausholen kannst? So ein Painters-Algo der wirklich mit allem zurechtkommt was man ihm reinwirft klingt am Papier vielleicht ganz nett, kann aber in der Umsetzung wirklich anstregend sein, das kannst du mir glauben. Einfach nur locker irgendwie Sortieren is da nämlich leider nicht, da heißts evtl. Primitive zerteilen, Floating Point Issues, ... ich hatte echt schon mehr Spaß

Zitat von »Memnarch«

das Depthbuffering ist es indirect. Eigentlich ist es das interpolieren einer position A auf einem dreieck B der ecken CDE >.<.

Muss da immer noch nen Divide(genauer 3) benutzen. Da knallt die FPS zu boden. Nehm ich diese 3 Divides raus(pro pixel) schwups über 100fps(auch bis zu 200fps, allerdings alles nur reine füllgeschwindigkeit, ohne tiefen berücksichtigung). Ok also eher ein mathematisches problem.

Naja dann zeig doch mal was du da genau treibst. Klingt für mich jedenfalls nicht wirklich als wär das Depth-Buffering dein Problem.

Zitat von »Memnarch«

PS: @Dot: du hast den Painterly schonmal benutzt? gibt irgendwo

Das war nichts besondres, nur eine Aufgabe für eine Vorlesungsübung für die ich zuständig war. Dabei sollte ein sehr einfacher Vektor-Renderer entwickelt werden wobei eben der verlinkte Depth-Sort-Algorithmus zum Einsatz kam. Jedenfalls bezweifle ich sehr dass du mit so einem Depth-Sort auf Ebene von Primitiven irgendwo Performance gut machen kannst, im Gegenteil. Ein solcher Depth-Sort bietet evtl. minimale Vorteile bei extrem einfachen Szenen die aus sehr wenigen großen Dreiecken bestehen. Ab einer gewissen Menge an Dreiecken würde ich mir jedoch erwarten dass der Depth-Buffer dem Primitive-basierten Depth-Sort im Allgemeinen bei weitem überlegen ist, sofern du nicht irgendwelche wesentlich komplexeren Visibility-Algorithmen wie z.B. BSP und PVS oder was auch immer verwendest, wobei die meisten davon auch nur für statische Szenen (Levelgeometrie) brauchbar sind.

Ok, ich wollte grad schreiben "verwend die Ebenengleichung" als ich deinen zweiten Link gesehn hab

Ich vermute mal dass es dir aber auch gar nichtmehr um die z-Interpolation geht sondern um beliebige Vertex-Attribute (Texturkoordinaten, etc.)!? Wenn ja dann vermute ich dein Problem ist dass du einfach das Attribut linear interpolierst, was aber perspektivisch nicht korrekt ist (bedenke dass dein Dreieck auf dem Weg in den Screenspace einer nichtlinearen Transformation unterworfen wurde). Um perspektivisch korrekt unterwegs zu sein musst du den Wert Attribut/z linear interpolieren und dann mit der Tiefe an der entsprechenden Stelle multiplizieren um das z wieder rauszubekommen. Da das z was du nach der Homogenisierung (Division durch w nach der Projektionsmatrix) hast aber eigentlich schon dein 1/z ist dreht sich das ganze wieder um. Den z-Wert (brauchst du sowieso fürs Depth-Buffering ) kannst du nun einfach linear Interpolieren (da er eigentlich 1/z entspricht). Was die Attribute angeht interpolierst du nun den Attribut*z Wert linear über das Dreieck. An jedem Pixel bestimmst du nun 1/z (für das interpolierte z das du sowieso berechnen musst) und multiplizierst deine interpolierten Attribute damit um den finalen Wert zu bekommen. So brauchst du nur eine einzelne Division pro Pixel.

Zitat von »Memnarch«

Problem ist aber dass ich in Delphi( damit bin ich hier unterwegs) wenn ich Attribute*Z mache(wobei dann z < 1 ist), muss am ende noch ein Trunc() hin und dass ist genauso schädlich wie eine Division. Muss nämlich zugeben dass ich nicht ganz dahinter gekommen bin wie ich die FixedPointMath bei mir umsetzen kann.

Floating points haben doch einen nicht festgelegten kommapunkt und FixedPoint haben einen festplazierten KommaPunkt oder?

Ich versteh nicht ganz, warum musst du z Truncaten?

Zitat von »Memnarch«

Und nochmal Oben auf die Tranformation: Also muss ich jetzt zuerst Z aus dem NICHT ViewTransformierten Polygon errechnen?

Nein. Das z nach der Projektion kannst du linear interpolieren. Das davor nicht.