Hallo!

In den meisten Tutorials, die ich so gelesen habe, steht nur, wie man Texturen durch ein Datenfeld erzeugt, z.B. durch ein selbstersteltes oder durch ein file geladenes.

Wie kann ich nun aber Vertexe, die ich zeichnen will, (offline) in eine Textur speichern?
Muss ich dazu, oder besser: Kann ich dazu irgendwie die Vertexe in ein Datenfeld übergeben (sollte wohl sehr lang dauern) oder geht das irgendwie schneller und einfacher?

MfG,
yadaddy.

Irgendwie kann ich dir gerade nicht folgen. Ich verstehe nicht mal was du unter "Datenfeld" bei der Textur meinst.

Für Vertexe gibt es aber DisplayListen, die durch die Grafikkarte optimiert weredn können und Vertex Buffer Objects. Dazu befindet sich bei uns auch ein Tutorial. Meinst du vielleicht so etwas?

Vielleicht meint er Render to Texture. Oder vielleicht will er anstatt in einen Framebuffer in einen PBuffer rendern, um das gerenderte für irgendwas graphisch unanständiges zu missbrauchen.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Hallo!

Ich will kein Bild aus einer Datei laden, deren bits dann in dem oben genannten Datenfeld an den Texturerzeuger übergeben werden. Ich will lediglich die Punkte, die ich durch Vertexes zeichne, auf eine Textur speichern und nicht in eine Displayliste. Anschließend will ich die Textur logischerweise rendern können.

MfG
yadaddy

Also Render To Texture. Schau dir mal das Tutorial über den PixelBuffer an. Und als ältere und langsamere Alternative kannst du dir auch auf delphigl.de unter "OpenGL" ganz unten das Sample zu RenderToTexture anschauen.

Danke, ich werds mir mal anschauen.

Zusatz: Ist denn rendern in texturen und danach anzeigen lassen schneller als displaylisten?

MfG
yadaddy

Vertexdaten werden in VertexBuffern und nicht in Texturen gespeichert und die sind schneller als DisplayListen.

Das ist nie schneller als das direkte Rendern. Bei RenderToTexture sieht es so aus, dass alles erst einmal in den Backbuffer gezeichnet wird und aus diesem werden dann die Daten in die Textur kopiert die dann wiederrum in einem frisch geleerten Backbuffer gezeichnet werden könnte. In dem Falle wäre es schneller den Backbuffer einfach zu dem Frontbuffer zu machen und das auf dem Bildschirm darzustellen. Also SwapBuffers. Beim PixelBuffer sieht es ähnlich aus bis auf das dort diverse Mechanismen nicht gemacht werden müssen. Aber in Endeffekt tut er immer noch mehr als das normale Rendern.

Aber je nach Grafikkarte etc besteht alleine beim Rendern schon die Möglichkeit etwas an der Geschwindigkeit zu verändern. Es gibt durchaus Mittel und Wege einen Rendervorgang künstlich hinauszuzögern. Und diese gilt es zu vermeiden. Wobei eine DisplayListe in vielen Fällen schon vom Treiber optimiert wird und da kann man meist nicht mehr viel rausholen. Außer die Grafikkarte ist ein bisschen älter. Die sind da ein wenig empfindlicher als die neueren Karten.

Hallo!

die Extension für Render to Texture ist aber nur für Windows. Ich brauche dieses unabhängig von System.
Gibt es keine andere Variante?

MfG,
yadaddy.

Die Extension glCopyTexImage2D ist eine allgemeine OpenGL-Extension und nicht auf Windows beschränkt.
Im dem Tutorial findest du eine Beispiel wie man es verwendet.

Also das RenderToTexture sollte auch ohne Probleme unter Linux funktionieren, da dort ja lediglich die Daten kopiert werden.

Der (ARB oder EXT) PBuffer funktioniert nicht unter Linux. Da hast du recht. Aber dafür gibt es ein Linuxequivalent. Nämlich GLX_SGIX_pbuffer. Der hat dann ein paar Linuxspezifische Sachen eingebaut. Wie dessen Unterstützung aussieht kann ich dir aber leider nicht sagen. Außerdem müsstest du das selber Implementieren, da diese Extension im Header nicht enthalten sind.

Ich würde dir aber empfehlen dort eine kleines Klassenkonzept zu erarbeiten bei dem du je nach Unterstützung entweder ARB_pbuffer, EXT_pbuffer oder das klassische RenderToTexture benutzt. Alle 2 oder 3 Klassen wären von einer Basis abgelitten. Mit abstrakten Methoden. Beim Erstellen einer Instanz überprüfst du was vorhanden ist und erstellst die entsprechende Instanze. Dort rufst du dann so was wie init auf. Bei den pbuffern würde dann entsprechend der Buffer aktiviert werden und bei RenderToTexture dann der ViewPort angepasst werden. Dann könntest du locker flockig rendern. Beim Deinit würdest du dann für RenderToTexture die Daten in eine Textur kopieren und bei pbuffer würdest du den anderen Context wieder aktivieren.

Dein Program würde dann nur noch mit einer RenderTexture (Basisklasse) sprechen und ob das jetzt mit einem pbuffer oder mit RenderToTexture gehen würde wäre dann primär erst einmal egal.

Ich hoffe das war jetzt nicht zu viel und ging nicht zu schnell.

PS: Der Vollständigkeit sollte noch erwähnt werden, dass es auch ein PixelBufferObject gibt. Da dabei aber die Unterstützung ziemlich bescheiden aussieht ist das momentan nur Zukunftsmusik und dürfte wohl den Implementationsaufwand noch nicht Wert sein. Wohl gemerkt noch.

Für RTT gibt's doch auch noch die plattformübergreifenden Extension EXT_Framebuffer_object.

Hallo.

Danke für die Antworten.

Ich glaube, was ich suche, ist glCopyTexImage2D.
Muss noch testen, ob es das gewünschte tut.

Die OS-Spezifikationen bringen mir nichts, weil es auch v.a. auf einem Mac schnell laufen soll.

MfG,
yadaddy.

Das Problem ist das glCopyTexImage nicht so wirklich schnell ist. Aus genau dem Grund wurde ja pbuffer, PixelbufferObject und der ganze andere Kram überhaupt gebaut. Aber ich denke mal so lange der Buffer, den du benutzt, nicht so wahnsinnig groß wird, sollte es noch durchaus gut vertretbar sein.