Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Direct3D11 'RenderStates' (Rasterizer, DepthStencil, Blending)

  • 1
  • 2

Werbeanzeige

LukasBanana

Alter Hase

  • »LukasBanana« ist der Autor dieses Themas

Beiträge: 1 097

Beruf: Shader Tools Programmer

  • Private Nachricht senden

1

15.07.2010, 18:32

Direct3D11 'RenderStates' (Rasterizer, DepthStencil, Blending)

Hallo,
wie bereits versprochen, wollte ich ein paar neue DX11 Fragen in einem passenden neuen Thread stellen.
Und zwar geht es mir um die 'RenderStates' in Direct3D11. "SetRenderState" gibt es ja nicht mehr, weil die Fixed-Function-Pipeline abgeschaft wurde.
Dinge wie Culling, FillMode, Blending usw. stelle ich mit den Schnittstellen "ID3D11RasterizerState", "ID3D11DepthStencilState" und "ID3D11BlendState" ein.
Aber ich weiß nicht, wie ich diese "States" aktualisieren kann. Im Moment lösche und erstelle ich diese Interfaces immer wieder. Das kann aber unmöglich im Sinne des Erfinders sein.
So sieht das bei mir im Moment aus:

C-/C++-Quelltext

 
1
2
3
4
5
6
7
8
9
10
11
12
13

/* Configure descriptions ... */

SafeRelease(RasterizerState);
SafeRelease(DepthStencilState);
SafeRelease(BlendState);

MyDevice->CreateRasterizerState(&RasterizerDesc, &RasterizerState);
MyDevice->CreateDepthStencilState(&DepthStencilDesc, &DepthStencilState);
MyDevice->CreateBlendState(&BlendDesc, &BlendState);

MyDeviceContext->RSSetState(RasterizerState);
MyDeviceContext->OMSetDepthStencilState(DepthStencilState, 0);
MyDeviceContext->OMSetBlendState(BlendState, 0, 0xFFFFFFFF);


Wie kann man diese aktualisieren?
Mein YouTube Channel
Mein Twitter Profil
Meine Projekte auf github.com
Meine Projekte auf bitbucket.org

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

2

15.07.2010, 19:45

Zitat von »LukasBanana«

Im Moment lösche und erstelle ich diese Interfaces immer wieder. Das kann aber unmöglich im Sinne des Erfinders sein.

Doch das ist exakt im Sinne des Erfinders. Anstatt einen Haufen loser Renderstates zu haben die du immer updatest hast du jetzt Objekte die den kompletten Zustand einer Stufe der Pipeline repräsentieren. Der Vorteil davon ist dass alle Validierungen etc. hier einfach nur einmal beim Erstellen des Objektes (also zur Loadtime) gemacht werden müssen. Beim Rendern setzt du dann einfach nur noch den kompletten State auf einmal anstatt haufenweise einzelne SetRenderState() Aufrufe abzusetzen. So wird der API Overhead signifikant verringert.

EDIT: Natürlich ist es so gedacht dass du am Anfang einmal alle States erzeugst die du so brauchst und die nacher nurmehr verwendest und nicht in jedem Frame dauernd neue Objekte erzeugst und alte zerstörst...
m4studios

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »dot« (15.07.2010, 19:50)

LukasBanana

Alter Hase

  • »LukasBanana« ist der Autor dieses Themas

Beiträge: 1 097

Beruf: Shader Tools Programmer

  • Private Nachricht senden

3

15.07.2010, 20:10

Das ist doch scheiße. Ganz ehrlich, in einer 3D Engine soll jedes 3D Objekt eigene Material Eigenschaften haben. Ich würde ja gerne für jedes Objekt ein eigenes RenderState erstellen, aber man kann gerade mal 4096 solcher states erstellen. Und diese voll auszunutzen, würde ziehmlich viel RAM (oder VRAM, keine Ahnung) verbrauchen.
Kann man das wirklich nicht aktualisieren?? Ansonsten lässt sich das ohne ständiges neu Erstellen nicht wirklich gut machen :pinch:
Mein YouTube Channel
Mein Twitter Profil
Meine Projekte auf github.com
Meine Projekte auf bitbucket.org

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

4

15.07.2010, 20:14

Warum ist das scheisse? Du musst die States für jedes Material doch sowieso irgendwie Speichern, warum dann also nicht einfach für jede Art von Material gleich direkt State Objekte machen!? Ich seh da kein großes Problem, du hast auch für jede Art von Material einen eigenen Shader!? Aber nein es lässt sich nicht aktualisieren, das ganze ist eine große Stärke der neuen API. Wenn du ständiges neu Erstellen brauchst dann vermute ich einen Designfehler in deiner Engine. Wenn du mal kurz in dich gehst sollte dir außerdem aufallen dass du mit 4096 State Objekten praktisch alle Kombinationen von States die überhaupt möglich sind abgedeckt hast ;)
m4studios

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »dot« (15.07.2010, 20:25)

LukasBanana

Alter Hase

  • »LukasBanana« ist der Autor dieses Themas

Beiträge: 1 097

Beruf: Shader Tools Programmer

  • Private Nachricht senden

5

16.07.2010, 11:53

Nun gut, man kann damit sicher alle Kombinationen abdecken, aber man kommt schnelle als es einem lieb ist über 4096 Objekte.
D.h. man muss alle Kombinationen erstellen, und die Materialen müssen dann auf die State-Objekte verweisen.
Anders kann ich mir das im Moment nicht vorstellen.
Mein YouTube Channel
Mein Twitter Profil
Meine Projekte auf github.com
Meine Projekte auf bitbucket.org

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

6

16.07.2010, 11:59

Ja, Materialien werden sich einen Pointer auf ihre State Objekte halten müssen, ich seh da nicht wo das Problem liegt. Du musst das noch nichtmal irgendwie besonders managen, das nimmt dir d3d sogar schon ab:

Zitat von »"D3D Doku"«

If an application attempts to create a rasterizer-state interface with the same state as an existing interface, the same interface will be returned and the total number of unique rasterizer state objects will stay the same.
m4studios

LukasBanana

Alter Hase

  • »LukasBanana« ist der Autor dieses Themas

Beiträge: 1 097

Beruf: Shader Tools Programmer

  • Private Nachricht senden

7

16.07.2010, 13:44

Ok, das klingt wirklich ganz vernünftig, wenn das D3D sogar schon übernimmt. Danke :)

EDIT:
Muss man sich dann also gar nicht um das Releasen der State Objekte kümmern? Wenn Direct3D das sowieso schon managet?!
Mein YouTube Channel
Mein Twitter Profil
Meine Projekte auf github.com
Meine Projekte auf bitbucket.org

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

8

16.07.2010, 13:51

Natürlich musst du das selber Releasen. Ich habs jetzt nicht ausprobiert aber ich würd mal davon ausgehen dass D3D natürlich AddRef() aufruft wenn es das selbe Objekt ein zweites Mal returned, alles andre wär irgendwie dumm^^
m4studios

LukasBanana

Alter Hase

  • »LukasBanana« ist der Autor dieses Themas

Beiträge: 1 097

Beruf: Shader Tools Programmer

  • Private Nachricht senden

9

18.07.2010, 15:00

So, ich jetzt habe ich das hinbekommen. Ich denke mal, dass man den Geschwindigkeits Unterschied bei vielen Objekten schon gemerkt hätte :lol:

Es ist gar nicht so leicht bei (inzwischen schon) 4 Renderern (OpenGL, Direct3D9, Direct3D11, SoftwareRenderer) ein gutes Mittelmaß zu finden, damit die API für alle gleich bleibt.
Mein YouTube Channel
Mein Twitter Profil
Meine Projekte auf github.com
Meine Projekte auf bitbucket.org

LukasBanana

Alter Hase

  • »LukasBanana« ist der Autor dieses Themas

Beiträge: 1 097

Beruf: Shader Tools Programmer

  • Private Nachricht senden

10

21.07.2010, 12:08

Kann mir jemand sagen, ob der Alpha-Test auch über die Render States bzw. StateObjects laufen??
Wenn ja, wie? Wenn nein, wie dann? ^^

In D3D9 ging das mit "D3DRS_ALPHAFUNC" und "D3DRS_ALPHAREF" bei den RenderStates.

(PS: nur damit klar ist was ich mit Alpha-Test meine: ist der Alpha Wert kleiner als 0.5 wird der Pixel und auch der damit verbundene Tiefen Wert nicht in den Color- und Depth Buffer geschrieben.)
Mein YouTube Channel
Mein Twitter Profil
Meine Projekte auf github.com
Meine Projekte auf bitbucket.org

Werbeanzeige

  • 1
  • 2

Ähnliche Themen