hmm oki.
primär kamen mir beim näheren überlegen nur folgende probleme in den sinn:
- ich hab in meinem schauen buch (super bible 5) nochmal das mit der 3d textur da durchgelesen. man erstellt eine textur mit GL_TEXTURE_2D_ARRAY (statt GL_TEXTURE_2D) und bindet da dann mittels glTexImage3D ein 3 dimensionales bild, was mit NULL als data pointer initialisiert wird. sprich, man baut sich nen großen leeren käfig, mit den dimensionen des bildes (x y). mittels glTexSubImage3D füllt man dann diesen leeren käfig stück für stück mit den einzelnen texturen (die texturkoords s und t werden um die koordinate r erweitert, welche dann quasi den array index repräsentiert).
da is für mich der erste knackpunkt: müssen diese subimages die selbe größe haben (x y) wie der "käfig" oder können sie auch kleiner sein? weil als default textur hätte ich dann einfach ne 1x1 pixel große grafik genommen um platz zu sparen un gut. aber wenn ich nen hochauflösendes bild mit 4x2k pixeln ca habe und diese "sinnfreien" default texturen dann auch so groß sein müssen, obwohl 1px langen würde.... gnaa ^^ aber gut, hier wären die flags sicher gut. wobei ich da auch noch überleg, wie ich das am dümmsten mach. textur, specular map, normal map, alpha map, luminezens(?) map - also die, die sagt wos auch im dunkeln leuchten soll ^^, höhen map? soll wohl für parallax mapping gut sein ^^. jedenfalls lässt sich mit bissl spucke da einiges zaubern und nen vec4 wird eng als flag-variable
müsste man dann vllt ne ganze matrix rüberballern
aber gut, das sollte ja ned der umstand sein.
gut, ich glaube die flags sind noch die beste option.
dann nochmal ne verfahrenstechnische frage. was organisatorisches. atm sieht mein object loader ca so aus (grob umrissen): er speichert alle punkte in ner punktliste, alle normalen in ner normalen liste and so on. dann gibts ne flächenliste, die je 3 vertizes (also ein konglomerat aus punkten, normalen, texcoords und farben) per index speichert (speicherplatz). beim zeichnen geht er dann die flächenliste durch, holt sich laut angegebenem index aus den entsprechenden listen die werte und baut sich das vbo/vao gedöhns zusammen, was er dann malen kann.
so, nun hab ich noch ne texturliste, die ich atm noch sträflich vernachlässigt habe. atm siehts so aus, das jede fläche noch ne texturangabe hat. is sorum aber schwachsinnig, da er dann ja im notfall laufend hin und her switchen muss (statusänderungen der pipeline = effiziensschwund = besser vermeiden). also wenn eine fläche aus der "textur" metall besteht, das nächste aus plastik und dann wieder metall... urgs ^^ daher war meine überlegung, das demnächst so umzubauen, dass die texturliste neben all den anderen listen läuft und ich zu jeder textur eine flächenliste anlege, die wiederrum den flächenindex speichert. dann kann man beim rendern/vao bla erstellen pro textur ein gesamtpaket der zu zeichnenden flächen erstellen und dann alle texturen nacheinander abarbeiten. so wechselt man dann alle texturen nur einmal durch un switcht ned laufen hin und her. natürl nur pro object. ein zweites gleiches objekt würde dann wieder alles durchgehen ^^ aber ich hoffe, das langt erstmal als optimierung.
so, nu müsst ich dann mit dieser 3d textur um dies mir eingans ging ja bei jedem texturwechsel diese textur neu "zusammenmischen". liege ich da a) vllt falsch und das lässt sich viel einfacher lösen oder is das richtig so? zumindest war meine überlegung dann dahin gehend, dass ich zu jeder "texturmischung" - die ich dann material nennen würde - eine eigene klasse baue. jede instanz dieser klasse baut dann quasi einmalig seine mischung zusammen, stellt gleich noch seine ambien/specular/diffuse eigenschaften zur verfügung usw und die textur-id würd ich dann einfach immer durchegeben, wenn was von dem material gezeichnet werden soll. irgendwie so ^^ details muss ich mir da noch überlegen.
soweit so gut. aber wenn ich jetz ne bodentextur hab zum bsp... wasn dann? xD oder einen holzschrank mit plastikgriffen? jetz ma blöde gesagt. die textur bestimmt dann, wo welches material ist, und ned die flächen. seh ich da grad den wald vor lauter bäumen nich? als erster woraround würd mir zwar spontan ne "materialmap" einfallen (greyscale und der grauwert als materialindex oder so), aber wie ich da dann die materialzuornung hinbekommen sollte... am ende müsste man ja aufs geradewohl alle materialien textur-mischungen an den shader übergeben, was aufgrund der übergabe-limitierung da doch ned geht oder?
grad nochma hier nachgelesen: "... with GLSL you can have a maximum of 16 attributes per vertex program." <- wenn man da die punktdaten, texcoords und normalen allein schon hat, + uniforms wie matrizen und texturmischung sowie flag-matrix... da bleibt ned mehr allzuviel über >< mit glück vllt 8 materialien quasi. was aber, wenn man da mehr will ^^ lichtinfos wären auch noch ne geschichte, die ich vergaß. also ich find das limit irgendwie arg knapp ^^ oder versteh ich das grundsätzlich falsch?
