[S]: Tool zum Umwandeln von Diffuse/Normal und Specularmap in 1 Textur?

[Mr. Lolman]

Gibts sowas? Oder hat irgendjemand den Schneid sowas zu programmieren?

Bsp:

http://img206.echo.cx/img206/377/smdoor1b3ft.jpg (http://www.imageshack.us) + http://img206.echo.cx/img206/2519/smdoor1blocal5oa.jpg (http://www.imageshack.us) + http://img206.echo.cx/img206/9694/smdoor1bs9at.jpg (http://www.imageshack.us)

=

http://img206.echo.cx/img206/7406/smdoor1bnew8ds.jpg (http://www.imageshack.us)



/edit: Mist das sollte eigentlich ins Technologieforum....

[Godmode]

Wie werden die Farbwerte den berechnet? Multipliziert oder addiert? Dürfte aber nicht sonderlich schwierig sein. Pixel aus allen 3 Texturen lesen, neuen Wert berechnen und in Zieltextur schreiben und dann diese halt noch speichern. Ich schau mal ob ich auf die Schnelle was zusammenschustern kann.

[Mr. Lolman]

Ich hab die Normalmap in Graustufen umgewandelt, dann im Photoshop mit Vidid Light über die Diffusemap gelegt, und darüber kam dann die Specularmap mit 50%iger Transparenz und Softlight.


Jetzt müsste man nur wissen wie Vivid und Softlight verrechnet wird ;)

[Godmode]

Ok es gibt jetzt schon ne Alpha-Version wo man 3 Bilder auswählen kann und dann ein 4 Bild daraus erzeugt wird. Ich bräuchte von dir nur mehr die Formeln.

Edit: Speichern funktioniert jetzt auch schon. Ich implementiere das Tool mit C#. Wenn du mir noch die genauen Formeln sagen kannst, hast du das Tool heute noch.

http://members.aon.at/bans3i/TextureEditor.exe

Das ist mal die 1. Version.
Du klickst einfach in jedes der 3 Felder oben und suchst dann im FileDialog deine gewünschten Bilddateien. Dann klickst du in das Feld unten rein, dadurch wird das neue Bild generiert. Mit Speichern kannst du das Bild dann abspeichern. Die 3 Source Bilder müssen gleich groß sein. Die Formeln schaut jetzt für Testzwecke mal so aus:

color = (pic1+pic2+pic3) / 3

[Mr. Lolman]

Hm,ich kann nur nen Link (http://www.santarosa.edu/~bheiman/73_31_online/lectures/lec05.html) anbieten in dem erklärt werden wie die Blending Modi funktionieren und das Ganze ein bisschen vereinfachen (in dem man sich
die Specularmap spart und stattdessen das Bild um ~15% abdunkelt)

Normalmap (2. Bild) in Graustufen umwandeln
mit Linear Light über 1. Bild blenden
15% dunkler


Linear light: combines Linear Dodge and Linear Burn.

Linear burn: like Multiply, with a greater tendency to make areas pure black.

Screen: the opposite of Multiply, lightening colors along a curve. Colors screened with white become white while colors screened with black keep
their color value. Screen affects highlights the most.

Linear dodge: like Screen, with a greater tendency to make lighter areas pure white.




Vereinfacht hab ichs deswegen, weil ich mir nicht sicher bin ob die Methode mit der Specularmap generell brauchbar ist, und obs für die ganze Sache nicht eh schon irgendwo ne Formel gibt...

[Mr. Lolman]

Noch ne einfachere Methode:

1. Normalmap -> Grayscale
2. Normalmap * Normalmap * Diffusemap
3. Brightness+7/Contrast+70

[aths]

Wozu soll das sein? Vorberechnetes Bumpmapping?

[zeckensack]

Ich würde mal auf ein Projekt zum besseren Doom3-Erlebnis auf 'ner Voodoo-Karte tippen ;)

@Lolman,
was du da machst ist allenfalls standbildtauglich.
Das was du da mit der normal map anstellst läuft daraus hinaus, dass du die Beleuchtung von oben links (~NNW) durchrechnest -- und zwar deswegen, weil Photoshop die NTSC-Gewichtung der Luminanz beherrscht.
Erstmal geht dann der Effekt flöten, wenn sich Lichtquellen bewegen. Ich erwarte eigentlich dass das im laufenden Betrieb etwas merkwürdig aussehen wird (wenn du Schatten deaktivierst, dann fällt das nicht mehr so auf ...).

Das ist alles nur geschummelt. Deswegen gibt's auch keine "richtige" Formel um diese Texturen zu verknüpfen.

Viel schlimmer aber ist, dass dieses "von oben links" für alle Texturen gilt. Man stelle sich flott mal einen engen Gang vor. Die Wand links ist so beleuchtet, als käme das Licht von hinten, die Wand rechts allerdings so, als käme es von vorn. Fußboden und Decke können sich auch nicht recht entscheiden. Sprich: eine einzelne Textur mag so behandelt schick aussehen, aber es wird sehr schwierig, mehrere aneinanderzusetzen ohne dass es blöd aussieht :)

[micki]

einfach emboss bumpmapping verwenden, das kann jede voodoo ab v2

MfG
micki

[Mr. Lolman]

Dann bräuchte man nur ein Tool welches die Voodoos Emboss Bumpmapping rechnen lässt, wenn irgned ein anderer Modus angefordert wird.

@Zeckensack. Mir ist klar, dass statische Beleuchtungen auf den Texturen tw. deplaziert wirken, aber

1. Hatten alle Spiele ohne Bumpmapping statische Beleuchtung an den Texturen

2. Könnte man ja die Normalmap so verrechnen, dass das Licht nicht von Links oben kommt, sondern normal zur Textur steht.

3. Schaut bei einem Testlauf mit ein paar bearbeiteten Texturen schon weitaus besser aus, als mit den konturlosen Diffusemaps alleine..

[Coda]

Emboss kann absolut jede Karte, auch die V1.
Aber das wirst du kaum in vorhandene Spiele einbauen können, außerdem sieht's beschissen aus ;)

@Topic: Wieso verwendet ihr nicht einfach die richtige Lichtformel mit einem Lichtvektor von links oben?

also Color = (N.L)*diffuse + [(N.H)^shininess]*specular

N muss man sich halt aus der Normalmap extrahieren. Ist recht einfach mit X=(R/256)*2-1, Y=(G/256)*2-1, Z=(B/256)*2-1. (X,Y,Z) ist dann der Normalenvektor, muss man eventuell vorher noch normalisieren.

[Mr. Lolman]

Emboss kann absolut jede Karte, auch die V1.
Aber das wirst du kaum in vorhandene Spiele einbauen können, außerdem sieht's beschissen aus ;)

@Topic: Wieso verwendet ihr nicht einfach die richtige Lichtformel mit einem Lichtvektor von links oben?


Weil wir die nicht kennen?

Vll wär ein Lichtvektor der direkt normal auf die Texturfläche steht doch besser...

[Coda]

Ich hab's hingeschrieben, . = Dot Product. Also a.b = a.x*b.x + a.y*b.y + a.z*b.z, falls das auch noch unklar ist ;)

Der Lichtvektor muss natürlich normalisiert sein, der Normalenvektor sollte es schon sein.

Vll wär ein Lichtvektor der direkt normal auf die Texturfläche steht doch besser...Dann halt einfach (0,0,-1) als Lichtvektor nehmen für die Formel.

Ach so: H ist der Halfway Vektor, der ist zwischen dem Lichtvektor und dem Betrachter, also (L+V) normalisiert. V ist der Betrachtervektor also auch (0,0,-1)

[zeckensack]

@Zeckensack. Mir ist klar, dass statische Beleuchtungen auf den Texturen tw. deplaziert wirken, aber

1. Hatten alle Spiele ohne Bumpmapping statische Beleuchtung an den TexturenSiehe dein Punkt 3 ;)
Diese (Diffus-)Texturen sind einfach für dynamische Beleuchtung gemacht worden. Da sind keinerlei Konturen drin.
Bei Spielen ohne Bumpmapping ist das wirklich anders.
2. Könnte man ja die Normalmap so verrechnen, dass das Licht nicht von Links oben kommt, sondern normal zur Textur steht.Jo, dann wäre es zwangsläufig einheitlich :)
Dafür musst du AFAICS den Blau-Kanal isolieren, anstatt komplett in Graustufen umzuwandeln.
3. Schaut bei einem Testlauf mit ein paar bearbeiteten Texturen schon weitaus besser aus, als mit den konturlosen Diffusemaps alleine..Klar, glaube ich dir gern. Ich habe Doom 3 auch schon nackt gesehen ...
Btw finde ich dein Resultat im Eingangsposting durchaus gelungen. Ich wollte nur rechtzeitig vorwarnen, dass mit der Methode einige Inkonsistenzen drohen.

[aths]

Dafür musst du AFAICS den Blau-Kanal isolieren, anstatt komplett in Graustufen umzuwandeln.Wieso reden immer alle davon, man könne per Kanal-Extraktion aus einer Normalmap die Heightmap wiedergewinnen? Der Blaukanal mag der Anteil des Normalenvektors sein, der senkrecht auf die Textur steht. Das heißt nicht, dass er die Höhe speichert. Ich habe mal Lolmans Bild in RGB-Kanäle zerlegt, da sieht auch nichts nach Heightmap aus.

Wenn ich das mit der Normalmap nicht ganz falsch verstanden habe, speichert sie praktisch Gradienten. Die Höhen-Info geht flöten. Man könnte lediglich, wenn für einen bestimmten Punkt die Höhe bekannt ist, den Rest einigermaßen rekonstruieren. Das hängt dann aber von den Nachbarwerten ab.

Im Gegensatz dazu könnte man aus einer Heightmap "on the fly" eine Normalmap samplen. Zumal eine TMU immer 4 Werte gleichzeitig lesen kann (für bilineare Filterung) hat man somit die Nachbar-Infos, um den Gradienten zu bestimmten.

[Mr. Lolman]

...und wie funktioniert dann das: http://66.70.170.53/Ryan/heightmap/heightmap.html ?

[aths]

...und wie funktioniert dann das: http://66.70.170.53/Ryan/heightmap/heightmap.html ?Nicht mit Kanal-Extraktion. Ich denk mal das geht so indem einfach ein Starthöhenwert festgelegt wird und man Texel für Texel aus dem Gradienten die Höhendifferenz zum Nachbarn berechnet. Am Ende kann man die Extremwerte für die Höhen bestimmten und das auf 0..1 normalisieren.

[Mr. Lolman]

Noch ne einfachere Methode:

1. Normalmap -> Grayscale
2. Normalmap * Normalmap * Diffusemap
3. Brightness+7/Contrast+70

Bringt das Ergebnis:

http://img217.echo.cx/img217/6051/smdoor1bnew21hd.jpg (http://www.imageshack.us)

[aths]

Um den Lichtwinkel anzupassen müsste die Reduktion auf die Graymap parametrisierbar sein. Vermutlich wird aktuell ungefähr dies gerechnet: Rot x 0,3 + Grün x 0,6 + Blau x 0,1.

[Mr. Lolman]

Hm, mit dem, oben von mir verlinkten, Tool kommt nach ~10sec ne nette Heightmap raus:

http://img176.echo.cx/img176/4785/smdoor1blocaldisplacement4ye.jpg (http://www.imageshack.us)

Multipliziert mit der Diffusemap und Brightness/Contrast +5/+50

http://img176.echo.cx/img176/5979/smdoor1bnew49dj.jpg (http://www.imageshack.us)

Heightmap² * Diffusemap -> Brightness/Contrast +7/+70:
http://img176.echo.cx/img176/7792/smdoor1bnew32pn.jpg

[zeckensack]

Wieso reden immer alle davon, man könne per Kanal-Extraktion aus einer Normalmap die Heightmap wiedergewinnen? Der Blaukanal mag der Anteil des Normalenvektors sein, der senkrecht auf die Textur steht. Das heißt nicht, dass er die Höhe speichert. Ich habe mal Lolmans Bild in RGB-Kanäle zerlegt, da sieht auch nichts nach Heightmap aus.Ich kenne den Unterschied (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=2934887#post2934887).

Wenn ich das mit der Normalmap nicht ganz falsch verstanden habe, speichert sie praktisch Gradienten. Die Höhen-Info geht flöten. Man könnte lediglich, wenn für einen bestimmten Punkt die Höhe bekannt ist, den Rest einigermaßen rekonstruieren. Das hängt dann aber von den Nachbarwerten ab.

Im Gegensatz dazu könnte man aus einer Heightmap "on the fly" eine Normalmap samplen. Zumal eine TMU immer 4 Werte gleichzeitig lesen kann (für bilineare Filterung) hat man somit die Nachbar-Infos, um den Gradienten zu bestimmten.Hier geht's nicht um height maps, sondern darum den diffusen Lichtanteil auszurechnen, wenn das Licht senkrecht zur Textur steht -- der einzige Fall, der nicht zu "komischer" Optik führt, wenn man das Licht nicht dynamisch berechnen will.

Und wie macht man das? Mit dem Skalarprodukt aus Normale und dem Vektor zum Licht.
Der Vektor vom Texel zum Licht ist (0;0;1) im "tangent space". Und (0;0;1)*(x;y;z) ist immer z. Deswegen reicht's, den Blaukanal zu isolieren.

[zeckensack]

Hm, mit dem, oben von mir verlinkten, Tool kommt nach ~10sec ne nette Heightmap raus:

<...>

Multipliziert mit der Diffusemap und Brightness/Contrast +5/+50

<...>

Heightmap² * Diffusemap -> Brightness/Contrast +7/+70:
<...>Mit der height map kannst du simulieren, dass das Licht schwächer wird, je weiter es reisen muss. Der Abfall mit der Entfernung ist quadratisch, also ist die zweite Formel richtiger. Allerdings ist der Effekt unrealistisch groß -- du simulierst unendlich starke Vertiefungen.

Mal angenommen, das soll so aussehen als wäre das Licht einen Meter weg, und die Vertiefungen maximal 10cm tief. Dann müsste "ganz hinten" das Licht 1²/1,1²~=82,6% der Intensität haben, die es "ganz vorne" hat.

Förml:
Diffusemap/(1+0,1*Heightmap)²
bzw
Diffusemap/(1,1-0,1*Heightmap)²

Es kommt darauf an, wie die Heightmap zu interpretieren ist. Wenn 0 in der Heightmap "ganz vorne" bedeutet, gilt die erste Formel. Bedeutet 0 "ganz hinten", gilt die zweite. IMO ist für deine Heightmap die erste Formel richtig.

PS: Warum reißt du eigentlich immer den Kontrast auf?

[Mr. Lolman]

PS: Warum reißt du eigentlich immer den Kontrast auf?

Weil die Luminanz mit jeder Multiplikation geringer wird, und der Helligkeitsregler allein, das Ganze ausgraut.

/edit:
und man im Photoshop mit Multiplikationen als Layereffekt entweder Vertiefungen oder Erhöhungen simulieren kann. (Heightmapabhängig)

/edit2:
Demnach müsste die Formel folgendermassen aussehen, wenn (bspw) max 20cm Erhebung und 20cm Vertiefung abgebildet werden sollen!?


Diffusemap/(0.8+0,4*Heightmap)²

[Mr. Lolman]

Wo kommt man eigentlich auf die Gewichtungen zur Bestimmung des Grauwerts?

Grauwert = Rotwert * 0.21 + Grünwert * 0.72 + Blauwert * 0.07

[aths]

Wo kommt man eigentlich auf die Gewichtungen zur Bestimmung des Grauwerts?

Grauwert = Rotwert * 0.21 + Grünwert * 0.72 + Blauwert * 0.07
Durch Experimente. Aber in dieser Formel ist Grün für meinen Geschmack zu stark gewichtet. Ich bevorzuge die YCbCr-Definition für Y (UV und CbCr sind hingegen nicht "kompatibel").

Y= R x 0,299 G x 0,587 + B x 0,114.

[Mr. Lolman]

Wie konvertiert man RGB zu YCbCr?

Denn damit die Farben nicht ausgegraut werden, dürfte ja nur Y mit der Heightmap verrechnet werden, oder?

[aths]

Ich kenne den Unterschied (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=2934887#post2934887).Ups http://www.chat-avenue.com/forums/images/smilies/sulkoff.gif

Hier geht's nicht um height maps, sondern darum den diffusen Lichtanteil auszurechnen, wenn das Licht senkrecht zur Textur steht -- der einzige Fall, der nicht zu "komischer" Optik führt, wenn man das Licht nicht dynamisch berechnen will.

Und wie macht man das? Mit dem Skalarprodukt aus Normale und dem Vektor zum Licht.
Der Vektor vom Texel zum Licht ist (0;0;1) im "tangent space". Und (0;0;1)*(x;y;z) ist immer z. Deswegen reicht's, den Blaukanal zu isolieren.Das sieht aber shice aus.

[aths]

Wie konvertiert man RGB zu YCbCr?

Denn damit die Farben nicht ausgegraut werden, dürfte ja nur Y mit der Heightmap verrechnet werden, oder?Hier interessiert nur Y als Helligkeit, um das dot product zu simulieren. Aber wie gesagt wäre es sinnig, um unterschiedliche Lichtwinkel zu ermöglichen, anpassbare Parameter zu erlauben. zs wirft nun ein, dass man damit immer Fehler hat, wenn man einen "schönen" Lichtwinkel nutzt.

Der YCbCr-Würfel liegt größtenteils außerhalb des RGB-Würfels (umfasst aber auch alle Farben im RGB-Würfel.)

[Mr. Lolman]

Das sieht aber shice aus.
Stimmt :biggrin:

Ich schätz mal, dass es das Einfachste wäre, die Normalmap in Graustufen umzuwandeln und dann anhand Zeckis Formel mit der Diffusemap zu verrechnen. V.A. dauert dass dann keine halbe Ewigkeit bei >1000 Texturen...

[Mr. Lolman]

Hier interessiert nur Y als Helligkeit, um das dot product zu simulieren. Aber wie gesagt wäre es sinnig, um unterschiedliche Lichtwinkel zu ermöglichen, anpassbare Parameter zu erlauben. zs wirft nun ein, dass man damit immer Fehler hat, wenn man einen "schönen" Lichtwinkel nutzt.


Ist mir klar, und das ignorier ich auch fleissig. :D


Der YCbCr-Würfel liegt größtenteils außerhalb des RGB-Würfels (umfasst aber auch alle Farben im RGB-Würfel.)

*dastandStuss*

Dann halt mit YUV:

Y = 0.2999 · R + 0.587 · G + 0.114 · B
U = 0.493 · (B - Y)
V = 0.877 · (R - Y)

[Godmode]

Wie schauts jetzt aus, gibt es jetzt eine Formel?

[Mr. Lolman]

Ja gibts mittlerweile:

Diffusemap in YUV umwandeln:

Y = 0,2999 * R + 0,587 * G + 0,114 * B
U = 0,493 * (B - Y)
V = 0,877 * (R - Y)

Normalmap in Graustufen umwandeln:

X = 0,2999 * R + 0,587 * G + 0,114 * B

Normalmap mit dem Helligkeitswert der Diffusemap anhand von Zeckis Formel verrechnen (Das könnte man auch parametrisieren "1" = 1m Abstand; "0,1" = 10cm Vertiefung) :

Y/ (1 + 0,1 * X)²

Das Ergebnis wieder in RGB:


R = V / 0,877 + Y
B = U / 0,493 + Y
G = Y - (0,2999 * R + 0,114 * B)

Natürlich könntest du die Werte für RGB parametrisiebar machen, aber toll wärs schon wenns mal so funktioniert. Dann bräcuhte man nur noch ne wählbare einstellung für das Normalmap Suffix im Dateinamen und ne Möglichkeit ~1000 Files so im Batch durchlaufen zu lassen. (Falls für einige Texturen keine Normalmap gefunden wird, kann er ja mal alle anderen durchrechnen, und bei den besagten Texturen Vorschläge für Normalmaps von ähnlich klingenden Dateinamen bringen)

Wenn dir das noch nicht reicht als Herausforderung -> mir fällt sicher noch was ein :biggrin:

[Godmode]

Super! Ja dann mach ich das mal!

edit:

noch ne Frage: sollte Y/(1+0.1*X)² heißen Y=Y/(1+0.1*X)² ?

[zeckensack]

Ups http://www.chat-avenue.com/forums/images/smilies/sulkoff.gif

Das sieht aber shice aus.Wie soll's denn deiner Meinung nach richtig aussehen? Das Lichtmodell entspricht der Situation "Objekt auf Scanner legen". Das sähe dann zB so (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=208345) aus, und das ist wirklich nicht viel anders.

Klar wirkt das ganze irgendwie matt. Kein Wunder, weil nur die diffuse Beleuchtung berechnet wurde (das allerdings halbwegs physikalisch korrekt).
Wenn du willst dass es chön gläncht, dann musst du selbstverständlich die specular map (gewichtet) addieren, denn dazu ist sie ja da.

[Mr. Lolman]

Wenn du willst dass es chön gläncht, dann musst du selbstverständlich die specular map (gewichtet) addieren

Wie gewichtet?

[aths]

Wie soll's denn deiner Meinung nach richtig aussehen? Das Lichtmodell entspricht der Situation "Objekt auf Scanner legen". Das sähe dann zB so (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=208345) aus, und das ist wirklich nicht viel anders.

Klar wirkt das ganze irgendwie matt. Kein Wunder, weil nur die diffuse Beleuchtung berechnet wurde (das allerdings halbwegs physikalisch korrekt).
Wenn du willst dass es chön gläncht, dann musst du selbstverständlich die specular map (gewichtet) addieren, denn dazu ist sie ja da.Die Specmap habe ich in meinem Beispiel berücksichtigt (wenn auch nicht korrekt.) Bumpmapping mit Licht was senktrecht zur Fläche einfällt bringt es imo nicht, da der schöne Bump-Effekt nur bei seitlichem Licht schön zum Tragen kommt. Dann wird jedoch das passieren wovor du gewarnt hast.

Mr. Lolmans Projekt kann nicht funktionieren – wäre es so einfach, würde das standardmäßig gemacht. Bei "vorbeleuchteten" Texturen nimmt man oft einen schrägen Lichteinfallswinkel und passt den Content entsprechend an. (Max Payne 2 zeigt aber auch hier Schwächen.) Bei Wandtexturen kann man das Licht immerhin noch von oben kommen lassen, aber bei Deckentexturen geht das nicht. Lässt man bei Wandtexturen das Licht "halb von oben" kommen und bei Decke und Boden immer orthogonal zur Ebene, das sieht imo auch nicht passend aus. Die Lichtquelle ist bei Doom 3 nicht die Sonne, die als unendlich weit entfernt gedacht werden kann. Über das Polygon ändert sich der Lichteinfallswinkel von der Lichtquelle, womit sich auch die Intensität ändert, von längeren Strahlenweg ganz zu schweigen. Das passt einfach nicht, wenn man gleichmäßig "vorbeleuchtet". Das hast du in diesem Thread schon zur Sprache gebracht.Sprich: eine einzelne Textur mag so behandelt schick aussehen, aber es wird sehr schwierig, mehrere aneinanderzusetzen ohne dass es blöd aussieht :)

[Mr. Lolman]

Das hast du in diesem Thread schon zur Sprache gebracht.
Schaun wir einfach mal - mit Gewichtungen kann man das vll. minimieren, schlimmstenfalls ändern wir die Formel* in

Y = (Y * B³) / (1 - Specular)




noch ne Frage: sollte Y/(1+0.1*X)² heißen Y=Y/(1+0.1*X)² ?

Ja natürlich, sry ;)


*wär praktisch wenn man de Rechenschritte überhaupt selbst festlegen könnte, oder wenn du mir gleich den Quellcode als PN schickst :D

BTW: Hau die Möglichkeit zum Verrechnen einer dritten Textur bitte nicht ganz raus. Vielleicht brauchen wir sie doch noch.

[Xmas]

Warum nicht einfach die normale Beleuchtungsformel, wie Coda sie geschrieben hat?

Der graue Streifen in der Normalmap ist wohl ein Bildfehler?

private struct vec3
{
public vec3(float a, float b, float c)
{
x = a; y = b; z = c;
}

public vec3 normalize()
{
float len = (float)Math.Sqrt(x*x + y*y + z*z);
if(len > 0)
{
len = 1 / len;
x *= len; y *= len; z *= len;
}
return this;
}

public float dot(vec3 rhs)
{
return x * rhs.x + y * rhs.y + z * rhs.z;
}

public vec3 add(vec3 rhs)
{
return new vec3(x + rhs.x, y + rhs.y, z + rhs.z);
}

public float x, y, z;
}

private Bitmap calculateLighting(Bitmap diffusemap, Bitmap normalmap, Bitmap specularmap)
{
Bitmap result = new Bitmap(diffusemap.Width, diffusemap.Height);

// Konstanten für die Beleuchtung
float diffuseIntensity = 1;
float specularIntensity = 1;
float ambientIntensity = 0;
float shininess = 8;
vec3 light = new vec3(-2, 1, 2).normalize();

vec3 half = new vec3(0, 0, 1).add(light).normalize();

for(int y = 0; y < diffusemap.Height; ++y)
{
for(int x = 0; x < diffusemap.Width; ++x)
{
Color nc = normalmap.GetPixel(x, y);
Color dc = diffusemap.GetPixel(x, y);
Color sc = specularmap.GetPixel(x, y);
vec3 normal = new vec3((nc.R - 128)*2, (nc.G - 128)*2, (nc.B - 128)*2).normalize();
float diffuseFactor = normal.dot(light) * diffuseIntensity + ambientIntensity;
float specularFactor = (float)Math.Pow(normal.dot(half), shininess) * specularIntensity;
Color rc = Color.FromArgb(
Math.Min(255, Math.Max(0, (int)(dc.R * diffuseFactor + sc.R * specularFactor))),
Math.Min(255, Math.Max(0, (int)(dc.G * diffuseFactor + sc.G * specularFactor))),
Math.Min(255, Math.Max(0, (int)(dc.B * diffuseFactor + sc.B * specularFactor))));
result.SetPixel(x, y, rc);
}
}
return result;
}

[Mr. Lolman]

@bans3i

Danke für den Source. Hab ihn mir aber nur mal kurz übern Texteditor angesehen, und muss sagen, dass es schon recht komplex wirkt. (Hab mich bisher auch eher mit vb.net heurmgespielt, als mit C#)

Naja was hältst du davon das Programm mit Xmas Formel schnell fertig zu basteln um dir damit zumindest nen Namen in der (immernoch aktiven) 3dfx Community zu machen

(Dementsprechend wär so ne Makrofunktion um mehrere Texturen auf einmal umzuwandeln, recht praktisch ;))