Ich weiss, es gibt noch experimentelle PBuffer-methoden für Windows und Linux.

Ich gehe z.Z. so vor: screen drawen, copyTexImage, dann kann ichs jedes mal wieder laden.
Problem: bei großen Texturen dauert es zu lange (bis zu einigen Sekunden!)

Wie kann ich nun dieses Problem lösen, wenn ich es auf jedem Betriebssystem, das auch opengl unterstützt laufen lassen kann?

Gruß,
yadaddy

Framebuffer Objekte sind die Lösung und schneller als PBuffer weil der RC Wechsel entfällt.

http://oss.sgi.com/projects/ogl-sample/ ... object.txt

Und das läuft wirklich auf jedem System? Windows, Linux, Mac brauch ich nur.

Wenn ja, dann danke für die Information.

Zumindest unter Windows und Linux. Mac weiß ich nicht.

Na ja. Das Ding ist nur, dass es derzeit nur von der oberen Spitze der Grafikkarten unterstützt wird. Je nachdem was du vor hast könnte es ein wenig lächerlich wirken wenn du eine 600€ teure Grafikkarten vorraussetzt und nicht entsprechende Grafik mit bringst.

Mich wundert es aber ein bisschen, dass CopyTexImage bei dir so extrem langsam ist. Was machst du denn da bitte genau? Klar ist es nicht das Schnellste aber das ist doch ein bisschen extrem.

Achso, also nicht alle neuen Grafikkarten unterstützen FrameBuffer-objects?


Ich kopiere sehr viele Primitiv-objekte, v.a. Problem bei großen Kreisen, auf mehrere Texturen (weil ich mehrere Schichten habe, die verschieden sind).
Mit internalformat == RGB gehts noch einigermaßen, bei RGB16 setzt er schon aus (bis zu 1 Sekunde je Schicht).

Das ist eine sehr gute Frage. Ich habe eine Radeon 9600 Pro und ATI hatte seit langem in den Treibern zwar die Methode eingebaut haben aber die Extension nicht freigeschaltet. Muss ehrlich passen ob sie es mittlerweile getan haben. Habe lange nicht mehr geschaut. Laut Delphi3D sollte es aber wohl sein. Sofern man denn schön seine Grafikkartentreiber updatet. Aber wie du sehen kannst ist diese Liste nicht sehr lang im Vergleich zu anderen.

Da würde ich aber sagen kommt es ganz darauf an was du damit bezwecken willst. Was sowieso mal ganz interessant zu erfahren wäre. Evtl gibbet ja auch ne andere Möglichkeit.

Sonst würde ich sagen probier als Texturformat mal bitte RGBA8 aus. Auch wenn du keinen Alpha hast. Das ist das schnellste Texturformat. Ich weiß nicht ob das möglich ist aber mitunter genügt es auch alle paar Frames solche Texturen zu aktualisieren. Evtl kannst du bei mehreren Texturen diese auch einzeln updaten. Also zu erst Tex1, im nächsten Frame Tex2. Etc. Aber befürchte fast, dass du das nicht machen kannst. Wobei es ja durchaus auch Möglichkeiten geben kann.

Hallo.

Also ich habe eine Radeon 9700 mobility.

Komischerweise, wenn ich folgendes aufrufe:

gl.isFunctionAvailable("glCheckFramebufferStatusEXT")
gl.isExtensionAvailable("GL_EXT_framebuffer_object")

so gibt er mir jedes mal false aus.


RGBA8 ist bei mir genauso schnell wie RGB. Ich habe einfach das Texturformat auf RGBA8 geschaltet und aber mit RGB screen gespeichert. Das erzielte bei mir soweit die schnellsten Ergebnisse.

Gruß,
yadaddy.

Beschreib mal dein Ziel. Eventuell gibts Lösungen die das Problem umgehen.

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

Ich programmiere mit JOGL (Java OPENGL).

Ich habe ein inkrementelles Schichtsystem, d.h. ich zeichne schichtweise (layers), jeder nächste layer enthält den vorigen layer.
Ich zeichne 2D ohne Licht, Schatten, Alpha. Ich brauche blending (alpha wird gesondert berechnet), pro layer male ich sehr viele grafische primitive, z.B.
100.000 lines oder 50.000 kreise mit großen radien, die sich jeweils überlappen.

Darf man Fragen was du da zeichnest?

Zum wZeichnen ürden sich wohl VBOs oder DLs anbieten. Damit kannst/solltest du deine Ausgabe beschleunigen. Aber sonst muss ich ehrlich sein. Das sieht nicht gut aus. Alleine eine solche Menge an Linien/Kreisen dürfe zu einem Problemen führen. Daran dürfte nicht mal Framebuffer Objects was ändern.

Ich habe vor ein paar wochen selber mal was mit render to texture gemacht und das war alles nicht so das Ding. Der hatte ne vernünftige Geschwindigkeit.

vbos bringen hier nix, und dls waren langsamer.

das problem taucht v.a. im fullscreen auf, also resolutions bis zu 1280*1024. die 4 texturen erzeugen geht ja noch, aber screen kopieren auf rgba16 braucht schon seine zeit . mit rgb gehts schon schneller, nur der screen resize ist halt problematisch. aber läuft dennoch tausend mal schneller als mit herkömmlichen java-klassen (awt und swing).

Wird das ein Zeichen bzw. Cadprogramm?
Eventuell kannst du die Menge an Objecten eingrenzen. Also per Raumunterteilungsalgorithmen. BSP-Bäume z.B.

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

ne, das wird ein programm, dass daten auf verschiedene art und weisen visualisiert.

Habe selber schon mal beruflich Daten visualisiert und selbst in reinem Pascal bekommt man mitunter Probleme. Solche Optimierungen wie Octrees etc bringen zu 95% der Fälle nichts, da man meist eh immer alle Daten sehen muss. Das Einzige was man machen kann ist zu versuchen die Darstellung zu beschleunigen. Und da helfen solche Sachen wie VBOs und DLs schon recht gut weiter. Wenn die bei dir nichts gebracht haben würde ich gerne mal wissen was du für eine Karte da hast. Wenn diese denn tatsächlich in der Hardware beschleunigt werden, dann sind moderne Karten durchaus in der Lage mehrere Millionen Dreiecke in der Sekunde darzustellen. Also ich denke dabei so an eine Radeon 9500 aufwärts. Moderne Spiele haben bis zu 1 Mio Dreiecke pro Bild. Und diese Arbeiten ausschließlich mit VBOs.

Aber selbst auf einer 9500er hängt die Geschwindigkeit sehr stark davon ab was du vor hast, wie flexibel es ist und eigentlich an jedem kleinen, vielleicht noch so unwichtigem, Detail. Ich denke mal du weißt worauf ich hinaus möchte. Du hast es zwar immer ein bisschen angerissen aber ich für meinen Teil kann nicht behaupten, dass ich genau weiß was du vor hast. Kann auch sein, dass ich mir das auch nur nicht vorstellen kann.

Das was du vor hast klingt ziemlich speziell und nach etwas was sehr an die Grenzen von deiner Sprache und deiner Hardware geht. Je nachdem was gewünscht wird musst du entweder sagen, dass ist Hardwareminimum oder ihr müsst an der Visualisierung Abstriche machen. Respektive sogar komplett andere Wege gehen.

Abstriche an der Visualisierung könnten zum Beispiel für einen Scatter so sein, dass man das Ganze zwar drehen kann aber man wärend dieses Vorgangs entweder nur eine Bounding Box der Daten oder eine sehr abgespeckte Version der Daten sieht. Dann könnte man unter anderem dafür Sorgen, dass die gerenderten Daten in ein Bild gemalt werden und so lange die sich nicht geändert werden nur das Bild gemalt wird. Das wäre eine Möglichkeit des Cachens die aber nicht funktioniert, wenn du zum Beispiel Animationen hast. Aber um dir da schon eher weiterhelfen zu können fehlt mir persönlich noch der entscheidende Hinweis wie ich mir das alles vorzustellen habe. Nen Bild oder so was wäre immer hilfreich.

Allerdings habe ich so die Befürchtung, dass es etwas berufliches sein wird und du deswegen ein bisschen zurückhaltend bist.

PS: Ich denke mal eine andere Sprache als Java wirst du auch nicht benutzen können. Ich befürchte einfach, dass Java da ab einer gewissen Datenmenge auch irgendwo die Puste ausgehen wird.