OpenGl: "2^n"-Texturen füllen, oder halbleer nutzen + Fragen zu den Vorteilen des modernen/erweiterten OpenGL
-
Nabend allerseits,
ich bin es nochmal. Diesmal mit ein paar Fragen zum Texturierung in OpenGl und außerdem zum modernen OGL...Also erstmal zur Texturierung mit klassischem OpenGL:
Erstmal eine dumme Frage:- Sehe ich es richtig, dass man die Texturierung mit glEnable() / glDisable() aktivieren muss, wenn man sie braucht und danach wieder deaktivieren muss. Sprich, gibt es da keine Alternative, wie eine Maske oder ähnliches?! Vom Gefühl her hatte ich glEnable() / glDisable() immer als relativ kostenintensiv betrachtet - wie gesagt, eine dumme Frage..
So nun die eigentlichen Fragen:
Es wird geschrieben, dass man für die Texturen bestenfalls 2^n * 2^m Texel als Maße nehmen soll. Das scheint zwar kein Muss zu sein, aber es kann ja nicht schaden - dachte ich...
Ich wollte den Framebuffer in einer Textur speichern und diese dann auf ein 3D-Objekt legen.
Das Problem ist nur, dass der Buffer i.A. nicht die passenden Maße besitzt, also kleiner ist, als meine Textur und darum Teile der Textur schwarz bleiben.
Die Textur-Parameter s,t habe ich schon umgerechnet, sodass z.B. s nicht von 0 bis 0.815, sondern eben wieder von [0...1] geht.Was mache ich aber nun, wenn ich die Textur wiederholen möchte, also
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT ) ?!Kann ich das Bild schon beim Schreiben in die Textur strecken? Das wäre ideal.
Oder kann ich den Framebuffer, aus dem ich das Bild für die Textur nehme für den Moment den Maßen der Textur anpassen? Das wäre sogar noch besser. Denn dann wäre die Texturauflösung nicht abhängig von der Fenstergröße der Anwendung.Wie würde man vorgehen, wenn man eine Textur generieren wollte, aus einem Bild, dass man (mit OpenGl) zeichnen müsste??
Mir ein Array anzulegen, als Leinwand-Ersatz, und dann irgendwelche Zeichenfunktionen (z.B. für Linien, Kreise, etc.) zu implementieren, scheint mir ein winzig-kleines Bisschen übertrieben, besonders da ich doch OpenGl direkt nebenan liegen habe...Soo, das zur Texturierung mit klassischem OpenGL..
Ich habe tatsächlich schon mal etwas ins moderne OpenGL rein geschnuppert ... naja insofern, als ich mir GLEW/GLee heruntergeladen und ausprobiert habe...
Die erste Frage dazu natürlich:
- Gibt's nun eine Lösung für mein obiges Problem?- Kann man sich eigene Blending-Funktionen schreiben, oder muss man immernoch auf "GL_ONE_MINUS_SRC_ALPHA" zurückgreifen?!
- Kann man sich z.B. eigene Textur-Filter-Funktionen basteln?
- Wenn das alles nicht geht, kann man sich dann überhaupt eigene OpenGL-Funktionen zusammenklöppeln?!
- Hat irgendwer ein Beispiel für mich, dass mich 'mit einem Blick' von der modernen OpenGL-Funktionalität überzeugt?! - Vielleicht etwas, das mit dem klassischen OpenGl garnicht geht..
Bzw. kann mir jemand sagen, welche Vorteile mir das moderne bringt?! - Ich weiß, dass es keine feste Pipeline mehr gibt, was mir das aber bringt, außer mehr Arbeit um überhaupt ein Bild zustande zu bringen, habe ich noch nicht raus..- Könnte es passieren, dass der Hardware-Hersteller sich in ferner Zukunft dazu entscheidet, das klassische OpenGl komplett zu verbannen, sodass die alten Programme garnicht mehr funktionieren, oder kann ich beruhigt mit klassischen OpenGl arbeiten, sofern es mir genügt?
- Die "glext.h". - Sehe ich es richtig, dass man die in Zeiten von GLEW garnicht mehr braucht?
Bzw. braucht man die nur, wenn man so verrückt ist und versucht, die Erweiterungen manuell zu laden??
Ich habe versucht mir Erweiterungen mit "wglGetProcAddress()" zu laden, bin aber gescheitert. Das ist, zum Glück, auch nicht mehr nötig. Aber hätte vielleicht doch jemand noch ein Beispiel für mich, wie sowas auszusehen hat? ... In die WinAPI habe ich tatsächlich kurz mal reingeschnuppert, falls es hilft...- Es gibt eine Kleinigkeit, die mich an GLEW und Konsorten stört: Bei den klassischen OpenGL-Funktionen zeigt mir CodeBlocks immer schön die Funktions-Parameter an. Das hat mir schon oft das Nachschlagen im Netz erspart. Da bei GLEW aber alles umdefiniert wird, gibt's da höchstens die Funktionsnamen. Es existiert nicht zufällig irgendeine Möglichkeit (bei CB) die Funktions-Parameter nachzurüsten?!?
Soo, das wär's auch schon für den Moment..
Gruß
OpenGl-Fifi
-
OpenGl-Fifi schrieb:
Oder kann ich den Framebuffer, aus dem ich das Bild für die Textur nehme für den Moment den Maßen der Textur anpassen? Das wäre sogar noch besser. Denn dann wäre die Texturauflösung nicht abhängig von der Fenstergröße der Anwendung.
Naja. Jain. Du kannst direkt in die Textur rendern. Und natürlich kannst du dabei dann die ganze Textur beschreiben, unabhängig davon wie gross dein Back-Buffer ist. Der Back-Buffer ist schliesslich nur eines von vielen möglichen Render-Targets.
Wie genau man das mit OpenGL macht kann ich dir nicht sagen, ich hab' bisher nur mit D3D gearbeitet. Vom Prinzip her besteht da aber kein Unterschied.OpenGl-Fifi schrieb:
- Kann man sich eigene Blending-Funktionen schreiben, oder muss man immernoch auf "GL_ONE_MINUS_SRC_ALPHA" zurückgreifen?!
IIRC kannst du im Fragment-Shader so ziemlich machen was du willst. Wobei es möglich wäre dass "fertige" Blending-Modes schneller sind wenn viel Fälche 100% transparent ist. Bin mir aber nicht sicher ob Grafikkarten das wirklich optimieren.
OpenGl-Fifi schrieb:
- Kann man sich z.B. eigene Textur-Filter-Funktionen basteln?
Ja, klar. Wieder Stichwort Fragment-Shader.
Du kannst ja die Textur mit "nearest pixel" sampeln. Und dafür mehrfach. Und dann die verschiedenen Samples selbst zusammenblenden.OpenGl-Fifi schrieb:
- Hat irgendwer ein Beispiel für mich, dass mich 'mit einem Blick' von der modernen OpenGL-Funktionalität überzeugt?! - Vielleicht etwas, das mit dem klassischen OpenGl garnicht geht..
OpenGl-Fifi schrieb:
Bzw. kann mir jemand sagen, welche Vorteile mir das moderne bringt?! - Ich weiß, dass es keine feste Pipeline mehr gibt, was mir das aber bringt, außer mehr Arbeit um überhaupt ein Bild zustande zu bringen, habe ich noch nicht raus..
Naja, du kannst das Bild - mehr oder weniger - so berechnen wie du willst. Shadow-Maps, Screen-Space-Ambient-Occlusion, Ray-Marching, ... - mit einer fixen Pipeline kannst du das alles vergessen.
Genau so realistische Materialien und Beleuchtungsmodelle. High Dynamic Range mit Tone-Mapping.OpenGl-Fifi schrieb:
- Könnte es passieren, dass der Hardware-Hersteller sich in ferner Zukunft dazu entscheidet, das klassische OpenGl komplett zu verbannen, sodass die alten Programme garnicht mehr funktionieren, oder kann ich beruhigt mit klassischen OpenGl arbeiten, sofern es mir genügt?
Also hardwareseitig ist das schon lange passiert. Der ganze Fixed-Function Krempel läuft nur mehr über Emulation. D.h. aus den Einstellungen die du in der Fixed-Function Pipeline machst wird ein Shaderprogramm (bzw. mehrere, Vertex-Shader, Fragment-Shader etc.) gemacht, und das wird dann verwendet.
OpenGl-Fifi schrieb:
- Die "glext.h". - Sehe ich es richtig, dass man die in Zeiten von GLEW garnicht mehr braucht?
Bzw. braucht man die nur, wenn man so verrückt ist und versucht, die Erweiterungen manuell zu laden??
Ich habe versucht mir Erweiterungen mit "wglGetProcAddress()" zu laden, bin aber gescheitert. Das ist, zum Glück, auch nicht mehr nötig. Aber hätte vielleicht doch jemand noch ein Beispiel für mich, wie sowas auszusehen hat? ... In die WinAPI habe ich tatsächlich kurz mal reingeschnuppert, falls es hilft...- Es gibt eine Kleinigkeit, die mich an GLEW und Konsorten stört: Bei den klassischen OpenGL-Funktionen zeigt mir CodeBlocks immer schön die Funktions-Parameter an. Das hat mir schon oft das Nachschlagen im Netz erspart. Da bei GLEW aber alles umdefiniert wird, gibt's da höchstens die Funktionsnamen. Es existiert nicht zufällig irgendeine Möglichkeit (bei CB) die Funktions-Parameter nachzurüsten?!?
Soweit ich weiss gibt es für so ziemlich jede Plattform fertige Libs die einem das Laden der ganzen üblichen Extensions abnehmen - so dass man auch nur einfach die Funktionen aufrufen muss. Da kommt dann auch die Liste der IDE mit den Parameternamen.
Einer unserer OpenGL-Freunde kann dir da sicher nen Tip geben.
-
Hallo Hustbär, ich bin dir sehr dankbär ...höhö... *hust*
Naja. Jain. Du kannst direkt in die Textur rendern. Und natürlich kannst du dabei dann die ganze Textur beschreiben, unabhängig davon wie gross dein Back-Buffer ist. Der Back-Buffer ist schliesslich nur eines von vielen möglichen Render-Targets.
Aha, dann muss ich mich korregieren. DAS ist die beste Lösung. Hoffentlich geht das auch schon mit klassischem OpenGL. So weit war ich noch nicht... Weiß zufällig jemand ob und wie das geht?! ..Oder eben, wie man die Framebuffer-Größe unabhängig von der Fenstergröße einstellen kann..!?
Also shadertoy.com ist ja wirklich 'hardcore', nicht nur, weil mit der browser einfriert, solange die Seite läd und das kann je nach Beispiel schon etwas dauern.. Aber ich hoffe mal, dass es sich eher um komplette Programme handelt und nicht nur um Teile eines OpenGl-Programms, da der Quelltext teilweise schon extrem lang ist. Sieht andererseits auch extrem gut aus...
Soweit ich weiss gibt es für so ziemlich jede Plattform fertige Libs die einem das Laden der ganzen üblichen Extensions abnehmen - so dass man auch nur einfach die Funktionen aufrufen muss. Da kommt dann auch die Liste der IDE mit den Parameternamen.
Einer unserer OpenGL-Freunde kann dir da sicher nen Tip geben.GLEW wäre solcheine Lib, bzw. eigentlich -die- Lib. Die Funktionsnamen werden mir auch angezeigt, aber eben nicht was rein kommt... Weiß da ein OpenGL-Freund rat?!
-
Bitte bitte.
OpenGl-Fifi schrieb:
Hoffentlich geht das auch schon mit klassischem OpenGL. So weit war ich noch nicht... Weiß zufällig jemand ob und wie das geht?! ..Oder eben, wie man die Framebuffer-Größe unabhängig von der Fenstergröße einstellen kann..!?
Bin mir nicht ganz sicher was du mit "klassischem OpenGL" meinst. Mit OpenGL 1.0 ohne jegliche Extensions geht es nicht. Aber es geht AFAIK mit der Fixed-Function-Pipeline, also ohne explizit Shader zu verwenden.
Google einfach mal nach OpenGL render to texture.
Da findet man dann z.B.
http://nehe.gamedev.net/tutorial/radial_blur__rendering_to_a_texture/18004/
http://ogltotd.blogspot.co.at/2006/12/render-to-texture.html
http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-14-render-to-texture/Also shadertoy.com ist ja wirklich 'hardcore', nicht nur, weil mit der browser einfriert, solange die Seite läd und das kann je nach Beispiel schon etwas dauern.. Aber ich hoffe mal, dass es sich eher um komplette Programme handelt und nicht nur um Teile eines OpenGl-Programms, da der Quelltext teilweise schon extrem lang ist. Sieht andererseits auch extrem gut aus...
Wie meinste "komplette Programme"? Das sind alles Fragment-Shader, sonst nix. Die Fragment-Shader bekommen als Input halt noch die Zeit und die Mauskoordinaten, damit machen die dann die Animationen. Gezeichnet wird aber immer nur ein Quad wo eben der Fragment-Shader drauf liegt.
GLEW wäre solcheine Lib, bzw. eigentlich -die- Lib. Die Funktionsnamen werden mir auch angezeigt, aber eben nicht was rein kommt... Weiß da ein OpenGL-Freund rat?!
Ah. Ok. Sorry
Bin wie gesagt kein OpenGL-er sondern D3Dler. Und auch das nur nebenbei.
Sieht aber nicht so aus als ob man bei GLEW im Moment was machen könnte...
http://sourceforge.net/p/glew/feature-requests/30/
Das Ticket ist von 2009 und immer noch "open". Tjoah. Doof.Aber lies mal das:
http://stackoverflow.com/questions/15561048/opengl-alternatives-to-glew-that-has-arguments-defined-or-a-solution-to-it
Das in der ersten Antwort erwähnte Tool OpenGL Loader Generator klingt finde ich ganz gut.
-
opengl 1.0 hatte damals nichtmal texture object, jeder texture switch war also ein texture upload. wenn ich mich recht erinnere haben wir texture objects erst in 1.2 bekommen und Framebuffer objects sind davon nicht weit entfernt. ich wuerde behaupten es gibt keinen grund FBOs nicht zu nutzen, das funzt noch mit allem anderen zusammen und ist nicht sonderlich komplex aufzusetzen.
auf jedenfalls sollte man von pbuffern (das man beim googlen vielleicht in dem zusammenhang findet) die finger lassen, das war zwar zuerst da und schneller, aber es hat mit der zeit kompatibilitaetsprobleme mit anderen features gemacht und treiber haben das auf unterschiedliche weisen interpretiert wie die parameter und reihenfolgen der initialisierungen zu machen sind.
-
Hallo,
Bin wie gesagt kein OpenGL-er sondern D3Dler.
Das merkt man, finde ich, aber nicht wirklich.. Und dann zauberst du einem auchnoch die passenden Links her.. Ist ja nicht so, als hätte ich nicht schon gesucht. Der OpenGL Loader Generator scheint genau das zu sein, was ich brauche. Den hatte ich tatsächlich schon mal gefunden, da wusste ich aber noch nicht, dass ich ihn mal brauchen könnte.
Ich habs gerne mit so wenig overhead wie möglich.. Naja eigentlich wollte ich ja nur mit C++ arbeiten, dafür brauche ich aber auch Lua wie es scheint .. soviel zum overhead.
In dem NeHe-Tutorial wird davon ausgegengen, dass das Fenster nicht kleiner als 128*128 px ist, die dann zur Textur-Generierung genutzt werden.
Im nächsten Link werden glGenFramebuffersEXT() genutzt, ich weiß aber nicht mit welcher Version..
Der dritte verwendet dann glGenFramebuffers()..
Ehrlich gesagt blicke ich durch die Nomenklatur noch nicht so ganz durch..
Also mal angenommen ich will ne Software programmieren, die auf möglichst vielen PCs läuft und dazu villeicht hier und da noch ein bisschen mehr an Funktionalität als die von OpenGL v1.1 haben soll, z.B. nen Framebuffer-artiges Objekt, welche Version bräuchte ich dazu wohl..?!Gibt es zufällig irgendwo eine Übersicht, aus der hervor geht, wann welche Funktionen zu OpenGl dazugekommen sind (/entfernt wurden) ???
Mit 'wann' meine ich eigentlich die Version, aber das Jahr wäre auch nicht schlecht.. Kann man davon ausgehen, dass z.B. die olle Onboard-GPU von 2007 alle OpenGL-Geschichten bis 2007 beherrscht? ..Oder wieviel Zeit sollte man ca. davon anziehen?!Danke rapso! Gut, dass du es sagst. Pbuffer waren wirklich das, was ich als erstes bei Google als Alternative gefunden hatte. Die scheinen ab v1.6 zu existieren.. Na davon kann ich mich dann ja gleich wieder verabschieden..
..Dabei scheint es die schon seit mindestens 1999 gegeben zu haben. Das hätte mir dann in Sachen Abwärtskompatibilität tatsächlich gereicht...
wenn ich mich recht erinnere haben wir texture objects erst in 1.2 bekommen und Framebuffer objects sind davon nicht weit entfernt.
Mit texture-objects meinst du die, die man mit GenTextures() erzeugen kann?? Die gibts schon in v1.1, sofern das die sind, die ich hier verwende..
Kann es sein, dass es FBOs (in welcher Form auch immer) erst ab v2.1 gibt (Zahlendreher ) ??Gruß
OpenGL-Fifi
-
OpenGl-Fifi schrieb:
Hallo,
Bin wie gesagt kein OpenGL-er sondern D3Dler.
Das merkt man, finde ich, aber nicht wirklich..
Naja, ich hab, im Gegensatz zu z.B. rapso, keinen Plan wie die einzelnen Extensions in OpenGL heissen, wann sie dazugekommen sind, was man verwenden sollte und was nicht usw.
Nur ne ungefähre Idee was OpenGL so ca. inetwa kann. Und dass quasi alles was in D3D geht mittlerweile auch mit OpenGL Extensions geht und umgekehrt.OpenGl-Fifi schrieb:
Und dann zauberst du einem auchnoch die passenden Links her.. Ist ja nicht so, als hätte ich nicht schon gesucht. Der OpenGL Loader Generator scheint genau das zu sein, was ich brauche. Den hatte ich tatsächlich schon mal gefunden, da wusste ich aber noch nicht, dass ich ihn mal brauchen könnte.
Ich hab einfach nach
glew alternativegesuchtOpenGl-Fifi schrieb:
Ich habs gerne mit so wenig overhead wie möglich.. Naja eigentlich wollte ich ja nur mit C++ arbeiten, dafür brauche ich aber auch Lua wie es scheint .. soviel zum overhead.
Lua wird bloss zum Erzeugen der Headers gebraucht. Runtime-Overhead gibt es dadurch keinen. Und wenn du die Headers erstmal erzeugt hast auch keinen beim Compilieren.
OpenGl-Fifi schrieb:
Ehrlich gesagt blicke ich durch die Nomenklatur noch nicht so ganz durch..
Also mal angenommen ich will ne Software programmieren, die auf möglichst vielen PCs läuft und dazu villeicht hier und da noch ein bisschen mehr an Funktionalität als die von OpenGL v1.1 haben soll, z.B. nen Framebuffer-artiges Objekt, welche Version bräuchte ich dazu wohl..?!
(...)Siehste, genau da kann ich dir jetzt nicht mehr weiterhelfen, weil eben D3D-Mann und kein OpenGL-Mann
-
Ich hab einfach nach glew alternative gesucht
Na gut, das scheint ja nicht so aufwendig gewesen zu sein. Dann vielleicht schon eher der Link zum Feature-Request?!
Ja, ich weiß, wie schenll man zum Ziel kommt, hängt davon ab wie nahrhaft das ist, was man Google zu fessen gibt..Lua wird bloss zum Erzeugen der Headers gebraucht. Runtime-Overhead gibt es dadurch keinen. Und wenn du die Headers erstmal erzeugt hast auch keinen beim Compilieren.
Das wär ja auch noch schöner... Keinen beim Compilieren is schon schön. Da gibts bei GLEW schon etwas Overhead, wenn auch nicht viel, sofern ich das richtig sehe..
Ich meine Overhead im Sinne von "mehr machen müssen als nötig". ..Man könnte sich ja auch einfach die passenden Dateien von der Seite runterladen, schein ja nicht allzuviele Möglichkeiten zu geben, den Loader zu konfigurieren, ...wenn es sie denn gäbe.Siehste, genau da kann ich dir jetzt nicht mehr weiterhelfen
Siehste, siehste - Kaktus inner Wüste..
Macht nix. Ich habs tatsächlich geschafft, mir exemplarisch ne Funktion manuell zu laden und bin der allgemeinen Erleuchtung dabei ein Stückchen näher gekommen.. Den Rest finde ich auch noch raus..
