4. Direct3D zeichnet alles Schwarz! Warum?

Direct3D zeichnet alles Schwarz! Warum?


  • 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