2D Vektrografik auf Direct3D und/oder OpenGL
-
Alles ist mein Fehler, ich bin immer schuld
-
Hrmmm, naja, eine Nacht drüber geschlafen: ich werde in meiner Freizeit einfach stur weitermachen
Ich war grad am überlegen, dass ich zum Rendern von dynamischen Polygonen ja auch einfach den Stencil-Buffer so benutzen kann, dass das Polygon im ersten Pass als Fan gerendert wird, ich linksswendig inkrementiere und rechtswendig dekrementiere. Danach müsste man ja bei einer 1 landen, wo das Polygon gefüllt gehört und könnte einfach ein Quad drüberrendern. Ab einer gewissen Komplexität könnte das doch effizienter sein, als die Polygone auf der CPU zu tesselieren? Fragt sich nur, wie man den Stencil-Buffer hinterher wieder für's nächste Polygon freibekommt. Da müsste man das Quad ja nochmal drüberrendern... Hrmmm. Kreise und sowas könnte man ja auch direkt im Shader umsetzen, wobei ich keine Ahnung hab, wie man da am besten effizient die Fallunterscheidungen der Geometrietypen bewerkstelligt Wird wohl kaum effizient sein, für ein Polygon mehrmals den Shader wechseln zu müssen.
Naja, ich hatte halt gehofft, dass vielleicht jemand, der im Gegensatz zu mir den Eindruck erweckt, er wisse was er tut, Interesse an solch einer Sache hat. Aber ist halt alles nicht so sexy wie 3D mit Global Illumination und Physics EngineIch habe auch einmal auf Stackoverflow bezüglich D2D eine Frage gestellt, aber ganz offenbar habe ich sie viel zu vage gestellt und es ist wohl auch nicht förderlich, wenn die Leute dort erst ein Beispielprojekt runterladen müssen, was sie mit aller Wahrscheinlichkeit nicht tun. Ich weiß nicht, wie ich ausdrücken soll, wie schlecht die Performance ist, außer zu sagen, dass ich CPU-limitiert bin und habe auch keinen "Erwartungswert".
-
Hrmmmm, also ich habe mal etwas rumprobiert, Kreissegmente und quadratische Bezier-Kurven per discard oder anderen Farben zu im Pixelshader auszuwerten. Das klappt auch hervorragend, aber im Moment sehe ich noch das Problem, dass ich mir nur schwerlich vorstellen kann, so Anti-Aliasing zu bekommen. Meinem Verständnis nach funktioniert "modernes optimiertes"-Anti-Aliasing so, dass Pixel-Shader nur einmal ausgewertet werden, aber die Geometrie selber mehrfach gesampelt wird. So kann man natürlich keine Shader filtern...
Welche Optionen habe ich hier zur Verfügung?Edit: Also mir sind jetzt 2 Möglichkeiten eingefallen:
1. Ich benutze eine Textur mit Rampe und frage die entsprechend der Nähe zum Rand ab.
2. Ich antialiase im Shader per HandBeides stelle ich mir nur schwerlich als effizient vor...
-
eine 'alte' moeglichkeit nennt sich alpha-to-coverage (A2C), dabei gibst du einen alpha wert aus anhand dessen die hardware dann eine gewisse anzahl punkt setzt in alehnung an den anti-aliasing modus. wenn du z.b. 16x AA hast und du gibst einen alpha wert von 0.49 aus, bekommst du 7 subsamples gesetzt. dabei sind die punkte relativ zufaellig angeordnet, sodass ueber die menge der punkt eine art weiche kante entsteht.
moeglichkeit 2. ist die gaengige heutzutage. dabei berechnest du shading etc. nur einmal, gibst aber eine coverage mask aus (also wie das obere A2C, jedoch bestimmst du selbst welches pattern die maske hat), so kannst du z.b. die konturen einer pflanze genau abtasten und die maske generieren, waehrend du beleuchtung + schadden + texture sampling fuer die pflanze nur einmal machst.
AMD nennt das "Transparency Anti-Aliasing", demos/samples findest du entsprechend bei http://amddevcentral.com/tools/gpu/RadeonSDKSamplesDocuments/Pages/default.aspx
geht ab directX 10.1
-
Danke Dir Rapso, das wird Bettlektüre!
-
Eine Frage hätte ich noch...
Warum zum Teufel benutzt D3D zur Beschreibung von Eingabetypen von Shadern die DXGI-Farbtypen? Mir stellen sich irgendwie die Fußnägel auf, wenn ich einen 2-Komponentenvektor durch DXGI_R32G32_FLOAT beschreibe...
-
zur einheitlichkeit, verschiedene datentypen fuer ein und dasselbe sind irgendwie redundant.
-
Ich bin vielleicht einfach zu pedantisch für solche Abkürzungen. Jetzt stellt sich ja die Frage, ob DXGI_B32G32R32_FLOAT dafür sorgt, dass die Vektoren "geflippt" werden, bevor sie an den Shader gelangen usw... Oder ob man so auch gleich die Farbumrechnungen zwischen den Farbräumen erledigt bekommt und ob sich das mit SV_POSITION-Semantiken verträgt... Naja, ich hab mir jetzt einfach meine enums drumgebastelt, ist ja keine Aufregung wert
-
Decimad schrieb:
Ich bin vielleicht einfach zu pedantisch für solche Abkürzungen.
dem wird wohl so sein, aber ist eine typische programmierer krankheit
wenn man es geschaft hat zu akzeptieren, dass es viele loesungen gibt und keine 'die richtige' ist, hat man schonmal einen grossen schritt geleistet aus dem junior dasein herauszukommen, zumindestens in der firma in der ich arbeite.
(sonst haette jeder programmierer seine eigene style guide, lol).Jetzt stellt sich ja die Frage, ob DXGI_B32G32R32_FLOAT dafür sorgt, dass die Vektoren "geflippt" werden, bevor sie an den Shader gelangen usw... Oder ob man so auch gleich die Farbumrechnungen zwischen den Farbräumen erledigt bekommt und ob sich das mit SV_POSITION-Semantiken verträgt...
es ist eine deklaration, sie deklariert wie du die daten hinlegst, da wird nichts geflippt.
Naja, ich hab mir jetzt einfach meine enums drumgebastelt, ist ja keine Aufregung wert
so jung und unbedarft, erfrischend sowas immer wieder zu sehen :).
-
Ich würde ja nix mehr mit DirectX und Windows only anfangen. Immer weniger Leute nutzen und spielen nur auf einem Microsoftsystem und das wird auch noch weiter zunehmen. OpenGL funktioniert wenigstens überall.
-
Ich brauche länger, das funktionierende Drumherum zu erstellen, als es kosten wird, das ganze auf OpenGL umzufrickeln, denke ich. Und im Moment erwarte ich für mein Zielsystem eine bessere Direct3D-Treiberqualität, außerdem hat VS echt coole eingebaute Debug-Möglichkeiten zur Einarbeitung.
-
useOGL schrieb:
Ich würde ja nix mehr mit DirectX und Windows only anfangen. Immer weniger Leute nutzen und spielen nur auf einem Microsoftsystem und das wird auch noch weiter zunehmen. OpenGL funktioniert wenigstens überall.
sag ich auch immer ...
das Performanceproblem von GDI/Direct2D haben andere Leute auch schon festgestellt, da muß man nicht lange suchen
http://www.google.de/#hl=de&sclient=psy-ab&q=direct2d+gdi+opengl+performance
ich habe im industriellen Umfeld eine 2D Zeichenbibliothek mit OpenGL 2.1 implementiert. dieses etwas ältere 2.1 läuft auch auf älterer und embedded Hardware stabil (WinXP emb.) und reicht für 2D Zeichenfunktionen eigentlich aus. Anti-Aliasing war bei meiner Implementierung nicht erwünscht, da Messwerte immer pixelgenau angezeigt werden sollen
bei Interesse kann ich für das 2D OpenGL 2.1 auch ein paar Tipps geben, z.B. wie man am schnellsten einen Kreis füllt
-
Danke Dir, das behalte ich im Hinterkopf für den Tesselierer der primitiven Geometrien!
Im Moment bin ich noch mit der impliziten Darstellung dieser Geometrien beschäftig (also für's Rendern von dynamischen Geometrien). Für statisches kommt dann ein genereller Mesher und für primitive Geometrien dann sowas!Ich gehe im Moment davon aus, dass ich alles, was ich so mit Direct3D mache, praktisch 1:1 auch in OpenGL umsetzen kann? Die APIs bestehen doch jetzt eigentlich nur noch aus Ressourcen-Puffern, bissl deklarativem Anteil und dann den Shadern?
-
der Funktionsumfang von Direct3D und OpenGL ist sehr ähnlich. wenn man aber mal eine gewisse Codebasis hat, kann man schlecht auf die andere Seite wechseln
bei dyn. Geometrien mußt du zunächst mal überlegen, ob du das auf der CPU oder auf der GPU rechnen möchtest. in einem Shader kann man das z.B. mit Texturkoordinaten ohne Textur machen
We use a shader program to determine if pixels are on the inside or outside of a closed region. Before getting to this shader, we must assign [u v] coordinates to the vertices of the triangles that contain curves. An example is shown in Figure 25-2. When these triangles are rendered under an arbitrary 3D projective transform, the GPU will perform perspective-correct interpolation of these coordinates and provide the resulting [uv] values to a pixel shader program. Instead of looking up a color value as in texture mapping, we use the [u v] coordinate to evaluate a procedural texture.
http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html
-
Genau das mache ich gerade! Eben für dynamische Geometrien, die ich nicht jedes Frame wieder durchtesselieren will oder wenn man gerade rumzoomt!
Alles größer als quadratische Beziers wird aber kompliziert... Bin grad noch am überlegen, die irgendwie durch Grundformen anzunähern oder an kritischen Stellen zu zerschnippeln. Die Gleichungen sind aber unschön^^