Die Normalmap (blaue Textur) wird noch schwieriger.
wozu willst du die normal map anpassen? die gibt ner geraden/ebenen fläche - nem polygon halt ^^ - struktur. ein polygon hat als flächen-normal (als einheitsvektor notiert) ne gewisse ausrichtung, die zur beleuchtung herangezogen wird. wird einfach über die polygon-normale berechnet, hat man halt ein sehr eintöniges bild. um feine strukturen darzustellen, muss man also die polygon-zahl erhöhen - eben feinere/kleinere polygone nehmen. da das aber zulasten der performance geht, geht man eben einen anderen weg. es wird eine textur(schicht) aufgebracht, die abweichungen von der polygon-normalen speichert. da ein bild aus den rgb-informationen besteht, welche als floatwert von 0-1 dargestellt werden, passt das wunderbar mit den xyz-koordinaten für eine normale im einheitsvektor-format (kein vektor anteil ist größer eins - vektor länge ist 1immer ...) zusammen. will man also zum bsp eine vektorabweichung nach "rechts" weg - also der x-koordinate folgend - dann muss man eben 1 0 0 speichern. in rgb notation würde das eben volles rot und keinerlei grün und blau bedeuten. die textur hätte hier also ne rote farbe.
das händisch zu machen, is natürlich nich grad toll. daher gibts gewisse programme, die ein high-poly-mesh in ein low-poly-mesh reduzieren können, und dabei gleich die ganzen high-poly-normalen in ner textur für das reduzierte low-poly berechnen. zum bsp hat man ein stück kopfsteinpflaster-weg. jeder stein ist mit vielen vielen polygonen erstellt worden, jede feinheit ausgearbeitet. das kann man natürlich ned in nen spiel einbauen, wenn allein der meter strasse/gehweg mehr polygone aufweist, wie so manche tolle renderszene von heut ^^ da wird daraus dann halt 1 polygon gemacht und die ganzen feinheiten der vielen vielen polygone mit ihren normalen wandern in die normalmap.
ihr seht, das hat mit der grundfarbe (die eigentliche textur - oder, wie schon richtig angesprochen, die color-map) an sich rein garnix zu tun und da dran "rumzupfuschen" bringt wohl kaum ordentliche ergebnisse ^^
was eventuell noch was bringen kann, sind specular maps oder so. die legen die "shininess" von objekten fest, also wie stark die reflektieren. so glanzpunkte quasi. also eine glaskugel, in der man den hellen leuchtpunkt einer lichtquelle sieht als bsp. je polierter die kugel, desto doller sieht man den punkt da. wenns eher rau wird (stein meinetwegen oder ne plastekugel), dann verläuft das eher und ein deutlicher reflexpunkt tritt eher nicht auf. wenn also der hals bspw viel zu sehr glänzt (oder vergleichsweise zu viel), dann könnte hier eine änderung was nutzen. die sind dann in der regel im graustufen-modus gespeichert. also nich rgb infos pro pixel (3 bit - r, g und b) sondern eben nur 1 bit pro pixel (rgba - mit alpha-channel (transparenz) - wären dann 4bit je channel). 0 wäre keine shininess (kein reflexpunkt, die raue plastikkugel) und 1 wäre volle shininess (starker reflexpunkt, spiegelkugel).
wenn etwas nass regnet, kann man als programmierer also rein theoretisch einfach die specular-map mit nem "feuchtigkeitsfaktor" multiplizieren und so regennasse materialien simulieren ^^ man hat zwar nen rauen stein, der ned glänzt, aber mit ner wasserschicht überzogen is, die eben doch glänzt).
gut, ich schweife ab