4. Direct3D zeichnet alles Schwarz! Warum?

Direct3D zeichnet alles Schwarz! Warum?

  • ?

    (Nicht sicher, ob das hier das richtige Forum ist)

    Habe gerade angefangen, Direct3D zu lernen.
    Beim Rendern der ersten Primitiven treten seltsame Probleme auf.

    So habe ich einen Vertex definiert:

    struct XYZCOLOR{
 float x,y,z;
 DWORD color;
};

// Später drei Punkte erzeugt:

XYZCOLOR Dreieck[]={
 {0.2f,0.4f,0.0f, D3DCOLOR_XRGB(200,0,0),}, // Sollte eigentlich Rot sein
 {0.6f,0.5f,0.0f, D3DCOLOR_XRGB(200,0,0),},
 {0.4f,0.2f,0.0f, D3DCOLOR_XRGB(200,0,0),},
};

// Natürlich habe ich beim Erzeugen des Vertex Buffers auch
// (D3DFVF_XYZ | D3DFVF_DIFFUSE) angegeben, weil das laut Buch für
// Farben sorgen soll

    Auch beim Aufruf der Funktion pd3dDevice->SetFVF habe ich noch einmal
    (D3DFVF_XYZ | D3DFVF_DIFFUSE) als Parameter übergeben, also knapp bevor
    pd3dDevice->DrawPrimitive() das Dreieck rendert.

    Hier ist das Problem: Zwar zeichnet DrawPrimitive das Dreieck, aber es ist SCHWARZ, und nicht, wie ich mir eigentlich erhofft hätte, ROT.
    Es spielt auch gar keine Rolle, welche Farbe ich bei der Definition der Vertices angebe, ob blau, ob grün oder sonst etwas, das Dreieck ist IMMER SCHWARZ.
    Seltsamer Weise scheint die Funktion pd3dDevice->Clear() die Farbangaben aber richtig zu verstehen, wenn ich das D3DCOLOR_XRGB Makro verwende, um die Hintergrundfarbe zu verändern. Nur wenn ich die Farben als DWORD in meiner Vertex Struktur speichern möchte, funktioniert es nicht.

    Wenn mir jemand Tipps geben könnte, woran das liegt, wäre mir eine große Hilfe! Oder vielleicht auch nur einen Hinweis, woran es VIELLEICHT liegt.

    Danke.

    0
  • ?

    Benutze mal die Debug-Runtimes. Im DX-SDK Startmenü Eintrag gibt es ein Control Panel, wo du sie aktivieren kannst. Mit einem DebugView (z.B. DebugViewNt) siehst du dann die Ausgaben. Wenn du nen Fehler gemacht hast, kann es sein, dass die Debug-Runtimes diesen bemerken wärend die Release einfach irgendwas komisches machen.

    0
  • C

    Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Spiele-/Grafikprogrammierung verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.

    0

  • Steht dein Dreieck vielleicht im Dunkeln. Logisch, im Dunkeln sieht alles Schwarz aus. Denk mal nach! f'`8k

    Gruß, TGGC (\-/ has leading)

    0
  • M

    Ich bin jetzt total verwirrt.

    Wenn ich das struct anders definiere:

    struct XYZCOLOR{ // eine andere Variante die im Buch steht, also
float x,y,z,rhw; // zusätzlich rhw als Element (was immer das ist?)
DWORD color;
};

    und anschließend wieder drei Punkte erzeuge:

    XYZCOLOR Dreieck[]{
 {150.0, 50.0, 0.5f, 1.0f, D3DCOLOR_XRGB(200,0,0),},
 {250.0f, 250.0f, 0.5f, 1.0f, D3DCOLOR_XRGB(200,0,0),},
 { 50.0f, 250.0f, 0.5f, 1.0f, D3DCOLOR_XRGB(200,0,0},},
};

// dann klappt es plötzlich mit den Farben (bei der Erzeugung des
// Vertexbuffers habe ich diesmal natürlich D3DFVF_XYZRHW|D3DFVF_DIFFUSE
// verwendet, auch als Parameter bei pd3dDevice->SetFVF())

    Jetzt ist das zwar schön und gut, dass die Farben diesmal auch wirklich
    dargestellt werden, aber mir sind zwei merkwürdige Unterschiede zum alten
    struct aufgefallen (Das alte Vertex-Struct nochmal:)

    struct ALTES_XYZCOLORVERTEX{
 float x,y,z; // Kein rhw!
 DWORD color;
};

    Bei der Definition von Punkten mit dem alten Vertexstruct (ohne rhw) haben bereits sehr kleine Werte für x und y zu einem ziemlich großen Dreieck geführt
    (beispielsweise 0.3f für x).
    Wenn man die Punkte aber unter Zuhilfenahme des Vertexstructs mit dem rhw definiert, dann setzt man für x und y plötzlich riesige Zahlen ein (100.0f beispielsweise), und trotzdem ist das rhw-Dreieck nicht größer (auf dem Bildschirm) als die Dreiecke, die mit dem alten Vertexstruct gebastelt werden (also das Vertexstruct ohne dem rhw).
    Wenigstens sind die rhw-Dreiecke dafür bunt.

    Jetzt wär's noch einmal schön, wenn jemand erklären könnte, warum die Dreiecke mit dem rhw schön bunt sind und die ohne dem rhw nicht (obwohl beide auch ein DWORD color Element haben).
    Und warum man bei den rhw Dreiecken so große Zahlen nehmen muss, und bei den missglückten schwarzen Dreiecken (ohne dem rhw) sehr kleine Zahlen.
    In meinem Buch steht das nämlich nicht, und Tutorials die man im Web findet enthalten in 9 von 10 Fällen fehlerhaften Quellcode und kaum zusätzliche Informationen.
    Es sei denn jemand kennt ein wirklich gutes Tutorial, das ich möglicher Weise noch nicht gefunden habe. Bitte einen oder mehrere Links!

    Danke für jedwede Tipps und Hilfe.
    🙂

    0

  • Wer lesen kann, ist klar im Vorteil. Ich hab dein Problem doch schon beschrieben. Jetzt umgehst du das TnL, brauchst also kein Licht, dafuer musst du selbst in den Screenspace transformieren. Darum Farben da, aber Dreiecke zu klein. Voellig logisch, also streng mal dein eigenes Koepfchen an. f'`8k

    Gruß, TGGC (\-/ has leading)

    0
  • R

    Metatron schrieb:

    Jetzt wär's noch einmal schön, wenn jemand erklären könnte, warum die Dreiecke mit dem rhw schön bunt sind und die ohne dem rhw nicht
    🙂

    Bezügliches des schwarzen Dreiecks:
    Was TGGC dir sagen will, ist, dass du weder eine Lichtquelle, noch die nötigen Normalen der Vertizes hast. Daher ist das Dreieck schwarz. Du kannst dir jetzt also entweder eine Beleuchtung basteln, oder das Licht vorläufig ausschalten.

    0
  • R
    Mod

    loesch den hintergrund testweise mit einer anderen farbe als schwarz, wenn du dann ein schwarzes dreieck siehst, liegt es wohl daran.

    0
  • M

    Hat sich erledigt, meine Lektion gelernt!
    Kein Licht (LightEnable) = Keine Farbe - Wie im wirklichen Leben!

    Danke für die Tipps.

    0

  • Metatron schrieb:

    Danke für die Tipps.

    Keine Ursache, immer gern. f'`8k

    Gruß, TGGC (\-/ has leading)

    0
  • M

    So jetzt ist es immerhin geglückt, ein buntes Dreieck zu zeichnen und mit VK_UP bzw. VK_DOWN die Welt so zu transformieren, dass der Betrachter sich dem Dreieck entweder nähert bzw. sich davon entfernt.
    Seit Licht im Spiel ist, erzeugt seltsamer Weise die 'Direct3D-Release' Funktion eine Unhandled Exception (Access Violatation an irgend einer Speicheradresse, aber nicht NULL!).

    So sieht diese Funktion aus (Erst seit Licht dabei ist läuft hier etwas schief)

    void BigWindow::destroyD3D(){
	  /* Hier soll, falls der VertexBuffer existiert,
          mittels Release() der VertexBuffer wieder freigegeben werden: */
      if(pd3dVbuf)
            pd3dVbuf->Release(); // 

       /* Ähnliche Idee wie beim VertexBuffer: */
       if(pd3dDevice)
		pd3dDevice->Release();   // Uebrigens der Debugger meldet das
                                   // Problem IMMER hier

	/* Am Schluss das d3d-objekt */
	if(pd3d)
		pd3d->Release();

}

    Der gleiche Code steht auch noch einmal im Destruktor von Big Window, der ja implizit aufgerufen werden sollte, wenn WinMain die Kontrolle an Windows zurückgibt und somit sicher stellen sollte, dass ein BigWindow Objekt wieder die beschlagnahmten Resourcen wieder freigibt/Released().
    Auch ein explizites Ent-Initialisieren von D3D sollte möglich sein, deshalb diese Funktion DestroyD3D.
    Wenn man übrigens die Codezeilen der Funktion anders anordnet:

    if(pd3dDevice)
       pd3dDevice->Release();
    // ...

  if(pd3d)
       pd3d->Release();
    // ...

  if(pd3dVbuf)  // Also erst zum Schluss den Vbuffer mit Release()
                // freigeben
       pd3d->Release();    /* Interessanter Weise meldet der Debugger jetzt
                        IMMER an dieser Stelle die Access Violation */

    ... dann ist das Problem zwar verschoben aber nicht behoben.

    In der WinMain bzw. der WndProc hätte ich mir ein Beenden des Programms so vorgestellt:

    // Globale Variable
BigWindow Fullscreen;

// in der WndProc dann (case WM_KEYDOWN:)
else if(wParam==VK_ESCAPE){
                        // Das Fenster schickt sich selbst eine Message,
                        // falls Esc-Taste gedrückt wurde
				PostMessage(hwnd,WM_DESTROY,0,0);
				break;
			}
// ...
// und in der Behandlung von WM_DESTROY dann:
case WM_DESTROY:
    Fullscreen.destroyD3D(); // hier sollte D3D wieder ent-initialisiert
                             // werden
    PostQuitMessage(0);
    return 0;

    So jetzt habe ich es kurz umrissen, jedenfalls beim Beenden des Programms
    kommt es immer zu dieser Fehlermeldung mit der unhandled Exception.

    Vielleicht kann mir noch einmal jemand einen Tipp geben, woran es VIELLEICHT liegen könnte, und ob bei Euch auch schon einmal Release() Probleme aufgetreten sind?

    Nochmals Danke für die Tipps mit dem Licht!

    0
  • R
    Mod

    Metatron schrieb:

    Vielleicht kann mir noch einmal jemand einen Tipp geben, woran es VIELLEICHT liegen könnte, und ob bei Euch auch schon einmal Release() Probleme aufgetreten sind?

    klar koennen wir das, sag uns nur an welcher steller er im debugger stehen bleibt.

    0
  • M

    thx hat sich auch erledigt, eine schlampige Speicherallokation war schuld.

    Jetzt wird's schön langsam richtig interessant.

    Zur Zeit hab ich ein Tetraeder an Punkt (0,0,0) gerendert.

    Mittels SetTransform(D3DTS_VIEW) gelingt es auch, dass man sich als Betrachter davon entfernt bzw. sich annähert.
    Etwas haarig sind meine Bemühungen, die Kamera um den Punkt (0,0,0) rotieren zu lassen, und zwar immer mit fixem Winkel (0.1667f), auch mit Rücksicht auf die momentane Distanz zwischen vEyePoint und Tetraeder (sozusagen konstante Winkelgeschwindigkeit, progressiv mit der Entfernung steigende 'Bahngeschwindigkeit'.

    Löst man das mit Einheitsvektor x Translationsgeschwindigkeit (d.h. Richtung des Einheitsvektors bei jeder Rotation neu berechnen) + vEyePoint oder bin ich da auf dem Holzweg? Vielleicht ein Link zu einem Tutorial bezüglich Rotationen?

    Danke für die Tipps!

    0
  • S

    Ist es vielleicht das was du suchst?

    MfG Spacemuck

    0
Anmelden zum Antworten