Suchergebnisse
Suchergebnisse 1-11 von insgesamt 11.
Ja, der Compiler vom 2009er SDK macht das ganze im mehr als 50% langsamer ... Rechenzeit meiner Testszene steigt von 24ms auf 37ms
Update auf ein neueres SDK und einsetzen des [loop] commands, ergab folgenden Fehler: ExternesOriginalbildanzeigen(Link) Funktioniert also scheinbar auch nicht mit einer Schleife von "-Variable" bis <= Variable Noch ein Nebeneffekt, die Compilezeiten meiner .fx files sind nach dem Umstellen vom 2004SDK auf das 2009SDK von 9 Sekunden auf gewaltige 68 Sekunden angewachsen. Das ist echt gruselig
Das werde ich mal ausprobieren, aber ich glaube vorher nehme ich mal eine Mütze voll Schlaf Vielen Dank für deine Hilfe!
Das war eine gute Idee. Ändert man die Schleifen auf C-/C++-Quelltext 1 2 3 4 5 for (int j=0; j<kernelSize; ++j) { samp.y = IN.texCoord.y + j * pixelToTexely; for (int i=0; i<kernelSize; ++i) { kommt der damit klar und die Größe kann von außen übergeben werden. Ergo: Schleifen dürfen offenbar nicht negativ starten und der <= Operator auf eine Variable scheint auch nicht erlaubt zu sein. Wieder was gelernt
Die Schleife als ganzes sieht im Moment so aus: C-/C++-Quelltext 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 kernelsizesquared=(float)kernelSize*(float)kernelSize; float3 LuminanceConv = { 0.2125f, 0.7154f, 0.0721f }; ... float 4 PS_HDR { //diverse variablendeklaration for (int j=-kernelSize; j<=kernelSize; ++j) { samp.y = IN.texCoord.y + j * pixelToTexely; for (int i=-kernelSize; i<=kernelSize; ++i) { d = 1/(3.1415926*kernelsizesquared) * exp ( -(i*i+j*j) / (ke...
Eine Änderung auf z.B. C-/C++-Quelltext 1 int kernelSize=2; erzeugt den gleichen Fehler. Ich komme da auch nicht wirklich hinter, in einem anderen Shader für die Beleuchtung benutze ich eine globale Variable C-/C++-Quelltext 1 int numLights; die von außen mit einem Wert von 1 bis 24 bestückt wird. Dort klappt das wunderbar, nur in diesem Shader nicht.
Das spuckt er aus: ExternesOriginalbildanzeigen(Link) PS: Das Device ist in Ordnung, die 33 .fx Files davor werden einwandfrei kompiliert
Ja, genau darum geht es. Eine Belichtungsreihe aus einer Szene erzeugen (3 Bilder) und dann richtiges HDR zu generieren und nicht "nur" Blooming. Das Problem mit dem abgreifen des Fehler ist folgender (auch hier mangelt es mir offensichtlich noch an Erfahrung mit dem D3D Zeugs (bin dort erst seit gut 6 Wochen unterwegs). Der C-Code zum compilieren des .fx Files sieht so aus: C-/C++-Quelltext 1 2 3 4 5 6 HRESULT hr = D3DXCreateEffectFromFile(g_pd3dDevice, fname, 0, 0, dwShaderFlags, 0, &pEffect, ...
Danke für deine Antwort. Die Performance Frage ist mir hier völlig klar, für einen normalen Gauss Blur benutze ich auch die separierte 2N anstatt der Rechenaufwendigen N² Variante. Es geht mir hier in erster Linie darum, einen Testshader zu bauen, in dem ich unterschiedliche Algorithmen zur Erstellung der Gewichtungsmaps für die einzelnen Bilder der Belichtungsreihe, sehr effektiv ausprobieren kann. Die Optimierung und Zerlegung in verschiedene aufeinanderfolgende Shader/Passes erfolgt dann soba...
Guten Abend, ich bin noch ziemlich neu im Bereich DirectX und versuche mich gerade an einer Implementation von Echtzeit HDR unter Direct3D-9. Mein Problem ist ein Pixelshader (3_0), genauer ein .fx file, in dem ich versuche die Schleifendurchlaufzahl durch eine Variable zu definieren, um im HDR Shader dann die Gauss-Kernel-Size von außen bestimmen zu können. Hier mal Auszugsweise der Shader "hdr.fx": (alles nicht relevante ist entfernt, um es kurz zu halten) C-/C++-Quelltext 1 2 3 4 5 6 7 8 9 10...