Hallo zusammen,

Ich entwickle derzeit eine Art Worms-Klon mit C++ und OpenGL. Die Texturen sind hochauflösend und es gibt die Möglichkeit 4-fach rein zu Zoomen. Zu guter Letzt sind die Level wesentlich größer.
Als Anfang habe ich mir einen Animationseditor und einen Leveleditor erstellt, bevor ich mit der eigentlichen Engine beginne.

Die Levelerstellung funktioniert momentan durch Einlesen eines schwarz-weiß-Bitmaps. An Farbwechseln werden dann Punkte als Decken und Böden identifiziert. Die so ermittelten Punkte werden anschließen via kubischen Splines verbunden, sodass eine schöne kantenlose Oberfläche entsteht. Weiterhin ermöglichen die Splines eine technisch einfach umsetztbare Kollisionsanalyse.

Zuletzt werden die Texturen darüber gelegt. Dies geschieht wie folgt:

Ich teile meine Landschaft in gleich große Felder auf. Jedes dieser Felder hat die Größe 512x512 Pixel. Für jedes dieser Felder bestimme ich, welche Bereiche "Luft" und welche "Boden" sind. Danach erweitere ich meine Ausgangstextur in dem entsprechenden Rasterblock um die ermittelten Alpha-Werte und binde sie anschließend. Das Ganze funktioniert so weit wunderbar, das Ergebnis sieht echt toll aus, nur kostet es mich auch eine Menge RAM. Bei größter Levelgröße gehen mal eben 2 Gig drauf.
Ich habe bereits leere und komplett ausgefüllte Raster herausgefiltert, sodass diese keinen Extra-Speicher benötigen. Dadurch konnte ich schonmal ne Menge Speicher wieder raus holen, allerdings hängt dieser vom Levelaufbau ab. Im schlimmsten Fall bin ich wieder bei 2 Gig. Jetzt war meine Idee folgende:

Ich binde die ermittelten Alpha Werte als reine Alpha-Textur. Erst wärend des Zeichnens innerhalb eines Frames sollen dann die Alpha-Textur und die ausgangsTextur miteinander vereint werden. Da der sichtbare Bereich durch einen Zoom-Faktor begrenzt wird, sollte sich der zusätzliche Rechenaufwand in Grenzen halten. Der Knackpunkt bei der Sache ist nur folgender:

Ich weiß nicht ob OpenGL eine Funktion anbietet, gebundene Alpha-Texturen mit gebundenen RGBA-Texturen möglichst schnell zu rekombinieren. Wenn jemand den Namen einer solchen Funktion kennt, wäre ich zu tiefst dankbar. Damit könnte 3/4 Speicherbedarf einsparen, was das Ganze wieder erträglich macht. (500 Mb hat heute ja nun fast jeder Rechner).

Für weitere Tipps, den Speicherbedarf gering zu halten, wäre ich ebenfalls dankbar.

MfG Der Troll

Wenn es wirklich nur darum geht, eine RGBA texture mit einer Alpha texture zu kombinieren,
dann würde ich dies mit GLSL und shadern machen. Das sollte ziemlich einfach sein.

Ich würde die Alpha-Texturen im Fragmentshader on-the-fly generieren. Dann benötigst du nur Speicher für deine Ausgangstextur die sagt wo was ist. Shader wirken auf den ersten Blick kompliziert, auf den zweiten Blick machen sie viele Dinge aber deutlich einfacher. (In diesem Fall kannst du deine ganze Speicherverwaltung für die Alpha-Texturen einsparen...)

Du musst quasi deinen Algorithmus der ermittelt wo Boden und wo Luft ist im Fragmentshader implementieren. Du entscheidest dabei einzeln für jeden Pixel (Fragment) welche Textur er benutzen soll. Um dir da zu helfen bräuchten wir genauere Infos wie du das genau machst.

=> http://wiki.delphigl.com/index.php/Tutorial_glsl

_________________
Yeah!

Mh... ich habe noch nicht sonderlich viel Erfahrung mit OpenGL. Kurzes Suchen ergab, dass die ganze GLSL Geschichte nicht mal eben mit 3 Zeilen abgehandelt ist und auch schon einen guten Grundstock an Vorwissen benötigt. Sicher kann ich auch erstmal mit der momentanen RAM-Auslastung weitermachen und später, wenn ich mehr Erfahrung mit OpenGL habe dann nachbessern, aber was ich so gelesen habe ist das ein wenig mit Kanonen auf Spatzen schießen?



Also die Bestimmung, welcher Teil solide und welcher nicht solide ist, ist leider icht ganz so simpel, auch wenn man das im ersten Augenblick erstmal denken mag. Ich versuche mal kurz das grobe Vorgehen zu schildern:

Mein Level ist ja zunächst in "Decken" und "Böden" durch die Spline Funktionen definiert. Ich muss also ermitteln, ob ein Punkt genau zwischen einer Decke oder einem Boden liegt (Spielfeldbegrenzungen ergeben Sonderfälle). Dazu bestimme ich alle y-Werte der Splines, die den x-Wert des betrachteten Pixels enthalten. Um nicht alle erhaltenen y-Werte mit jedem Pixel mit dem selben x-Wert neu vergleichen zu müssen, bestimme ich, ob der Punkt mit x=0 solide ist und gehe dann davon ausgehend alle Pixel mit diesem x-Wert durch. Sobald ich auf eine Decke oder einen Boden stoße, ändere ich den Alpha-Wert und mache weiter, bis ich am oberen Rand angekommen bin.

Sicherlich lässt sich bei dem Verfahren noch ein wenig optimieren, allerdings sollte unter einbeziehung des Zoomes (4-Fach) und der betrachteten Bildschirmauflösung von 1600x900 schnell klar werden, dass ein on-the-fly berechnen der Alpha-Werte eher nicht in Frage kommt (dass wären weit mehr als 4-Millionen Schleifendurchläufe).

Wie gesagt, am einfachsten wäre für mich folgende Lösung:
Ich binde mit glTexImage 2d einmal die AusgangsTextur als RGBA und für jedes Raster die Alpha-Werte als GL_Alpha. Beim Zeichnen erstelle ich mir eine "Buffer"-Textur, in die ich die RGB-Werte der Ausgangstextur rein kopiere und anschließend die Alpha-Werte der Alpha-Textur. Dann wird die Buffer-Textur an der entsprechenden Stelle gezeichnet.

Wäre dies mit folgendem Befehl machbar:

glCopyTexImage2D

MfG Der Troll

Im Fragmentshader benötigst du immer nur den Alphawert des Pixels (Fragments) das gerade gerendert wird. Du würdest also deine schwarz-weiß-Bitmap-Leveltextur lokal an der entsprechenden Stelle auswerten und nur die lokal nötigen Splines im Shader generieren. Da du C++ verwendest kannst du vielleicht sogar etwas Code im Shader wiederverwenden, GLSL ist ja sehr C ähnlich.
Aber die Verwendung von Splines macht die Sache wirklich komplex. Vermutlich für OpenGL-Anfänger wirklich nicht zu empfehlen.


Eine CPU mag da ins schwitzen kommen, aber eine aktuelle GPU wird sich fast langweilen. Eine GPU hat zwar weniger MHz, arbeitet aber massiv parallel. D.h. du musst es nur schaffen deinen Algorithmus irgendwie so umzubauen das er parallelisiert werden kann. Er muss also in viele kleine gleichartige Einzelaufgaben zerteilt werden, etwa die Berechnung des Alpha-Werts für einen einzigen Pixel. Wenn dir das gelingt kann das durchaus 50-100mal schneller als eine CPU sein!

Ich möchte einen anderen, simpleren Ansatz kurz umreißen. Wenn du das für sinnvoll hältst kann ich das auch noch näher erläutern.
Also dein Level ist eine Bitmap-Textur mit 1 für Luft und 0 für den Boden, richtig? Diese Textur hat vermutlich eine relativ geringe Auflösung, weshalb du deine Sache mit den Splines gemacht hast.

Hier mal ein Beispiel-Bitmap. Das Bild ist 8x größer damit man die Pixel gut sieht.

Wenn du im Shader einfach nur so auf die Texturkoordinaten zugreifst, bekommst du eine lineare Interpolation. Das sieht natürlich reichlich bescheiden aus.

Wendest du allerdings im Shader einen Gausskernel ("Weichzeichner") mit einem Radius von 3px an, bekommst du sowas. Das ist logischerweise zu weich:

Wenn du jetzt aber den Kontrast erhöhst sieht das dann wie folgt aus. Je nach dem wie stark du den Kontrast erhöhst, bekommst du einen harten 0/1 Übergang (einfach bei <>0.5 entscheiden) oder sogar mit Anti-Alias wie hier im Bild:

Die Bilder sind natürlich mit GIMP gefaket, aber das sieht doch wunderbar aus, oder?

Da der Radius beim Gauss nur 3px beträgt kannst du das wunderbar on-the-fly im Shader machen. Du schaust eben einen Bereich von 7x7 Bereich von Pixeln an und summierst die Farbwerte anhand von ein paar vorberechneten Faktoren auf. Vom Prinzip das in diesem Post-Effekt-Shader passiert, allerdings in einer 2D-Variante da ein zwischenspeichern nicht (so einfach) möglich ist. Diese Shader wäre relativ einfach, ich denke den würdest du mit etwas Hilfe hier aus dem Forum hinbekommen.

_________________
Yeah!

Das sieht wirklich schon sehr gut aus. Frage ist halt nur, ob das abgebildete am Schluss noch mit den durch die Splines gegebenen Koordinaten übereinstimmt. Die Splines werden ja nachher noch für eine Kollisionsabfrage ran gezogen. Ich möchte möglichst vermeiden, dass meine animierten Objekte nachher in der Luft stehen oder gar im Boden versinken, weshalb abgebildete Kanten immer dem Spline-Wert entsprechen sollten. Gut, wenn es sich im Pixelbereich bewegt, sollte es vernachlässigbar sein.

Ich sage mal, sollte es keinen anderen Möglichkeit geben, werde ich diesen Weg durchaus mal ausprobieren, allerdings muss ich auch einräumen, dass ich von Shadern momentan noch absolut nichts verstehe.

Ich habe mal Testweise nur eine reine Alpha-Textur statt der RGBA Textur erzeugt und der Speicherbedarf ging wie erhofft auf ein Viertel zurück. Weiterhin waren die betroffenen Bereiche während des Programmablaufes weiß statt texturiert, die Kanten waren jedoch noch korrekt abgebildet. Deshalb kam mir die Idee, evtl auch Masking zu verwenden.

http://www.codeworx.org/opengl_tut20.php

Bitte verzeih, aber ich versuche eine möglichst einfache Lösung für mein Problem zu finden, dass ich erstmal leicht begreife und für das ich keine lange Einarbeitungszeit benötige. Ich denke der von dir vorgeschlagene Weg ist sicher zielführend und vermutlich auch schon nah am Optimum, aber dein OpenGl Wissen ist vermutlich auch 100 mal größer als meines.^^ Ich glaube momentan würde mich dieser Weg schlichtweg überfordern.

Wäre denn das Masking oder der im vorherigen Post genannte Befehl glCopyTexImage2D auch ein Weg der funktionieren könnte? Wenn das Programm erstmal so weit ist, dass es ans optimieren geht, habe ich zum einen vermutlich schon mehr Erfahrung mit OpenGL und kann mich zum anderen völlig darauf konzentrieren das letzte raus zu holen. Momentan gibt es aber noch so viele Baustellen, dass ich mich ungern mehr als 2 Wochen mit einer einzigen auseinander setzen würde. Trotzdem erstmal danke für diesen Vorschlag... das zeigt mir mal wieder, dass es noch so viele Dinge gibt, von denen ich noch gar keine Ahnung habe^^

MfG Der Troll

Das hier könnte hilfreich sein:
http://www.opengl.org/wiki/Texture_Comb ... ha_of_tex0
Auf Textur-Kanal 0 wäre deine Alpha-Textur, während Textur 1 und Textur 2 Boden bzw. Luft sind. Das ganze "Texture Combiners"-System ist natürlich völlig veraltet weil das mit Shadern deutlich einfacher geht (wenn man einmal die nötige Infrastruktur für Shader hat), siehe auch das Beispiel unten im verlinkten Abschnitt.

Siehe auch die (ganz ganz) alte Extension dazu als das noch nicht Teil des OpenGL-Kerns war: http://wiki.delphigl.com/index.php/GL_A ... nv_combine

Nicht zu vergessen die Warnung am Anfang des Artikels:

_________________
Yeah!

Ich würde dir raten, dich zuerst mit Shadern zu beschäftigen. Dann wird es nämlich viele Probleme garnicht mehr geben. z.b. die Combiner Funktionen, Blending oder Masking. Ich selbst kenne die Combiner nur aus den Tutorials, da ich direkt mit den Shadern angefangen habe.
Die Shaderunterstützung in dein Programm einzubauen, ist im Prinzip nicht viel Arbeit. Die Sourcen der Shader aus den Dateien laden und Compilieren, Linken und Binden wenn man sie verwenden will. Bei Nehe ist es ordentlich beschrieben und direkt mit c/c++ code;

Bzgl deines Problems: Könntest du mal einen Screenshot hochladen, der die Splines zeigt.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Okay, nach einigem rumprobieren, bin ich nun zu der Ansicht gelangt, dass ich wohl oder übel in den sauren Apfel beißen muss und um Shader nicht herum komme. Den geforderten Screen werde ich morgen mal hochladen. Das NeHE Tut werde ich mir auch mal anschauen. Hoffe das ist wirklich so gut wie beschrieben. Naja, zur Not kann ich ja euch auf den Wecker gehen. :p Ansonsten erstmal eine gute Nacht.

Eben. Gibt ja n Leute hier, die schonmal nen Shader gesehen haben. Und dann demnächst n+1

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

So, ich habe nun mal ein bisschen nachgelesen und rumprobiert. Nachdem ich mir einen Tutorial Code runter geladen und diesen zum laufen gekriegt habe, habe ich die Kernelemente in mein Programm rüber geschoben und das Ganze ebenfalls zum Laufen gebracht. Da kam natürlich erstmal völlige Grütze bei raus und mittlerweile ist mir auch klar warum ---> Der Shader behandelt keine Texturen gibt aber absolute Pixelwerte zurück.
Ich glaube nun ein grobes Verständnis entwickelt zu haben, wie ich mein Problem mit Shadern in den Griff kriege. Ich binde via Multitexturing meine Ausgangstextur und meine Alpha-Textur. Im Shader setze ich dann meinen Pixel aus den RGB-Werten der Ausgangstextur und den Alpha-Werten der Alpha-Textur zusammen. Ist das so grob korrekt?

Ansonsten wären da noch ein paar Sachen, die ich gerne wüßte:

- Wie kann ich Shader nach Bedarf anfordern, also den entsprechend benötigten Teil aus und einschalten?

- Wo sollte ich den Shader wenn möglich initialisieren? Ich habe es bisher einfach in die Initialisierung meines GL-Fensters rein gebastelft

- Theoretisch sollte es doch auch möglich sein, den Shader im Quellcode zu hinterlegen oder einer verschlüsselten Binärdatei, damit keiner dran rumpfuschen kann, oder? Wenn ich es richtig verstanden habe ist er ja nur eine Zeichenkette die wärend der Initialisierung interpretiert wird... Korrekt?


Ansonsten erstmal ein dickes Danke, dass ihr mich so hartnäckig in diese Richtung gelenkt habt. Vermutlich hätte ich mich sonst nie damit beschäftigt. So wie es bisher aussieht kann ich damit viele Dinge vereinfachen und verbessern. Trotzdem werde ich euch noch weiter nerven.

MfG Der Troll

PS: Screen reiche ich noch nach und habe ich nicht vergessen^^

Gib mir zwei Tage und einen Debugger (den hab ich sogar) und ich pfusche auch so daran herum. Das Vorgehen ist sinn- und grundlos.

Ansonsten, Initialisierung beim Start ist sinnvoll, ja. Wenn du Shaderteile ein-/ausschalten willst, kannst du dies entweder per If und Uniform-Parameter machen oder (besser) mehrere Varianten des Shaders kompilieren. Dabei bietet sich eine kleine Präprozessorsprache ala #ifdef/#endif an (sowas ist schnell geschrieben).

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Wenn du zur Laufzeit aufgrund bestimmter Bedingungen entscheiden willst, kannst du da einfach if-Anweisungen verwenden.
Allerdings lohnt es sich schon, je nach Fall, einfach einen 2. Shader zu nehmen. Wenn der Shader z.b. nur in 99,9% in den einen Zweig der Bedingung springt, haste ne Menge Zeit für die Anweisung verschwendet, wenn man die Entscheidung auch vorher im Programm hätte treffen können.

Ich benutze dafür eine ShaderManager Singleton-Klasse, die alles behandelt. Also Shaderdateien laden, compilieren und linken. Im eigentlichen Programm kann ich dann mit ShaderManager.getInstance().bindShader("simple_light"); den Shader auswählen. Beim Laden werden evtl. noch Änderungen am Quelltext vorgenommen (z.b. Konstanten einfügen, die nicht zur Laufzeit geändert werden; z.b. Höhe und Breite der Schattentextur)

Klar kannst du das. Aber warum sollte man? Wenn jemand dran rumpfuscht, läufts eben nicht mehr. Pech gehabt.
Du brauchst die Uniformlocations nur einmal ermitteln. Jedenfalls solange bis du den Shader zur Laufzeit neu compilierst.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Jap. Du kannst sogar Luft und Boden gleichzeitig rendern, ca. so:

Also einfach coden was passieren soll und nicht mit irgendwelchen obskuren "Texture Combinern" hantieren.

_________________
Yeah!

Vielen Dank erstmal, für die Infos. Ich mache das ein und ausschalten von Shadern nun momentan mit glDetachShader(). Allerdings muss ich das Programm dann neu Linken und aktivieren, andernfalls übernimmt er die Änderungen nicht. Ist das soweit korrekt? Bzw meinte ja wer, dass ich besser zwei Shader Programme generiere und zwischen denen hin und her switche.

Ich brauche den Shader ja momentan nur für die Übergangselemente zwischen Luft und Boden (Auch wenn ich denke, dass ich später wohl doch etwas mehr damit rum spielen werde, das bietet ja doch einige Möglichkeiten). Dementsprechend würde ich ihn für alle anderen Zwecke einfach abschalten. Gibt es einen Befehl, womit ich OpenGL sage einfach gar keinen Shader zu verwenden oder muss ich mir ein "Standard"-Shader mit meinen Standardeinstellungen generieren?

Ansonsten versuche ich einfach mal den Shader den ich haben will zu proggen und Poste dann mal den Quellcode hier, damit ihr euch dann über das schlechte Coding auslassen könnt^^.

MfG Der Troll