Zusatz:
Wenn die Umwandlung von ASCII-Zeichen (aus dem Uniform-Array) in Texcoords aufwendig ist weil die Buchstaben z.B. nicht einfach nacheinander in der Textur stehen kann man auch eine LookUp-Textur verwenden. Hier bietet sich ein Texturbufferobject vom Typ GL_RGBA32F_ARB an. Rot und Grün sind dann die Texcoords oben links, Blau und Alpha die Texcoords unten rechts, etc...

(Texturbufferobjekte sind nichts anderes als 1D-Texturen auf die man nur mit Integer-Koordinaten zugreifen kann. Es gibt also keine Interpolation benachbarter Pixel. Ideal wenn man im Shader ein Array mit Daten benötigt )

_________________
Yeah!

Oc2k1 hatte mal vor langer Zeit eine Möglichkeit implementiert, um über Shader dynamische Texte Darzustellen.
http://lumina.sourceforge.net/Tutorials/Hello_World.html

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Wow, DAS muss ich mir anschauen. Sieht auf den ersten Blick wirklich gut aus (ich mein jetzt den Shader, das Bild dazu aber auch). ich glaub langsam lichten sich die Nebel, wie man mit OpenGL3 Text ausgibt. Mein Kompliment und Dankeschön an oc2k1.


Bist Du Dir sicher? Das wäre doch dann immediate mode, und den gibt es in OpenGL3 doch nicht mehr. Ich dachte, man zeichnet ab OpenGL3 alles nur mehr mit VBOs. Die haben dafür ja diese verschiedenen Rendermodi, es gibt auch den Modus "DYNAMIC_DRAW", das ist praktisch fast so etwas wie Immediate Mode.

So wie ich das verstanden habe ist der "Immediate Mode" nur glBegin...glEnd und das wurde in OpenGL 3 entfernt. Ich will mich da aber auch nicht zu weit aus dem Fenster lehnen.

_________________
Yeah!

Als auszug aus dem OpenGL3 Wikiartikel, den ich aktuell schreibe.
Also alle Befehle, die zwischen glBegin und glEnd gepackt wurden sind geschichte und glDrawArrays gehört nicht dazu.
Neben VBO(Vertex Buffer Object) gibt es noch VA(Vertex Array), VAO(Vertex Array Object) und diese werden über z.B. glDrawArrays angesprochen.
Es gibt dann noch weitere Möglichkeiten VBO, VA und VAO zu zeichnen wie z.B. glDrawElements, welches ein Indexliste benötigt.
Nebenher sind noch einige weitere dinge rausgefallen aber diese haben nicht direkt mit dem Immedate Mode zu tun(alle Matrizen, Licht, Material funktionen(z.B. glLoadMatrix) und Konstanten(z.B. GL_MODELVIEWMATRIX) aus der API entfernt worden).
In OpenGL3 gibt es auch TextureArrays, welche das binden von Texturen leichter macht. NVidia und AMD haben auch schon eine EXT für OGL3 zur verfügung gestellt, welche erlaubt ganze Bindinggruppen zusammen zu fassen, indem ein weiteres BufferObject eingebaut wurde, welches die Speicheradressen, der Texturen und weiterer BufferObjects(z.B. VBO,FBO) , im VRAM, abfragt und dann in den neuen Buffer hinterlegt. Dies erlaubt dann ohne Bind befehle auf die Ressourcen zu zugreifen und somit massive viel Zeit, auf der CPU, zu sparen. Ich denke, dass wird mit OpenGL3.2 dann als ARB und dann mit OpenGL3.3 als Core hinzu kommen, da dies mit OpenGL3 einer der größten Bottlenecks geworden ist.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Aha, Danke. Jetzt seh ich ein wenig klarer. Ich dachte, man MUSS jetzt VBO benutzen. Damit wäre Ayas Frage eigentlich beantwortet: für einzelne Quads ist ein Vertex Array viel sinnvoller als ein VBO.

Das wird gut sein. Die Bufferbinderei geht mir ziemlich auf die Nerven und der Code wirkt auch nicht eben elegant.

Tut mir leid, wenn ich da jetzt irgendwelche Träume zerstöre oder so etwas. Aber selbst einfacher Text besteht aus mehr als einer Textur mit 16x16 Zeichen und einem Text. Diese Technik wie oc2k1 sie einsetzt darf man nur als Spielerrei ansehen. Nichts gegen oc2k1s Fähigkeiten aberum halbwegs ernsthaften Text auszugeben ist das schlicht nicht brauchbar. Das Ergebnis muss passen und das tut es dort nicht.

Die Texturen die ich in der TextSuite erzeuge sehen in etwa wie folgt aus. Dabei sind die Buchstaben durch einen PostProcessor leicht grau hinterlegt (+ 1 Pixel Rand in schwarz), um die Kanten besser zu sehen. Die 4 nicht asiatischen Fonts haben auch jeweils eine andere Farbe, um sie besser erkennen zu können.
http://textsuite.opengl24.de/images/gallery/Texture.png

Texturen mit einer Gridanordnung haben enorm viel Verschnitt. Und wenn dann benötigt man in jedem Fall auch noch mapping tabellen. Sonst könnte man nur von Zeichen 0-255 benutzten. Was schlicht nicht brauchbar wäre. Obendrein kommt aber noch hinzu, dass jedes Zeichen eine eigene Laufweite hat und auch noch über und unterschnitten sein kann. Beispiel. W ist breiter als I. Also größere Laufweite. J ist ein klassischer Buchstabe der Unterschnitten wird. Der muss also weiter links gezeichnet werden als er eigentlich anfängt. Und dabei habe ich noch nicht mal Kerning berücksichtigt. Wo für Buchstabenkombinationen eine Laufweitenanpassung hinterlegt ist. zum Beispiel 'VA'.


Lord Horazont: GL_ARB_map_buffer_range. Gehört zum 3.0 Kern. Ist aber eine ganz normale ARB Extension.

Bin leider gestern abend nichtmehr zu gekommen irgendwas zu testen... mach ich aber dann heute abend

Die 3 dinge gibt es jetzt die ich durchtesten werde:

- glMapBuffers
- glSubBufferData
- VertexArrays

irgendwas vergessen?

Unabhängig davon werde ich die Font-geschichte wohl auf die methode mit einem VBO pro Textur umstellen (evtl auch ein großer VBO mit index-array.. wobei da die verwaltung größerer aufwand wird als 1 VBO pro Textur).

Aya~

PS: @Lossy: Magst du mir deinen Algorithmus verraten den du verwendest um die buchstaben in der textur anzuordnen? Der scheint den platz wesentlich besser auszunutzen als meiner.. bei mir passiert es öffters mal das hier und da ein paar freie stellen bleiben :/

Gibts eigentlich noch Quads in OpenGL 3.0 oder müssten es dann Dreiecke sein? Denn bei Zeichen aus 2 Dreicken würde ein IndexArray aber dahingehend schon der gpu helfen, da 2 Vertices jeweils doppelt benutzt werden müssten. Durch den IndexBuffer würde der Vertexcache der gpu was optimieren können. Allerdings wird dir im Gegenzug auch recht groß. Und selbst bei 2000 Zeichen ist die Datenmenge noch lächerlich für eine Grafikkarte als das man dort wirklich viel unterschied hätte.



Öhm. Das ist ne OpenSource Library. Aber im Endeffekt ist der Algorithmus zum Finden nur der, dass ich Zeile für Zeile von Oben nach Unten und von Links nach Rechts durchgehe und bei genügend Platz in der Breite dann schaue ob auch genügend Platz in der Höhe vorhanden ist. Allerdings wurde das auf Geschwindigkeit optimiert damit ich schneller sagen ob da noch genügend Platz vorhanden ist oder nicht. Ich will ja schließlich bei 40 Texturen keine Sekunden benötigen um das ein mal zu durchsuchen. Der Algorithmus an sich ist alles andere als komplex.

Hm, das tu ich doch. oc2k1 ist ein Pionier, der immer wieder Neuland betritt, und wir anderen sind viel konservativer. Eine Frage, die mich schon seit einiger Zeit beschäftigt, ist, wie man Schrift ausgibt wenn man nur Pufferobjekte und Shader zur Verfügung hat, weil ich in dem Irrtum war, dass glDrawArrays nur mit VBO funktioniert. Das heißt, ich bin von falschen Voraussetzungen ausgegangen. Aber jetzt kann man das Ganze wieder etwas entspannter sehen.

Trotzdem finde ich, dass solche Ansätze interessant sind, einfach unter dem Lernaspekt. So ein Vorreiter wie oc2k1 gibt da Denkanstöße. Oder sagen wir mal so: ich bin eben neugierig. Hat aber nicht wirklich was zu bedeuten.


Ja, ich weiß. Ich weiß auch, dass das nicht so leicht ist. Du bist der Spezialist auf dem Gebiet, schon klar. Geh nicht zu hart ins Gericht mit mir.


Gemäß Spezifikation OpenGl 3.1 gibts im Prinzip nur noch Punkte, Linien und Dreiecke (auch LineLoops und TriangleFans und -strips und so ein Zeug).
Viele Grüße,
Traude

Ja die Liste von möglichen Primitiven ist in OpenGL 3.x riesig.
Points: Points
Lines: Lines, Line_Loop, Line_Strip
Triangles: Triangles, Triangles_Strip, Triangle_Fan

Zum Thema Platz finden für Zeichen, da sollte man mal ein Blick in den Radiosity/lightmap baking Bereich werfen.
Dort hab ich schon mehrmals gesehen, dass durch ein kD Tree die ganze Suche und Zuweisung beschleunigt wurde.

Wiki Erklärung: http://en.wikipedia.org/wiki/Kd-tree
Implementierung: http://www.blackpawn.com/texts/lightmaps/default.html

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Primitive: Also dann würde ich eventuell schon auch mal schauen ob sich das mit einem Indexbuffer nicht doch lohnt. Was auch recht einfach zu handhaben sein sollte, da man beim "zeichnen" ja direkt quads in diese Arrays packt.

Traude: Also ich würd mich da jetzt nicht als Spezialist bezeichnen wollen. Mein Beitrag war auch an niemand persönlich gerichtet sondern bezog sich nur auf die verwendete Technik. Und die ist zwar vom Ansatz her schon ganz okay. Hat aber im Detail ziemlich viele Fallstricke. Und durch die extreme Fokusierung auf neuerer Technologien behindert man sich, meiner Meinung nach, vermutlich mehr als man Vorteile davon bekommen würde.

Wobei ich aber zu meiner Schande gestehen muss, dass ich VertexArrays irgendwie immer ignoriere. Wahrscheinlich weil die schon seit OpenGL 1.1 existieren. Aber wenn die nach wie vor eine gangbare Methode zum Zeichnen sind, dann könnt ich mir gut vorstellen, dass sich das so für Kleinstdaten durchaus lohnt. Also für 1-2 Quads ein BufferObject zu bemühen ist ja nicht gerade billig. Vielleicht merk ichs mir ja dieses Mal die nicht zu ignorieren.

Ich hab mich gerade noch ein bischen in die glspecs 3.1 eingelesen, damit ich den OpenGL3 Wiki Artikel weiter schreiben kann.
Dabei ist ein kleine Falltür unter mir aufgegangen.
Mit Vertex Array sind nicht die Vertex Arrays von früher gemeint.
Man hat in ogl3 nur noch eine art zu zeichnen, unzwar VBO, VA kann falsch verstanden werden, denn in ogl3 sind damit eine hand voll funktionen gemeint, die ein VBO oder speicherstück als vertexarray in den shader bekannt macht, genau gesagt als ein VertexAttrib.
Vertex Array Object ist auch was ganz anderes, dieses sorgt dafür, dass man alle VBO's und vertex state changes in einem Objekt zusammen packen kann und nur noch ein bind benötigt(texturen und co müssen immer noch zusätzlich gebunden werden, da diese eine art displaylist für alle vertexbezogenen daten ist).

edit:
Vertex Arrays:
-glVertexAttribPointer()//verknüpft ein attrib mit vbo oder stück speicher, im arbeitsspeicher
-glVertexAttribIPointer()
-glEnableVertexAttribArray()//aktiviert ein attrib im shader
-glDisableVertexAttribArray()

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich weiß nicht ob es bei OpenGL 3.0 genauso ist, aber bei OpenGL ES funktioniert dashier noch:



Das ist ja im grunde genommen ein VertexArray. (Und dürfte theoretisch genau der ersatz für glBegin sein)
Und nachdem ES und 3.0 sehr viele ähnlichkeiten haben in dem was alles weggefallen ist, kann ich mir gut vorstellen das es das in 3.0 auch noch so gibt.

Aya~

Ich habe mir die Mühe gemacht und den Abschreibungsabschnitt über Vertex Arrays sowohl aus der Spezifikation 3.0 als auch aus der Spec 3.1 herauszusuchen.

Auszug aus der OpenGL 3.0 Spezifikation,Abschnitt E.1. PROFILES AND DEPRECATED FEATURES OF OPENGL 3.0, Seite 405:
(Dieser Abschnitt betrifft abgeschriebene Dinge):


Das heißt doch wohl im Klartext, dass es keine client-seitigen Vertexarrays mehr gibt. Der Satz "all vertex array attribute pointers must refer to buffer objects" drückt sich doch eigentlich recht klar aus


Auszug aus der OpenGL 3.1 Spezifikation,Abschnitt E.1. PROFILES AND DEPRECATED FEATURES OF OPENGL 3.0, Seite 297:


Hier haben sie zusätzlich auch die Client-seitigen Index-Arrays abgeschrieben. Deutlicher kann man es nicht mehr sagen. Also mir sieht es so aus, als ob es überhaupt kein immediate Rendering mehr gibt, nur mehr über VBOs.

@Aya: OpenGL ES gibt es schon länger als OpenGL 3; damals können durchaus andere Ziele verfolgt worden sein. Ich nehme ganz stark an, dass sich nicht OpenGL3 an OpenGL ES anpassen wird, sondern umgekehrt.

NACHTRAG: glVertexPointer ist schon bei der Spec 3.0 rausgeflogen.