Multiplikationen/divisionen optimieren

[Memnarch]

Kurze zusammenfassung(nicht das ich was vergesse und euch dan infos fehlen^^):

Berechnen der gesamtfläche das Dreiecks(wird nur einmal ausgeführt)

Berechnen der Fläche Teildreiecke PAB/PBC/PCA
Addition und vergleich mit der gesamtfläche

eine fläche wird so berechnet:

FlächePBC = |PXBY + BXCY + CXPY - PXCY - CXBY - BXPY|
Alle teile der formel wo KEIN p drin vorkommt, werden ebenfalls einmal vor begin der routine berechnet, da sie sich nicht ändern.
Alle teile mit PY werden nur neukalkuliert, wenn sich die YAchse ändert, alle PX teile werden jedesmal neu kalkuliert. Obige formel muss 3mal angewand werden, für jedes teildreieck einmal.

Ja ich berechne mehrere punkte pro dreieck. So ziemlich jeden pixel der drin ist(im schlimsten fall der ganze bildschirm von 512*512px)>.<
Viel schöner wäre es, wenn ich in chunks rechnen könnte. Also(vorausgesetzt es ist innerhalb des dreiecks), bei einem rechteck von 8*8 punkten, nur z.b eckpunkte so aufwendig kalkulieren und den rest simpler. Aber dass weiß ich nicht.

@Lemmy, kurz zum klarstellen: das was ich mache, mache ich aus selbstlernzwecken. Experimentieren erwünscht. Es ist zumindest EIn performancekiller. Die formel zur berechnung der flächen z.B habe ich wie oben beschrieben aufgesplittet damit sie nicht bei jedem zyklus voll ins gewicht fällt.

Zu den vekoroperationen muss ich mal googlen.

EDIT: ich hab vorher mit Integern gearbeitet, hatte zu Single gewechselt um zu gucken ob die CPU performance mässig dort anders arbeitet.

EDIT2: ich hatte auchmal die kalkulation des ZWertes rausgenommen(also obige problemformel), und der Performancegewinn war beträchtlich.

EDIT3: und nochwas zur größen ordnung: Der Renderer ist eine echtzeitapplikation. Ohne DepthTest ratert der auch bei gut 1000Polygonen noch gut mit 60FPS

MFG
Memnarch

[Lemmy]

Zitat von Memnarch:

@Lemmy, kurz zum klarstellen: das was ich mache, mache ich aus selbstlernzwecken. Experimentieren erwünscht. Es ist zumindest EIn performancekiller. Die formel zur berechnung der flächen z.B habe ich wie oben beschrieben aufgesplittet damit sie nicht bei jedem zyklus voll ins gewicht fällt.

Danke für die Klarstellung. Du solltest hier aber nun auch schon lange unterwegs sein um zu wissen, dass es da draußen jede Menge CopyPaster gibt, die alles kopieren

Grüße und viel Spaß beim experimentieren...

[Medium]

Warum musst du überhaupt die Z-Werte von Punkten auf den Dreiecksflächen berechnen? Der übliche Weg ist es, 3D-Weltkoordinaten erst in 2D-Bildschirmkoordinaten zu transformieren, und dann dadrauf die Flächenfarben zu interpolieren. Z fällt für die teuren pixelweisen Rechnungen dann ganz weg.

[Memnarch]

@Medium: Aber ohne ZWert kein ZBUFFERING. Das ist der Kasusknaktus. der Painteralgo ist nur bedingt einsetzbar, um richtiges ZBuffering kommste nicht drumherum wenn die Grafiken vernünftig dargestellt werden sollen.


MFG
Memnarch

[Medium]

Da haste wohl Recht Den Z-Buffer kann man sich (mehr oder weniger) allerdings sparen, wenn man die Faces im Screenspace back-to-front sortiert und so auch zeichnet. Damit gingen dann auch Transparenzen, wobei man noch die "hidden faces" wegoptimieren kann um zu viel mehrfach gezeichnete Pixel zu verhindern - deren Erkennung kostet aber natürlich auch ne Kleinigkeit. Front-To-Back ist schneller, braucht nur einen 1-Bit Stencil-Buffer, aber Transparenzen werden zu nem ziemlichen Spezialfall.
Die einzigen Fälle, bei denen das ohne pixelweisen Z-Buffer schief geht, sind sich schneidende Faces, oder sich im Screenspace überlappende Faces, die etwas ungünstig angeordnet sind.
Dann könnte man auch noch überlegen, ob der Z-Buffer, wenn er schon sein muss, nicht evtl. in Integer-Auflösung genügt. Dann wird aus dem "/" ein schnelleres "div", und man spart das Umsatteln in die FPU Register.

Insgesamt ist Rechnen mit Floats prinzipiell langsamer, es sei denn du fummelst dir mitm Inline-Assembler was mit SSE2 zurecht. Darauf müssen aber dann auch die gesamte Verarbeitungspipeline und Datenstrukturen angepasst sein, sonst machen die Mode-Switches der FPU wieder viel gewonnenes kaputt.

[Memnarch]

Gut dan bleib ich bei integern, das "ding" funktioniert normalerweise nur mit integern, genauso der depthbuffer. Dan bleib ich also da^^.

Ich überlege gerade wie ich TileWeise rendern kann. Dazu müsste ich checken ob ein rechteck komplett in einem dreieck liegt, es überlappt oder ganz draußen ist. Aber die welt von google spuckt nur oberflächliches aus. Meistens leute die bei solchen fragen nicht ernst genommen werden, oder gleich ne formel die mir sagt wie oft welche linie welche geschnitten hat, wie großt eine eventuel daraus entstehende fläche ist, und was die linien zum frühstück gegessen haben >.<. Letzteres war meist in der darstellung sehr chaotisch .



MFG
Memnarch

[Medium]

Die Frage ist doch sehr schnell und performant beantwortbar: Liegen alle (Screenspace-) Punkte des Dreiecks im Tile, ists ganz drin. Liegen alle ausserhalb ists ganz weg, und bei drin/draußen Mischung eben geschnitten. Komplett ohne Mathe mit Koordinatenvergleichen lösbar, da deine Tiles ja sehr wahrscheinlich Achsenparallel sind. In Tiles rendern würde schöne Möglichkeiten bzgl. Multicore Nutzung schaffen, zumindest beim Zeichnen.

[Memnarch]

Hab es zumindes endlich geschafft, diesen Rasterizer zu verstehen:
http://www.devmaster.net/forums/showthread.php?t=1884

Füllgeschwindigkeit ist von dem teil um einiges höher als bei mir ohne ZBuffering.

Jetzt muss ich noch gucken wie ich die Koordinateninterpolation wieder integrieren, un d das matheschonend^^"

MFG
Memnarch