Farbergebnisse in DirectX 11- Abhängigkeit von x64 oder x86 Exe und mögliche Rolle von XMFLOAT3

[gombolo]

In meinem Fall habe ich festgestellt, dass sich die Farbe des Lichts im Pixelshader unterschiedlich verhält, je nachdem, ob ich eine x64- oder x86-Exe erstelle. Wenn ich beispielsweise die Umgebungslichtfarbe auf Rot einstelle:

Code: Alles auswählen

float3 ia = float3(1.0, 0.0, 0.0); // Umgebungslichtfarbe

Sehen nicht beleuchtete Stellen rot aus. Jedoch, wenn ich stattdessen versuche, die Umgebungslichtfarbe von einem Eingabewert zu lesen:

Code: Alles auswählen

float3 ia = input.lightcolor; // Umgebungslichtfarbe

Sind unbeleuchtet Stellen scwharz.

Meine Shaderstruktur sieht dabei wie folgt aus:

Code: Alles auswählen

struct PS_INPUT
{
    float3 position : POSITION;
    float4 color : COLOR;
    float3 normal : NORMAL;
    float3 lightposition : TEXCOORD0;
    float3 lightcolor : TEXCOORD1;
};

Warum führt das Lesen von input.lightcolor zu diesem unerwarteten Verhalten, und wie kann dieses Problem behoben werden?

[TomasRiker]

Am Shader wird es wohl eher nicht liegen, sondern an deinem Programm, welches die Farben an den Shader übermittelt.

[gombolo]

Am Shader wird es wohl eher nicht liegen, sondern an deinem Programm, welches die Farben an den Shader übermittelt.

Es liegt bedingt am Programmcode :) sondern an der Ausrichtung der Variablen. Hier in diesem Fall XMFLOAT3. Ich habe jetzt eine eigene Struktur mit float-Werten erstellt und es auf 16Bit ausgerichtet. So geht das, dann. Unter Windows x64 sind alle Heap-Zuweisungen auf 16 Byte ausgerichtet, bei Windows x86 jedoch nur auf 8 Byte. Das führt das zu seltsamen Verhalten. Im schlimmsten Fall könnte das Programm abstürzen.

EDIT Ich habe die Struktur von XMFLOAT3 auf XMFLOAT4 umgestellt und es verhält sich jetzt so wie es soll (4 x 4 byte = 16 byte) passt. Ich bin mir nur nicht ganz sicher ob das ok ist. Weil nach meinem Verständnis sollte doch auch XMFLOAT3 funktionieren (3 x 4 byte = 12 + 4 byte zum Auffüllen) so könnte ich mir das vorstellen mit der DirectXMath-Bibliothek. Vielleicht kann jemand Klarheit bringen. :)

[Schrompf]

Dein Vertex ist ein float4 color und Du schreibst einen XMFLoat3. Damit ist der Alphawert undefiniert. Und wenn der zufällig 0 ist, dürftest Du schwarz kriegen. Wenn Du im Shader einen float3 einem float4 zuweist, kriegst Du einen Default-Alpha von 1. Das dürfte der Unterschied zwischen Rot und Schwarz sein.

[gombolo]

Dein Vertex ist ein float4 color und Du schreibst einen XMFLoat3. Damit ist der Alphawert undefiniert. Und wenn der zufällig 0 ist, dürftest Du schwarz kriegen. Wenn Du im Shader einen float3 einem float4 zuweist, kriegst Du einen Default-Alpha von 1. Das dürfte der Unterschied zwischen Rot und Schwarz sein.

oh ja...also float4 color hat gepasst. Mir ging es um float3 lightcolor. Dieser ist im C++ Programm als XMFLOAT3 definiert gewesen und ich habe später festegelstellt, die Farbe war nicht schwarz sondern blau. Also die rgb-Werte waren vertauscht. Als ob es die Bytes in der falschen Reihenfolge gespeichert werden (was es ja eigentlich tun :) ) aber nicht sollten?

Ich habe angenommen das DirectXMath das schon selber anpasst an die 16Bit Ausrichtung. Erst als ich statt XMFLOAT3 die Version XMFLOAT4 genommen habe hat es auf dem X86 und X64 System funktioniert.

[NytroX]

Könnte ein alignment Problem sein.

https://learn.microsoft.com/en-us/windo ... king-rules

HLSL packing rules are similar to performing a #pragma pack 4 with Visual Studio, which packs data into 4-byte boundaries. Additionally, HLSL packs data so that it does not cross a 16-byte boundary. Variables are packed into a given four-component vector until the variable will straddle a 4-vector boundary; the next variables will be bounced to the next four-component vector.

In DirectXMath werden die Sachen aber einfach ganz C-style definiert, ohne Rücksicht darauf. Es gibt aber alignedte Typen:
https://github.com/microsoft/DirectXMat ... ectXMath.h

Code: Alles auswählen

// 3D Vector; 32 bit floating point components aligned on a 16 byte boundary
XM_ALIGNED_STRUCT(16) XMFLOAT3A : public XMFLOAT3
{
    using XMFLOAT3::XMFLOAT3;
};

Kann es evtl. sein, dass du irgendwo eigentlich XMFLOAT3A und co. beim Laden in den Shader nehmen müsstest, anstatt XMFLOAT3 ?

[gombolo]

Danke für die beiden Links. Den ersten habe ich mir schon gestern "reingezogen"... XMFLOAT3A ja kann sein. Ich muss mir das mal in den nächsten Tagen wieder im Detail anschauen, wenn die "echte" (wo man Geld bekommt) Arbeit erledigt ist :) dann kann ich wieder meinem Hobby nachgehen. :)