Hi,

Ich hab mir eine Möglichkeit überlegt, wie man komfortabel Texturen binden kann.
Ähnlich wie beim Texture-Manager von Sascha.
Dort hat mich jedoch gestört, dass die Texturen als string angesprochen werden. Ich nehme mal nicht an, dass solch eine Vorgehensweise gut für die Performance ist. Andererseits bietet sie einen großen Komfort.

Als Alternative erschien mir noch das Ansprechen über ein Array. Allerdings wollte ich die Texturen nicht über Nummern ansprechen, sondern schon über irgendeine Art Name.

Ich hab mich dann etwas vom PCode-Tutorial inspirieren lassen und spreche seitdem die Texturen so an:
Code zur Definition der Texturen:


Laderoutine:


Und hier dann die Verwendung:


Mögliche Definition für Textures:



Was haltet ihr von dieser Methode? Was gibt es noch für alternativen? Was könnte man noch optimieren? usw...

Gruß,
SpaceJunky

Das Problem ist, das deine Anzahl von Texturen beschränkt ist. Mach dir doch eine TStringList mit den Texturen. Dann speicherst du am besten bei jeder Texture noch einen Zähler wie oft sie verwendet wird.
Ich habe bei mir alle Texturen in einer Liste gespeichert. Mit TTexture2D.LoadTexture lädt man eine Texture, falls sie noch nicht in der Liste ist und erhöht den Zähler. Wenn man die Texture nicht mehr braucht wird die Methode Release aufgerufen, die den Zähler erniedrigt. Falls der Referenzzähler dabei den Wert 0 erreicht, wird die Texture freigegeben und aus der List entfernt.
So werden die nötigen Texturen immer bei Bedarf geladen, ohne dass unnötige Texturen im Speicher bleiben und man muß auch nicht am Anfang oder Ende des Levels einen großen Ladevorgang durchführen.

Wieso ist meine Anzahl von Texturen beschränkt??? Oder meinst du die normale Hardware-Beschränkung?
Könntest du mir das mit der Stringlist und dem Zähler mal nochmal erläutern? Klingt interesant. Aber ich seh schon die FpS in den Keller gehen bei der Verwendung von Stringlisten. Auch wenn es sortierte HashedStringlisten sind.

Warum sollen StringListen denn die FPS in den Keller bringen? Im Normalfall rendert man ja eh über Displaylisten oder VBOs, und da sind die Aufrufe an eine Stringlist doch recht wenige.

Deine Methode ist halt total statisch weil du ein Set benutzt. Von daher recht unbrauchbar für Anwendungen die ihre Szenen dynamisch laden wollen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Die String Liste muß doch nur angesprochen werden, wenn eine neue Texture geladen wird. Und das passiert normalerweise nicht so häufig. Ansonsten hat man ja das Texture Object.

Viele Objekte werden ja gemeinsam benutzt und deshalb muß man beim Objekt speichern wie oft es benutzt wird, damit man es korrekt freigeben kann. Das ist nicht nur bei Texturen sondern eigentlich bei ganz vielen Objekten wie Modellen, Sounds, usw... so.

Speziell auf die Texturen bezogen kann man das so machen:

TTexture=class
private
..
refcount:Integer;
public
...
procedure AddRef;
procedure Release;
class function LoadTexture(const name:string):TTexture;
...
end;

Laden einer Texture.
-Eine Funktion die einen Texturenamen übergeben bekommt.
Die Funktion schaut nach, ob die Texture in der Liste ist. Wenn sie nicht drin ist, wird sie geladen.
Der Referenzzähler wird erhöht, weil die Texture ja jetzt einmal mehr verwendet wird.
Das Texture Object wird zurückgegeben.

Danach wird ganz normal mit dem Objekt gerarbeitet.

Freigeben einer Texture:
-Der Zähler wird erniedrigt. Wenn er jetzt bei 0 ist, dann war das die letzte Referenz und die Texture kann gelöscht werden.

So ungefähr könnte man das programmieren.



Eine Alternative sind die Interface Typen. Die haben automatisch einen Referenzzähler und werden von Delphi verwaltet. Man kann daher davon ausgehen, dass das Objekt automatisch gelöscht wird, wenn es keine Referenzen mehr darauf gibt.
Das Problem beim Referenzzählen ist, dass es Schwierigkeiten gibt, wenn sich Objekten gegenseitig referenzieren, aber bei diesen typischen Klassen die GL Objekte kapseln ist das üblicherweise nicht der Fall.

Da hab ich einfach hineininterpretiert, dass eine möglichst schnelle Lösung zu bevorzugen ist. Und da ich bei Napalm-Bomber nur 30 fps kriege, hab ich das auf die Stringlist zurückgeführt.

Meine Methode ist tatsächlich statisch. (Im Gegensatz zu der da oben ) Was ich aber nicht unbedingt als Nachteil empfinde.

Ist halt mehr für kleine Projekte gedacht, deren Texturen statisch sein können.

Die THashedStringList ist natürlich die bessere Variante wenn sie bei deiner Delphi Version dabei ist(ab 6).
Aber man braucht während des Renderns ja sowieso nie die String Liste, weil man ja optimalerweise direkt mit den Objekten arbeitet.

Und wir bindest du die Texturen dann?
Sammelst du die TTextures in einem Array? Dann wirst du wohl über Nummern darauf zugreifen:


Und wieso muss eine Stringliste angesprochen werden, wenn eine neue Textur geladen wird? Ich dachte eigentlich, dass die angesprochen wird, wenn die Textur dann gebunden wird.



Ich erzeuge meine Objekte immer nur einmal und gebe die dann auch nur einmal frei. (Lässt sich nicht vermeiden, wenn man nur bis 3 zählen kann ). Spaß beiseite: Was meinst du damit???

Mit welchen Objekten??? Seh ich den Baum vor lauter Wäldern nicht?

Wenn du irgendwo eine Texture benötigst dann kannst du dir natürlich die Texture Nummer von OpenGL holen oder nimmst gleich das Objekt, das bei dir diese Texture kapselt. Auf diesem Objekt mußt du dann nur noch so eine Methoden zum Binden aufrufen. Die TextureID von OpenGL ist ja dann vermutlich in dem Objekt gespeichert und kann direkt verwendet werden.

Die String Liste benötigt man nur um Texturen nicht mehrfach zu laden.

Angenommen du hast ein 3D Model und das hat immer genau eine Texture.
Dann muß diese Texture natürlich vor dem ersten Rendern geladen werden. Man muß also in der Liste nachsehen ob die Texture bereits geladen ist und falls nicht, die Texture dann eben laden. Ich hatte in dem vorherigen Bsp vergessen die neu erstellte Texture in der Liste zu speichern.
Das 3D Modell bekommt dann nur das Textureobjekt. Wenn die Texture gebunden werden soll, muß man nicht suchen, weil man diese Texture ID von OpenGL ja mit in dem Objekt speichert.
Wenn das Model irgendwann wieder gelöscht wird, dann sollte es die Texture ja auch wieder freigeben. Das Problem ist aber, das inzwischen schon ein anderes Model die gleiche Texture angefordert haben könnte. Da man Texture nicht doppelt laden will, hat man dem anderen Model natürlich die gleiche Texture gegeben.
Damit es jetzt keine Probleme gibt, speichert man bei jeder Texture wie oft sie rausgegeben wurde. Wenn eine Texture jetzt nicht mehr benötigt wird, kann man den Zähler dann wieder einen runtersetzen. Wenn man dann 0 erreicht gibt es keine Modelle mehr die diese Texture erhalten haben und sie kann problemlos gelöscht werden.

Ich hab irgendwie das Gefühl, du redest über was anderes...

Mein "Problem" ist, dass ich möglichst komfortabel rogrammieren will (Wer will das nicht?
Und daher möchte ich bei meinem Texture-Manager auch möglichst komfortabel die Textur auswählen, die ich brauche.
Also sowas wie TextureManager.BindTexture('wand-textur');
Zu diesem Zeitpunkt ist die Textur ja bereits im Speicher. Es geht mir nur darum, sie beim Namen zu nennen.
In diesem Beispiel hier muss der Textur-Manager erstmal in einer Stringliste suchen, welche Textur mit 'wand-textur' gemeint ist, damit er auch die richtige Textur aus seinem Textur-Array bindet.
Also sowas da:

Ich vermute aber, dass durch dieses suchen das ganze recht langsam wird.

Aber deine mit dem Zähler und der "intelligenten" Texturen-Verwaltung (Was wir grad nicht brauchen, brauchen wir nicht, und was wir brauchen laden wir uns) ist genial.

Du könnest die Texturen auch gleich in Variablen speichern, die den einen entsprechenden Namen tragen:

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Hmm. Ich will die Texturen aber in einer Schleife oder etwas ähnlichem laden.
Bei so einem record sähe das doch dann so aus:

Genau. Und dort wird dann ganz Übersichtlich festgelegt wo welche Datei geladen wird.
Gegeben falls nutzt du dann zum Laden nicht diese Funktion sondern eine eigene welche auf Fehler reagiert und die Verzeichnisse verwaltet.

Mehr als dich umstimmen kann ich nicht
MfG
Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut