(LWJGL) Aufwendiges Animieren von Texturen

[Luk10]

Grüße,

Ich bin gerade dabei eine Grafikanwendung (2D) mit LWJGL zu planen bzw. umzusetzten. Rein CPU-basiertes render ist zu leider zu langsam, deshalb will ich auf möglichst niedrig-levlige GPU-Unterstützung zurückgreifen: LWJGL

Hab ganz grobe Kenntnisse zu LWJGL und kann einigermaßen gut mit VBOs und Shadern umgehen. Jedoch habe ich keine großen Erfahrungen was Textures angeht.

Zu meiner Situation:

Ich habe 2D-Objekte, die animiert werden sollen. Dazu will hatte ich eigentlich vor die Texture zu animieren, aber das Laden, Verändern und wieder in den Grafikspeicher Laden nimmt bei vielen Objekten wahnsinnig viel Zeit in Anspruch. Ich will die Texture auf Pixel-Ebene verändern und nicht nur austauschen o.ä. wobei die Ausprägung des Austausches auch erst zur Laufzeit feststeht.

Gibt es eine gute Möglichkeit Texturen im großen Stil mit LWJGL zu verändern? Kann man für sowas evt. auch Fragment-Shader nutzen? Kenne mich da nicht besonders gut aus.

Danke,
-Luk10-

 

[Guest2]

Moin,

Gibt es eine gute Möglichkeit Texturen im großen Stil mit LWJGL zu verändern? Kann man für sowas evt. auch Fragment-Shader nutzen?

ja das geht. Wie konkret hängt dann aber davon ab, wie die Änderungen aussehen sollen.

Hier gibt es z.B. ein Beispiel, bei dem Conway's Game of Life innerhalb einer Textur / FBO / Fragment Shader abläuft. Das ist auch nichts anderes als das ändern einer Textur mit der GPU.

Viele Grüße,
Fancy

 

[Luk10]

Vielen Dank für deine Antwort. Sieht ganz interessant aus. Jedoch verstehe ich den Kern des Ganzen nicht:

Der "CONWAY_SHADER", wohl der Frag-Shader, verwendet Techniken die ich überhaut nicht kenne. Ich weiß auch nicht was in der Klasse Texture gemacht wird mit

sampler = glGenSamplers();
            glSamplerParameteri(sampler, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
            glSamplerParameteri(sampler, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
            glSamplerParameteri(sampler, GL_TEXTURE_WRAP_S, GL_REPEAT);
            glSamplerParameteri(sampler, GL_TEXTURE_WRAP_T, GL_REPEAT);
            glBindSampler(0, sampler);

Was ist ein "sampler"?

 

[Guest2]

Ja genau, der Conway Shader ist der Fragment Shader und der Teil, in dem das Eigentliche passiert. Neu bzw. ungewöhnlich sind dabei hauptsächlich zwei Punkte:

1: [c]layout(binding = 0) uniform sampler2D texture;[/c]

Seit OpenGL 4.2 kann man GLSL-Sampler (das ist etwas anderes als OpenGL-Sampler!) direkt aus dem Shader heraus an eine OpenGL-Texture-Image-Unit binden. Das ist vergleichbar mit der Verbindung die sonnst mit glUniform1i(..) hergestellt wird.

2.: [c]texelFetch(..)[/c]

Gibt es schon länger, sieht man aber nur relativ selten. Es ist vergleichbar mit dem sonnst üblichen texture2D(..). Der Unterschied ist hauptsächlich nur das texelFetch mit absoluten und texture2D mit normierten Koordinaten arbeitet.


Bei dem Teil mit dem [c]glGenSamplers()[/c] handelt es sich um einen OpenGL-Sampler (!= GLSL-Sampler ). Die Werte, die darüber eingestellt werden, sind (fast) dieselben die sonnst mit glTexParameteri gesetzt wurden (z.B. GL_TEXTURE_MIN_FILTER). Das ist einfach eine Trennung, die mit OpenGL 3.3 eingeführt wurde, zwischen dem Textur- und dem Sampler Objekt.

Hier (ab Texture Objects) ist z.B. erklärt, wie Texture Object, GLSL-Sampler, Texture Image Unit und OpenGL-Sampler Object zusammenhängen.

(Lediglich wird dort Texture Unit als Synonym für Texture Image Unit genannt, das ist leider nicht ganz richtig. TUs ist das, was man früher hatte (da hängt z.B. noch ne Textur-Matrix dran) und davon gibt es oft nur 8 Stück. TIUs sind das Neue (haben z.B. keine Textur-Matrix mehr) und davon gibt es mindestens 16 (GL_MAX_TEXTURE_UNITS vs. GL_MAX_TEXTURE_IMAGE_UNITS vs. GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS))

Viele Grüße,
Fancy

 

[Spacerat]

Wäre es evtl. angenehm, wenn du wie von AWT gewohnt per Graphics-Context in eine Textur zeichnen könntest? Sieh' mal hier.
[EDIT]Wenn ich drüber nachdenke, ist dies kaum das was du suchst. Du bräuchtest einen Graphics-Context, der auf der GPU läuft. [/EDIT]

 

[Empire@Work]

Gerade wen du wenig erfahrung mit opengl hast würde ich eher zu einer der zahlreichen java 3d engine empfehlen. Da die viele noob fehler abfangen und wahrschenlich auf effizienter sind als alles was du in den nächsten 1-2 jahren selber scheiben kannst. (ausnahme das game ist extrem simple, wirkt aber wenn du mit cpu rendern probleme hast eher nicht so)

 

[Luk10]

Hab das Thema erstmal kurz auf Eis gelegt, weil mir dazu noch einige Grundlagen fehlen. Danke für eure Hilfe.
Eine Frage schließe ich aber noch an:

Wie wichtig ist es VBO mit

glDeleteBuffers(vboHandle)

wieder freizugeben? Mir ist bewusst, dass mit Beenden des Kontext der Treiber alles aufräumt, aber ist es dennoch wichtig/wünscheswert? Kann es bei "Standard-Programmen" passieren, dass der VRAM durch alte, überschüssige VBOs überläuft?

 

[Marco13]

Ausprobieren Mein Tipp: Ja. (Auch wenn GC-verwöhnten Java-Programmierern das kalte Schauer über den Rücken jagt )

 

[Spacerat]

Afaik macht glDeleteBuffers nichts weiter, als der GraKa mittzuteilen, dass belegter Speicher wieder verwendet werden kann, sollte also nix kosten. Evtl. ist's aber besser Buffer zu mappen, damit überlässt man die Speicherverwaltung der GraKa nahezu selbst. Diese Verwaltung kann dann per GL_STATIC/DYNAMIC/STREAM_READ/WRITE/DRAW beeinflusst werden. Dann ein abschliessendes glUnmapBuffer ist dan ungefähr ebenso teuer (billig), wie ein delete.
@Marco13: Ich glaube kaum, dass der GC Einfluss auf den GraKa-Speicher nehmen kann.

 

[Marco13]

Das habe ich auch nicht angedeutet. ("Im Gegenteil"). Es ging nur darum, dass so eine Notwendigkeit, "hinter sich aufzuräumen" ungewohnt und "unbequem" sein kan...

 

[Guest2]

Auch wenn der Buffer durch Map/Unmap mehrmals neu beschrieben wird, wird in einem größeren Projekt der Punkt kommen, in dem der zugehörige Buffer nicht mehr benötigt wird. Und dann sollte man ihn imho auch wieder freigeben. Das sollte man dann auch nicht nur bei VBOs sondern bei allen OpenGL Ressourcen so machen.

Ich implementiere dazu gewöhnlich einen GLLifecycle der unter anderem eine glInit(..) und eine glDispose() vorsieht. Wenn ich dann ein "GL Objekt" implementiere, etwa "GLTexture implements GLLifecycle", dann ist es bei mir "Konvention" das glInit() alles notwenige macht, um die notwendigen Ressourcen im OpenGL Kontext zur Verfügung zu stellen. glDispose() macht das Gegenteil und gibt alles wieder frei. Das verstößt zwar brutal gegen RAII (Resource Acquisition Is Initialization) aber in höheren Objekten kann man das dann ggf. wieder sauber kapseln. Irgendwo muss man halt OpenGL und OOP annähern

Bei kleinen Projekten oder KSKBs kann man vielleicht drauf pfeifen, da kriegt man den Speicher eh nicht sinnvoll voll.

Viele Grüße,
Fancy

 

[Empire Phoenix]

Tatsächlich kann man auch relativ sinnvoll einen phantomrefrence nehmen um mitzubekommen wann die opengl objecte nichmehr benötigt werden, und dann die ressourcen freigeben. Ist etwas schöner, und mehr java artig.

 

[Guest2]

Stimmt, danke für den Tipp! Da hatte ich auch noch nicht drüber nachgedacht.

Allerdings könnte ich mir vorstellen, dass das an einigen Stellen durchaus etwas haarig werden könnte, z.B.: Synchronisation zwischen den Threads, mehreren verschiedenen OpenGL-Kontexten, bei Verlust eines OpenGL-Kontextes, VRAM voll aber GC will noch nicht...

Oder noch viel schlimmer: Ich will eine Textur laden, binden und OpenGL-seitig ewig nutzen. Dan bräuchte ich Java-seitig aber keine Referenz mehr auf die Textur. Wenn der GC / PhantomReference das nun mitbekommt, würde das Freigeben der OpenGL Ressourcen angestoßen werden. Da bräuchte ich die aber noch!

Das Ankoppeln des OpenGL Lebenszyklus an den GC hat sicherlich Vorteile, aber ob diese immer / meistens / oft / manschmal überwiegen?

(Die Verletzung des RAII bei der Erzeugung ist davon natürlich unabhängig.)

Viele Grüße,
Fancy

 

[Spacerat]

...von daher ist diese PhantomReference die wohl weitaus schlechtere Idee, als wenn man mal ein glDeleteBuffer oder glUnmapBuffer vergisst.

 

[Marco13]

Hmmjaaa, Phantom- und WeakReferences sind für solche Dinge nicht wirklich geeignet. Das nicht so offensichtliche Hauptproblem ist, dass man nicht weiß, wann sie weggeräumt werden. Im schlimmsten Fall: Nie. Das offensichtliche Hauptproblem ist damit verwandt, und Fancy hat es schon in einem Halbsatz angedeutet: Man kann sich z.B. auf einer 1GB-Karte 10 GL-Bufer (mit PhantomReferences) erstellen. Jeder dieser Buffer ist 100MB Groß. Dann braucht man 9 davon nicht mehr, und löscht ihre Referenzen, so dass sie dann beim Abarbeiten der PhantomReferences in der ReferenceQueue mit glDeleteBuffer wirklich gelöscht werden. Aber BIS das passiert, ist der Speicher der GPU erstmal voll. Und wenn man nun einen weiteren GL-Buffer mit 100MB allokieren will, dann juckt das den GC überhaupt nicht: Der kennt nur ein paar byte (von den SoftReferences und ein paar ID-ints), und denkt, es wäre noch massig Speicher frei. D.h. beim Versuch, weiteren GL-Speicher zu allokieren, kracht es...

 

[Luk10]

hmm ich hätte noch eine Frage. Ich habe gerade diverse Guides zu Buffer mapping angeschaut, jedoch verstehe ich den Unterschied, bzw. den Vorteil gegenüber der "normalen" Methode nicht (bezieht sich auf aktualisieren von Daten im VBO).

Soweit ich das jetzt verstehe
> allokiert man mit der normalen Methode speicher und kann mit glBufferSubData einen Bereich des VBOs durch neue übergebene Daten austauschen lassen.

> kann man mit mapping von Buffern direkt und selbst in den Buffer schreiben

Für meine Anwendung ändern sich die Koordianten von einige Verticies sehr, sehr oft. Deshalb suche ich nach günstigen Methoden.
Kann mir jemand einen einfachen und grundlegenden Guide oder eine Erklärung liefern, was es mit Mapping / Unmapping von Buffern auf sich hat? Bitte einfach halten, ich habe nicht besonders viel Erfahrung damit.

Danke!

 

[Guest2]

Das ist ein ziemlich weites Feld, auf dem es viele verschiedene Varianten gibt. Diese Links sind dabei wohl ziemlich wichtig:

Vertex Specification - OpenGL.org
Vertex Specification Best Practices - OpenGL.org
Buffer Object - OpenGL.org
Buffer Object Streaming - OpenGL.org

Insbesondere der letzte Link beschreibt, wie Du deine dynamischen Vertexkoordinaten am besten auf die Grafikkarte bekommst. Allerdings solltest Du dir die anderen Links auch ansehen, da man dabei ziemlich viel falsch machen kann:

OpenGL puts in place all the guarantees to make this process work, but making it work fast is the real problem.

Viele Grüße,
Fancy