2D Vektrografik auf Direct3D und/oder OpenGL
-
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^^