Einige Frage zu Direct3D11



  • Hallo,
    ich bin etwas neuer in Direct3D11 und habe dazu einige Fragen.

    1. Soll ich meine drei Matrizen (World, View, Projection) mit der CPU mulitplizieren, und dann die fertige Matrix dem Shader übergeben, oder das ganze jedesmal den Shader multiplizieren lassen?

    2. Genauso bei einer Heightmap, soll ich die Vertexpositionen mit der CPU oder dem Shader berechnen?
    Ich weiß, dass genau dazu der Vertexshader da ist, jedoch muss das ganze dann jedes Frame aufs neue berechnet werden, was ich mir etwas überflüssig vorstelle.

    3. Eine etwas fortgeschrittenere Frage, wenn ich meine Heightmap render, sieht das ganze noch etwas eckig aus, welche Methoden könnt ihr mir da empfehlen, das ganze etwas zu runden?

    Schonmal Danke für eure Hilfe 🙂



  • Direkter3D schrieb:

    1. Soll ich meine drei Matrizen (World, View, Projection) mit der CPU mulitplizieren, und dann die fertige Matrix dem Shader übergeben, oder das ganze jedesmal den Shader multiplizieren lassen?

    Kommt drauf an. Recht oft ist die ViewProjection Matrix ja konstant für die ganze Szene, aber die WorldMatrix variable pro Objekt. Ich setze meistens die ViewProj Matrix EINMAL pro Frame und sende dann pro Objekt nur noch die World Matrix.

    Direkter3D schrieb:

    2. Genauso bei einer Heightmap, soll ich die Vertexpositionen mit der CPU oder dem Shader berechnen?
    Ich weiß, dass genau dazu der Vertexshader da ist, jedoch muss das ganze dann jedes Frame aufs neue berechnet werden, was ich mir etwas überflüssig vorstelle.

    Wenn dein Terrain statisch is (und nicht exorbitant groß ist), würd ich die Koordinaten einmal in einen statischen VB schieben und fertig. Alternativ könntest du auch ein XZ Gitter nehmen und die Höhe im VS per Vertex Texture Fetch samplen (geht aber erst ab SM 3.0+)

    Direkter3D schrieb:

    3. Eine etwas fortgeschrittenere Frage, wenn ich meine Heightmap render, sieht das ganze noch etwas eckig aus, welche Methoden könnt ihr mir da empfehlen, das ganze etwas zu runden?

    Am einfachsten mit einem Filter über Vertexblöcke. Google mal nach "Terrain Smoothing"



  • Direkter3D schrieb:

    1. Soll ich meine drei Matrizen (World, View, Projection) mit der CPU mulitplizieren, und dann die fertige Matrix dem Shader übergeben, oder das ganze jedesmal den Shader multiplizieren lassen?

    Natürlich auf der CPU multiplizieren.

    Direkter3D schrieb:

    2. Genauso bei einer Heightmap, soll ich die Vertexpositionen mit der CPU oder dem Shader berechnen?
    Ich weiß, dass genau dazu der Vertexshader da ist, jedoch muss das ganze dann jedes Frame aufs neue berechnet werden, was ich mir etwas überflüssig vorstelle.

    Wenn du die Heightmap dynamisch verändern willst ist das vielleicht eine gute Lösung die im VertexShader zu samplen. Aber wenn das Terrain statisch ist würd ich es auch einfach in einen statischen VertexBuffer packen und fertig.

    Direkter3D schrieb:

    3. Eine etwas fortgeschrittenere Frage, wenn ich meine Heightmap render, sieht das ganze noch etwas eckig aus, welche Methoden könnt ihr mir da empfehlen, das ganze etwas zu runden?

    Hängt davon ab was "eckig" genau heißt.



  • dot schrieb:

    Direkter3D schrieb:

    1. Soll ich meine drei Matrizen (World, View, Projection) mit der CPU mulitplizieren, und dann die fertige Matrix dem Shader übergeben, oder das ganze jedesmal den Shader multiplizieren lassen?

    Natürlich auf der CPU multiplizieren.

    Warum? Bei vielen Vertices kommt da ein riesiger Haufen Operationen zu Stande, die hochgradig parallelisierbar sind, also eigentlich genau das Hauptgebiet der Shader, während die CPU das im Vergleich dazu relativ lahm durchackern muss.

    Ist es allg. nicht klüger (wenn man nicht grad aus welchen Gründen auch immer schon von den Operationen/Sekunde der Grafikkarte limitiert ist), wie this->that schon angedeutet hat, die View/Projection Matrix auf der CPU zu berechnen (weil sie meistens nur 1x. bzw. wenig öfter berechnet werden muss) und die World (oder Model)/etc. Matrix dann vom Shader zusammenbauen zu lassen?

    sin, cos etc. für Rotation würde ich dann noch von der CPU machen lassen (geht evtl. mit lookup-tables ziemlich fix, muss man ja auch nur für Objekte machen die eine neue Berechnung nötig haben), dann dem Shader die World/Model Matrix geben und von ihm multiplizieren lassen.



  • TravisG schrieb:

    Warum? Bei vielen Vertices kommt da ein riesiger Haufen Operationen zu Stande, die hochgradig parallelisierbar sind, also eigentlich genau das Hauptgebiet der Shader, während die CPU das im Vergleich dazu relativ lahm durchackern muss.

    Es geht ja auch nicht darum die Vertices auf der CPU zu transformieren. Der parallelisierbare Teil bleibt immer Aufgabe der GPU. Es verwenden aber wohl alle Vertices von seinem Terrain die selben Matritzen. D.h. es steht 1x auf der CPU multiplizieren vs. Nx auf der GPU multiplizieren, wobei N relativ groß sein wird.

    TravisG schrieb:

    Ist es allg. nicht klüger (wenn man nicht grad aus welchen Gründen auch immer schon von den Operationen/Sekunde der Grafikkarte limitiert ist), wie this->that schon angedeutet hat, die View/Projection Matrix auf der CPU zu berechnen (weil sie meistens nur 1x. bzw. wenig öfter berechnet werden muss) und die World (oder Model)/etc. Matrix dann vom Shader zusammenbauen zu lassen?

    Warum sollte man sie auf der GPU für jeden Vertex aufs Neue zusammenbauen wenn man sie auch einfach vorher einmal auf der CPU zusammenbauen kann? Eine einzelne Matritzenmultiplikation ist jetzt nicht sooooo aufwändig dass das gleich ins Gewicht fallen würde. Aber den Vertexdurchsatz kanns evtl. doch erhöhen wenn ich mir die 64 FMAs pro Vertex sparen kann. Aber wie immer in diesen Dingen findet man die richtige Antwort für den konkreten Fall natürlich nur mit dem Profiler...



  • dot schrieb:

    TravisG schrieb:

    Warum? Bei vielen Vertices kommt da ein riesiger Haufen Operationen zu Stande, die hochgradig parallelisierbar sind, also eigentlich genau das Hauptgebiet der Shader, während die CPU das im Vergleich dazu relativ lahm durchackern muss.

    Es geht ja auch nicht darum die Vertices auf der CPU zu transformieren. Der parallelisierbare Teil bleibt immer Aufgabe der GPU. Es verwenden aber wohl alle Vertices von seinem Terrain die selben Matritzen. D.h. es steht 1x auf der CPU multiplizieren vs. Nx auf der GPU multiplizieren, wobei N relativ groß sein wird.

    TravisG schrieb:

    Ist es allg. nicht klüger (wenn man nicht grad aus welchen Gründen auch immer schon von den Operationen/Sekunde der Grafikkarte limitiert ist), wie this->that schon angedeutet hat, die View/Projection Matrix auf der CPU zu berechnen (weil sie meistens nur 1x. bzw. wenig öfter berechnet werden muss) und die World (oder Model)/etc. Matrix dann vom Shader zusammenbauen zu lassen?

    Warum sollte man sie auf der GPU für jeden Vertex aufs Neue zusammenbauen wenn man sie auch einfach vorher einmal auf der CPU zusammenbauen kann? Eine einzelne Matritzenmultiplikation ist jetzt nicht sooooo aufwändig dass das gleich ins Gewicht fallen würde. Aber den Vertexdurchsatz kanns evtl. doch erhöhen wenn ich mir die 64 FMAs pro Vertex sparen kann. Aber wie immer in diesen Dingen findet man die richtige Antwort für den konkreten Fall natürlich nur mit dem Profiler...

    Achso... sorry, ich hatte irgendwie komplett den Bezug zum Terrain übersehen und dadurch deine Antwort missverstanden.


Anmelden zum Antworten