In OpenGL direkt auf Bildschirm zeichnen, also 2D?!

Hallo nochmal,
ich habe nur eine kleine Frage, ok zwei.. Kann man in OpenGl auch direkt auf dem Bldschirm, also in 2D statt 3D zeichnen?

Ich habe mir einen kleinen Frame-Zähler gebaut. Der war aber plötzlich weg, nachdem ich am Frustum rumgefummelt hatte. Grund war, dass er weggeschnitten wurde, weil plötzlich außerhalb des Clipping-Würfels...

Also gibt es die Möglichkeit diese 2D-Objekte auch so zu behandeln, sprich sie nicht in den 3D-Würdel packen zu müssen?
Ich habe die Frame-Zahl im Moment quasi auf die vordere Seite des Würfels gezeichnet. Das finde ich aber unsauber. Wenn ich die vordere Ebene mal wieder ändere, ist der Zähler entweder wieder weg, oder im Würfel...

Mal angenommen ich möchte in mein GUI nicht nur 2D-Objekte, wie den Frame-Counter, sondern auch 3D-Objekte einbauen. Z.B. einen rotierenden Würfel, also irgendetwas, das auch tiefengetestet werden muss, aber ich möchte natürlich nicht, dass es mit der eigentlichen Szene irgendwie wechselwirkt, genauer gesagt, den Szenen-Tiefenpuffer beeinflusst, oder davon beeinflusst wird.. Gibt es irgendeine Art separaten Objekt-Tiefenpuffer? ...Oder wie macht man das professionell???

Gruß
OpenGl-Fifi

rapso

OpenGl-Fifi schrieb:

Hallo nochmal,
ich habe nur eine kleine Frage, ok zwei.. Kann man in OpenGl auch direkt auf dem Bldschirm, also in 2D statt 3D zeichnen?

falls du fragst wie man 2d coordinaten uebergibt, da gibt es z.b. glVertex2f..

Ich habe mir einen kleinen Frame-Zähler gebaut. Der war aber plötzlich weg, nachdem ich am Frustum rumgefummelt hatte. Grund war, dass er weggeschnitten wurde, weil plötzlich außerhalb des Clipping-Würfels...

du musst natuerlich fuer alles was du zeichnen moechtest das passende setup machen. pixelzugriff gibt es eigentlich nicht fuer den framebuffer. du kannst texturen fuellen, aber die muestest du dann auf den screen zeichnen, das eigentlich problem wuerde also bestehen.

Also gibt es die Möglichkeit diese 2D-Objekte auch so zu behandeln, sprich sie nicht in den 3D-Würdel packen zu müssen?
Ich habe die Frame-Zahl im Moment quasi auf die vordere Seite des Würfels gezeichnet. Das finde ich aber unsauber. Wenn ich die vordere Ebene mal wieder ändere, ist der Zähler entweder wieder weg, oder im Würfel...

aender sie nicht wenn du sie nicht aendern moechtest fuer die framezahl. du hast das in deiner hand.

[quote]
Mal angenommen ich möchte in mein GUI nicht nur 2D-Objekte, wie den Frame-Counter, sondern auch 3D-Objekte einbauen. Z.B. einen rotierenden Würfel, also irgendetwas, das auch tiefengetestet werden muss, aber ich möchte natürlich nicht, dass es mit der eigentlichen Szene irgendwie wechselwirkt genauer gesagt, den Szenen-Tiefenpuffer beeinflusst, oder davon beeinflusst wird[quote]dann loesche den tiefenbuffer doch einfach nachdem du fertig mit der 3d scene bist.

Gibt es irgendeine Art separaten Objekt-Tiefenpuffer?

frame buffer objects, FBO.

Oder wie macht man das professionell???

kannst du spezifischer sein?

Vielen Dank schon mal für die Antwort.

da gibt es z.b. glVertex2f

Wenn ich das richtig sehe, sind diese 2d-Funktionen oft recht nutzlos, da die Z-Koordinate immer "0" ist und darum z.B. beim Frustum immer außerhalb liegt..
Ich hatte die Position der Zahl mit glRasterPos2f() angegeben, was dann, beim Wechsel von ortho- zu perspektivischer Projektion, der Grund fürs Verschwinden war..
Ideal wäre, wenn man die Z-Koordinate für 2D-Fkt. festlegen könnte.. Geht das?

dann loesche den tiefenbuffer doch einfach nachdem du fertig mit der 3d scene bist.

Ja stimmt natürlich... ...Aber, dann kann ich die GUI-Objekte nicht einfach irgendwann mittendrin zeichnen. Gibt es zufällig eine Möglichkeit, so wie beim Stencil-Buffer, die Tiefenpuffer lokal zu löschen, bzw. lokal mit irgendwelchen Werten zu füllen??? Dann kann ich mir den Bildschirmbereich, den ich gerne hätte mit Tiefenwerten füllen, die mir gerade passen..
Und ich hätte noch ein Problem mit der Clipping-Ebene: Wenn ich ein 3D-Objekt in die linke untere Bildschirmecke, als GUI haben möchte, dann muss ich es ja bestenfalls auf die vordere Clipping-Würfel-Ebene setzen, so wie auch beim 2D-Objekt.. Das Problem ist dann nur die dritte Dimension, die dann wahrscheinlich weggeclippt wird... Kann man das Clipping nur für den Moment nicht einfach ausschalten?! - Und den Tiefenpuffer auch?!

frame buffer objects, FBO.

Ich hätte vielleicht noch dazu sagen sollen, dass ich mit dem klassischen OpenGL arbeite.. Was wäre da eine Alternative..?! ...außer umzusteigen...
Ich mache das erstmal zur Übung. Modernes OpenGL kommt dann irgendwann danach..

kannst du spezifischer sein?

Naja direkt gefragt: Mal angenommen, du programmierst einen Flugsimulator. Und zum GUI (oder Cockpit) gehört ein 3D-Kompass. Wie würdest du den implementieren ...möglichst einfach (und/oder möglichst effizient) ... und eben mit altem OpenGL.. ???

rapso

OpenGl-Fifi schrieb:

da gibt es z.b. glVertex2f

Wenn ich das richtig sehe, sind diese 2d-Funktionen oft recht nutzlos, da die Z-Koordinate immer "0" ist und darum z.B. beim Frustum immer außerhalb liegt..

was meinst du mit 'beim frustum', das ist kein gaengiger term

Ich hatte die Position der Zahl mit glRasterPos2f() angegeben, was dann, beim Wechsel von ortho- zu perspektivischer Projektion, der Grund fürs Verschwinden war..

kennst du den witz "herr doctor, immer wenn ich 'so' mache tut das weh. - dann machen sie es nicht mir 'so'"
ich verstehe dich irgendwie nicht ganz. es geht, dann aenderst du es und dann geht es nicht mehr und du fragst uns was du tun musst.
zeichne doch einfach den text immer auf die weise wie es geht.

Ideal wäre, wenn man die Z-Koordinate für 2D-Fkt. festlegen könnte.. Geht das?

glVertex3f, der dritte parameter ist die z coordinate.

dann loesche den tiefenbuffer doch einfach nachdem du fertig mit der 3d scene bist.

Ja stimmt natürlich... ...Aber, dann kann ich die GUI-Objekte nicht einfach irgendwann mittendrin zeichnen.

das war ja auch deine anforderung. GUI und 3d welt sollten nichts miteinander zu tun haben... jetzt doch?
wenn du jetzt anfaengst mit "ich moechte dass sie zu 63.46% miteinander zu tun haben" muss ich die mit einem null pointer pieken.

Gibt es zufällig eine Möglichkeit, so wie beim Stencil-Buffer, die Tiefenpuffer lokal zu löschen, bzw. lokal mit irgendwelchen Werten zu füllen???

emm... ja, wo sollte das problem sein werte in den zbuffer zu zeichnen?

Und ich hätte noch ein Problem mit der Clipping-Ebene: Wenn ich ein 3D-Objekt in die linke untere Bildschirmecke, als GUI haben möchte, dann muss ich es ja bestenfalls auf die vordere Clipping-Würfel-Ebene setzen

nein musst du nicht, wieso solltest du das muessen? dann wuerde es doch nicht mehr viel sinn machen es in 3d zu haben wenn du es in 2d zeichnen willst. a little bit paradox.

so wie auch beim 2D-Objekt.. Das Problem ist dann nur die dritte Dimension, die dann wahrscheinlich weggeclippt wird... Kann man das Clipping nur für den Moment nicht einfach ausschalten?! - Und den Tiefenpuffer auch?!

tiefenpuffer kannst du ausschalten/konfigurieren. clipping auszuschalten macht keinen sinn.

frame buffer objects, FBO.

Ich hätte vielleicht noch dazu sagen sollen, dass ich mit dem klassischen OpenGL arbeite.. Was wäre da eine Alternative..?! ...außer umzusteigen...
Ich mache das erstmal zur Übung. Modernes OpenGL kommt dann irgendwann danach..

klassisches opengl hat nur einen zbuffer fuer alles.

kannst du spezifischer sein?

Naja direkt gefragt: Mal angenommen, du programmierst einen Flugsimulator. Und zum GUI (oder Cockpit) gehört ein 3D-Kompass. Wie würdest du den implementieren ...möglichst einfach (und/oder möglichst effizient) ... und eben mit altem OpenGL.. ???

ich wuerde
-die umgebung rendern
-zbuffer loeschen
-cockpit mit compass rendern

was meinst du mit 'beim frustum', das ist kein gaengiger term

Das Frustum ist doch dieser "Pyramiden-Stumpf", innerhalb welchem man zeichnen kann.. Und glVertex2f(a,b) entspricht doch glVertex3f(a,b,0), nur dass das wegen z=0 quasi nie im Frustum liegt... Ikke hab jehofft, dett man den z-Wert global für alle "glBla2*()" hätte vorgeben können.. Dann wären die Funktionen wenigstens noch nützlich gewesen, z.B. als Indikator dafür, dass man wirklich nur 2D-Sachen machen möchte..

zeichne doch einfach den text immer auf die weise wie es geht.

Naja, wenns sein muss... Ich hatte gehofft, dass der Text immer so gezeichnet werden kann, dass es geht, also ohne vorher zu schauen, wie..

glVertex3f, der dritte parameter ist die z coordinate.

Also soviel hab ich immerhin schon verstanden... Moment: ...die negative z-Koordinate, wenn ich bitten darf..

wenn du jetzt anfaengst mit "ich moechte dass sie zu 63.46% miteinander zu tun haben" muss ich die mit einem null pointer pieken.

Bereit zum Inkrementieren!
Nein, so schlimm ist es nicht.. Also mit "mittendrin" meine ich eher zwischendurch! Also mal ein 3D-Objekt, dann etwas GUI, dann wieder ein 3D-Objekt..

emm... ja, wo sollte das problem sein werte in den zbuffer zu zeichnen?

Naja, mal angenommen, ich will im unteren linken Viertel des Bildschirms den Z-Puffer löschen, dann muss ich irgendwie eine Ebene zeichnen, die auch den entsprechenden z-Wert hat, aber so skaliert, dass sie ein Viertel des Bildschirms verdeckt.. Im Stencil-Buffer wäre das viel einfacher: Einfach auf die vordere Clipping-Ebene ein Rechteck zeichnen (ohne skalieren zu müssen) und dort wo es gezeichnet wird, dem Stencil-Buffer den gewünschten Wert übergeben..

Oder mal angenommen, die linke Clipping-Ebene wäre quasi sichtbar. Dann kann ich nichtmal ein Rechteck soweit nach hinten schieben, dass es den passenden z-Wert hat und gleichzeitig so skalieren, dass ein Viertel bedeckt ist, da es dann schon geclippt wird, also garnicht mehr bis an den Bildschirmrand reicht.. Das würde nur gehen, wenn es direkt auf der vorderen Clipping-Ebene sitzt, dann hat es aber die falschen z-Werte...

clipping auszuschalten macht keinen sinn.

Wäre aber die Lösung für den obigen Fall...

ich wuerde
-die umgebung rendern
-zbuffer loeschen
-cockpit mit compass rendern

Ok, und wenn das Cockpit bis auf den Kompass nur aus einer Textur besteht?! (Nicht weil wir es so machen müssten, sondern weil wir es so wollen. Ist eben ein sehr kantiges Flugobjekt..) Würdest du die Textur dann nicht vorne auf die Clipping-Ebene packen? Und was ist dann mit dem Kompass?!

rapso

OpenGl-Fifi schrieb:

was meinst du mit 'beim frustum', das ist kein gaengiger term

Das Frustum ist doch dieser "Pyramiden-Stumpf", innerhalb welchem man zeichnen kann..

du meinst die perspektivische projektion? das benoetigst du bei 2d nicht.

Und glVertex2f(a,b) entspricht doch glVertex3f(a,b,0), nur dass das wegen z=0 quasi nie im Frustum liegt... Ikke hab jehofft, dett man den z-Wert global für alle "glBla2*()" hätte vorgeben können.. Dann wären die Funktionen wenigstens noch nützlich gewesen, z.B. als Indikator dafür, dass man wirklich nur 2D-Sachen machen möchte..

wofuer wuerdest du in 2d einen z wert ueberhaupt brauchen? eigentlich garnicht. wenn du ihn also garnicht brauchst, dann ist der z-wert doch egal.

zeichne doch einfach den text immer auf die weise wie es geht.

Naja, wenns sein muss... Ich hatte gehofft, dass der Text immer so gezeichnet werden kann, dass es geht, also ohne vorher zu schauen, wie..

was meinst du mit 'zu schauen wie'? ganz am anfang im ersten posting hattest du doch gesagt es funktioniert. mach es doch einfach weiter so wie es funktioniert.

Ich habe mir einen kleinen Frame-Zähler gebaut. Der war aber plötzlich weg, nachdem ich am Frustum rumgefummelt hatte

doctor: dann fummel nicht am frustum rum, das brauchst du nicht in 2d.

wenn du jetzt anfaengst mit "ich moechte dass sie zu 63.46% miteinander zu tun haben" muss ich die mit einem null pointer pieken.

Bereit zum Inkrementieren!
Nein, so schlimm ist es nicht.. Also mit "mittendrin" meine ich eher zwischendurch! Also mal ein 3D-Objekt, dann etwas GUI, dann wieder ein 3D-Objekt..

wenn du das machen moechtest, darfst du das machen.

clipping auszuschalten macht keinen sinn.

Wäre aber die Lösung für den obigen Fall...

es wuerde fehlerhaftes zeichnen verursachen. clipping ist dafuer da, dass es keine fehler gibt. machst du es aus, ist das rendering kaputt. das kann also nicht die loesung sein....

ich wuerde
-die umgebung rendern
-zbuffer loeschen
-cockpit mit compass rendern

Ok, und wenn das Cockpit bis auf den Kompass nur aus einer Textur besteht?! (Nicht weil wir es so machen müssten, sondern weil wir es so wollen. Ist eben ein sehr kantiges Flugobjekt..) Würdest du die Textur dann nicht vorne auf die Clipping-Ebene packen? Und was ist dann mit dem Kompass?!

ich wuerde es 2d zeichnen. wie oben gesagt, 2d braucht keine tiefe. danach wuerde ich den kompass drueber zeichnen.

ich wuerde es 2d zeichnen. wie oben gesagt, 2d braucht keine tiefe. danach wuerde ich den kompass drueber zeichnen.

Ja nun, welche Projektions-Matrix würdest du denn dazu verwenden?! Man könnte ja ne orthographische Projektion wählen, die um z=0 herum liegt, also z.B. glOrtho(-1,1, -1,1, -1,1). Dann könnte man auch glVertex2f() nutzen.
Mal angenommen, der Platz für unseren Kompass liegt bei (-0.5,-0.5). Dann könnte man eben dort auch einen zeichnen, sammt z-Koordinate. Das Problem wäre nur, dass man den dann auch in ortho. Projektion zeichnen würde..
Also müsste statt dessen eine perspektivische Projetion her. Aber dann könntest du den Kompass nichtmehr auf x=-0.5, y=-0.5, z=0 zeichnen, weil z=0 keinen Sinn macht. Z muss nun im Frustum liegen und dann müsste man wiederum x und y ändern, sodass der Kompass an der richtigen Position auf der Textur liegt..

rapso

OpenGl-Fifi schrieb:

ich wuerde es 2d zeichnen. wie oben gesagt, 2d braucht keine tiefe. danach wuerde ich den kompass drueber zeichnen.

Ja nun, welche Projektions-Matrix würdest du denn dazu verwenden?! Man könnte ja ne orthographische Projektion wählen, die um z=0 herum liegt, also z.B. glOrtho(-1,1, -1,1, -1,1).

aus faulheit wuerde ich eine nehmen die quasi die pixelaufloesung in der ich zeichnen moechte 'simuliert', aber ja, ortho natuerlich, 2d braucht ja keine perspektive und mein 2d cockpit bewegt sich nicht.

Dann könnte man auch glVertex2f() nutzen.

Mal angenommen, der Platz für unseren Kompass liegt bei (-0.5,-0.5). Dann könnte man eben dort auch einen zeichnen, sammt z-Koordinate. Das Problem wäre nur, dass man den dann auch in ortho. Projektion zeichnen würde..

wieso nicht perspektivisch?

Also müsste statt dessen eine perspektivische Projetion her. Aber dann könntest du den Kompass nichtmehr auf x=-0.5, y=-0.5, z=0 zeichnen, weil z=0 keinen Sinn macht. Z muss nun im Frustum liegen und dann müsste man wiederum x und y ändern, sodass der Kompass an der richtigen Position auf der Textur liegt..

jup, das solltest du tun.

Wir haben 2014 und jemand schreibt echt noch was über glVertex?!?

rapso

wir haben eine nuetzliche konversation und es gibt echt immer einen der trollt...

jup, das solltest du tun.

...Naa gut, dann werde ich das wohl so machen... Ist ja keine große Sache, es passend umzurechnen.
Ich hatte irgendwo gehofft, dass man das direkter machen kann, aber wie es aussieht muss man in OpenGL letztendlich alles in 3D machen.. ..wer hätte das gedacht
Also nochmals Danke!

Es kann doch nicht schaden, erstmal mit klassischem OpenGl anzufangen. Das ermöglicht auf jeden Faller erstmal einen schnelleren Einstieg um sich allgemeine Praktiken anzueignen..
Ich habe auch erst C gelernt und schreibe nun in C++. Hat mir nicht großartig geschadet, auch wenn das so mancher C++-Purist anders sehen mag. Wen interessierts..