OGL und der tägliche Wahnsinn!

[del_4901]

Kann mir mal bitte einer erklären wie es zu diesem Phänomen kommt?
das tritt immer beim ersten QUAD auf welches gezeichnet wird. Sprich wenn ich TopView auskommentier, hab ich das Problem im SideView. Das Problem tritt sowohl bei Perspektivischer sowie Orthogonaler Projektion auf.


das ganze läuft ungefähr so ab:

class Viewport4

bool bufferedDraw()
{
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glEnable(GL_TEXTURE_2D);
front.setOrthoBuffer();
drawgrid();
draw();
...
}


class Viewport4

void drawgrid()
{
glEnable(GL_LIGHT1);
glEnable(GL_LIGHT2);
glBindTexture(GL_TEXTURE_2D, grid[0].tex);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA , GL_DST_COLOR );
// glDisable(GL_LOGIC_OP);
glDisable(GL_DEPTH_TEST);
glEnable(GL_ALPHA_TEST);
glAlphaFunc(GL_GREATER, 0.1f);
// glAlphaFunc(GL_GEQUAL, 0.5);

glBegin(GL_QUADS);

/////////////TopVIEW///////////////
glVertex3f (-100.0f, 0.0f, 100.0f);
glTexCoord2f( 0.0f, 150.0f);

glVertex3f ( 100.0f, 0.0f, 100.0f);
glTexCoord2f( 150.0f, 150.0f);

glVertex3f (100.0f, 0.0f,-100.0f);
glTexCoord2f(150.0f, 0.0f);

glVertex3f (-100.0f, 0.0f,-100.0f);
glTexCoord2f( 0.0f, 0.0f);//*/


////////////SideVIEW///////////////
glVertex3f ( 0.0f,-100.0f, 100.0f);
glTexCoord2f( 0.0f, 150.0f);

glVertex3f ( 0.0f, 100.0f, 100.0f);
glTexCoord2f( 150.0f, 150.0f);

glVertex3f ( 0.0f, 100.0f,-100.0f);
glTexCoord2f( 150.0f, 0.0f);

glVertex3f ( 0.0f,-100.0f,-100.0f);
glTexCoord2f( 0.0f, 0.0f);//*/


////////////FrontVIEW///////////////
glVertex3f (-100.0f, 100.0f, 0.0f);
glTexCoord2f( 0.0f, 150.0f );

glVertex3f ( 100.0f, 100.0f, 0.0f);
glTexCoord2f( 150.0f, 150.0f );

glVertex3f ( 100.0f,-100.0f, 0.0f);
glTexCoord2f( 150.0f, 0.0f );

glVertex3f (-100.0f,-100.0f, 0.0f);
glTexCoord2f( 0.0f, 0.0f );//*/

glEnd();

glBindTexture(GL_TEXTURE_2D, 0);
glDisable(GL_ALPHA_TEST);
glDisable(GL_BLEND);
// glEnable(GL_LOGIC_OP);
glEnable(GL_DEPTH_TEST);
glDisable(GL_LIGHT1);
glDisable(GL_LIGHT2);
}



class WindowBuffer (front ist z.B ein objekt hiervon)

void setOrthoBuffer()
{
cam.orthomode = true;
int w = (x1 - x0);
int h = (y1 - y0);

glViewport (x0,y0,w,h);
glMatrixMode (GL_PROJECTION);
glLoadIdentity ();

cam.look(w,h);

glMatrixMode (GL_MODELVIEW);
glLoadIdentity ();
glClear (GL_DEPTH_BUFFER_BIT);
}


class Camera (cam ist hiervon ein objekt)

void look(int w, int h)
{
float zoom;
Vector3f vVector = m_vView - m_vPosition;
float hw = (float)(h)/(float)(w);

if(!(vVector.x<=EPSILON && vVector.x>=-EPSILON)) zoom=-m_vPosition.x;
else if(!(vVector.y<=EPSILON && vVector.y>=-EPSILON)) zoom=-m_vPosition.y;
else if(!(vVector.z<=EPSILON && vVector.z>=-EPSILON)) zoom=m_vPosition.z; //*/
glOrtho(-zoom, +zoom, (-zoom*hw), (+zoom*hw),
-100.0f, 100.0f);
gluLookAt(m_vPosition.x, m_vPosition.y, m_vPosition.z,
m_vView.x, m_vView.y, m_vView.z,
m_vUpVector.x, m_vUpVector.y, m_vUpVector.z);
}

[zeckensack]

glVertex3f (-100.0f, 0.0f, 100.0f);
glTexCoord2f( 0.0f, 150.0f);

glVertex3f ( 100.0f, 0.0f, 100.0f);
glTexCoord2f( 150.0f, 150.0f);

glVertex3f (100.0f, 0.0f,-100.0f);
glTexCoord2f(150.0f, 0.0f);

glVertex3f (-100.0f, 0.0f,-100.0f);
glTexCoord2f( 0.0f, 0.0f);//*/
Anders herum.
glVertex sammelt alle anderen gesetzten Parameter ein, und "schießt den Vertex ab". Dh wenn du eine Texturkoordinate zuordnen willst, musst du glTexCoord aufrufen bevor du glVertex aufrufst. Für glColor, glNormal, oder was es sonst noch so geben könnte gilt das gleiche.

Du kannst einem Vertex nicht später noch Attribute hinzufügen (oder diese ändern). Er ist schon auf die Reise gegangen.

So wie du es machst bekommt der erste Vertex irgendeine alte Texturkoordinate von früher, der zweite Vertex bekommt die erste Texturkoordinate usw, und der vierte Vertex bekommt die dritte Texturkoordinate. Die vierte bleibt "im Raum stehen" und kommt dann wohl an einer Stelle zum Einsatz die du nicht erwartet hättest.

[del_4901]

uhh, so einfach ^^
besten Dank ... hab das gar nicht gesehn ^^.


Mal ne andere Frage. Mein Grid ist noch ein ziehmliches Moreé-Monster,
lässt sich da was machen?

Ich dachte da so an AF und ein paar Mips, oder reicht das nicht?

[Xmas]

Sollte reichen. Bei den Mipmaps kannst du für das Grid einen Trick anwenden: keine "echten" Mipmaps verwenden, sondern den Linienabstand in Texeln für jede Stufe konstant halten (Zweierpotenz, damit Repeat richtig funktioniert). Somit verschwinden bei Verkleinerung immer mehr Zwischenlinien, und der Abstand der verbleibenden Linien auf dem Bildschirm bleibt immer in einem gewissen Rahmen.

[Gast]

Was mich interessieren würde: Im Window-Titel werden bei dir mehr als 400 fps angezeigt. Wie geht das? Ich komme i.d.R. auf nicht mehr als 60 fps (weil vermutlich die Windows Paint-Events Abarbeitung darauf geeicht ist). Schneller habe ich das noch nicht kontrolliert hinbekommen obwohl intensiv versucht. Oder läuft das Programm gar nicht unter Windows?

[del_4901]

Was mich interessieren würde: Im Window-Titel werden bei dir mehr als 400 fps angezeigt. Wie geht das? Ich komme i.d.R. auf nicht mehr als 60 fps (weil vermutlich die Windows Paint-Events Abarbeitung darauf geeicht ist). Schneller habe ich das noch nicht kontrolliert hinbekommen obwohl intensiv versucht. Oder läuft das Programm gar nicht unter Windows?

IHHHHHHHH Paint-Events

Versuchs mal mit ner Endlosschleife a la:

bool done = true;

while(done)
{
if (PeekMessage(&msg,NULL,0,0,PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else renderer.draw();
}


Dann hab ich noch eine PreAlpha VBO Implementierung eingebaut ... mit dem löschen klappt ned so ganz ... also Switchen von Vollbild Fenster und zurück ist nicht soooo toll ^^

Und Interleaved Arrays sind nicht verkehrt.

[Gast]

IHHHHHHHH Paint-Events

Versuchs mal mit ner Endlosschleife a la:

bool done = true;

while(done)
{
if (PeekMessage(&msg,NULL,0,0,PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else renderer.draw();
}


Dann hab ich noch eine PreAlpha VBO Implementierung eingebaut ... mit dem löschen klappt ned so ganz ... also Switchen von Vollbild Fenster und zurück ist nicht soooo toll ^^

Und Interleaved Arrays sind nicht verkehrt.
Ich stelle nur ein Bild als Texture dar. (Die Grafikkarte spielt also intensiv Tic-Tac-Toe, um sich die Zeit zu vertreiben.)

Wenn ich z.B. eine Schleife zum Rendern nehme (C#/C++, kein Vollbild, das OpenGL-Fenster ist nur ein Teil des Windows-Window mit anderen normalem Windows-Elementen, also z.B. Scrollbars), dann kommt mir vermutlich immer noch SwapBuffers() und/oder Begin/End Paint() in die Quere, weil das gerenderte Bild/Window ja nun irgendwie auch koordiniert (Rücksicht auf andere Fenster und Windows-Elemente) angezeigt werden muss?

for (int i =0; i < 1000; i++) {
BeginPaint();
draw.texture();
SwapBuffers();
EndPaint();
}

Das Bild wird angzeigt, aber schneller als 60 fps geht es trotzdem nicht. Irgendwas Fundamentales scheine ich noch nicht zu wissen...

[del_4901]

Das Bild wird angzeigt, aber schneller als 60 fps geht es trotzdem nicht. Irgendwas Fundamentales scheine ich noch nicht zu wissen...

1) hast du nen TFT -> nein weiter mit 2)
I ja
V
2) hast du deine Refreshrate auf 60Hz -> nein (keine Ahnung)
I ja
V
3) mach Vsync aus ^^

[del_4901]

ich hab heut Pech mit den Buttons

PS: solange deine Anwendung nicht auf mehrerern CPUS laufen lassen willst, kommt sich auch niks in die Quere.

[Gast]

1) hast du nen TFT -> nein weiter mit 2)
I ja
V
2) hast du deine Refreshrate auf 60Hz -> nein (keine Ahnung)
I ja
V
3) mach Vsync aus ^^
Jupp, VSync war's. Ich hatte probehalber die Refersh-Rate im NVidia-Panel auf 75 hz umgestellt (habe ein TFT), aber es wurden weiterhin nur ~60 fps gerendert. Da hatte ich VSync als Ursache ausgeschlossen. Komisch.

Schönen Dank jedenfalls!

[del_4901]

Jupp, VSync war's. Ich hatte probehalber die Refersh-Rate im NVidia-Panel auf 75 hz umgestellt (habe ein TFT), aber es wurden weiterhin nur ~60 fps gerendert. Da hatte ich VSync als Ursache ausgeschlossen. Komisch.

Schönen Dank jedenfalls!

np. Jetzt kannst du mir ja auch erklären, wie du Buttons, Scrollbars etc. "neben" das OGL Fenster bekommen hast.

Wenns über die MFC läuft kannst du dir die Erklärung auch spaaren. ^^ ironie stdfx.h oder wie auch immer gibs bei mir nicht mehr ... /ironie


BTW: ich hab da mal eine Frage. Wie krieg ich meine C++ Anwendung in einen C# Kontext (ich bin C# noob , Java geht so, und c++ pro) ... wegen den Ganzen Buttons Layouts menus etc. Soll "nur" die Bedienung des Editors vereinfachen, darf ruhig etwas Speed fressen.

[TheGamer]

Versuch mal Managed C++ C++/CLI. Dann kannst du mti WIndowsForms rum machen ist sehr einfach

[del_4901]

Versuch mal Managed C++ C++/CLI. Dann kannst du mti WIndowsForms rum machen ist sehr einfach
ja sowas in der richtung habe ich bereits gehört ... nach gesucht, aber kein tut gefunden. Hast du da nen tutorial?

[TheGamer]

Zuerst mal die neuste version von c++/cli die gibt imo nur in vs2005. Dann einfach ein neues projekt machen c++/cli mit windows forms. dann ahst ud managed c++ und kannst auch native c++ einfuegen

[Gast]

np. Jetzt kannst du mir ja auch erklären, wie du Buttons, Scrollbars etc. "neben" das OGL Fenster bekommen hast.

Wenns über die MFC läuft kannst du dir die Erklärung auch spaaren. ^^ ironie stdfx.h oder wie auch immer gibs bei mir nicht mehr ... /ironie


BTW: ich hab da mal eine Frage. Wie krieg ich meine C++ Anwendung in einen C# Kontext (ich bin C# noob , Java geht so, und c++ pro) ... wegen den Ganzen Buttons Layouts menus etc. Soll "nur" die Bedienung des Editors vereinfachen, darf ruhig etwas Speed fressen.
Bin auch Win App Entwickler Anfänger. Unser Hobby-Projekt (OpenGL-Bildbetrachter mit einfacher HW-schleunigter Bildbearbeitung, also Shader-Programme) sollte erst mit C# V1.1 als simples UI-Front-End und C++ für den Rest (OpenGL + umfangreiche Bibliothek wegen Komptibiliät). Das ging gründlich in die Hose (managed vs. umanaged Code u.a.).

Jetzt habe ich nochmal neu mit C# Express V2.0 (ist umsonst von MS runterladbar) angefangen. Den Source-Code der ebenfalls freien Basic-Version des "C# OpenGL Framework" habe ich mir dann als "Ideengeber" heruntergeladen:
http://www.csharpopenglframework.com/basic_edition.html
Der darin enthaltene wichtige C#-OpenGL-Wrapper ist allerdings ebenfalls geklaut. Bin soweit sehr zufrieden.

[Xmas]

Zuerst mal die neuste version von c++/cli die gibt imo nur in vs2005. Dann einfach ein neues projekt machen c++/cli mit windows forms. dann ahst ud managed c++ und kannst auch native c++ einfuegen
C++/CLI ist nicht Managed C++.

[TheGamer]

ok :)

Dann stells richtig bitte. was was ist und was er verwenden soll

[Xmas]

C++/CLI gibt es ab VC++ 2005, und das sollte man auch nehmen. Managed C++, der Vorgänger, ist in so ziemlich allen Belangen schlechter und sollte folglich nicht mehr verwendet werden.

[TheGamer]

ah ok dann passts eh fast was ich sagte ich sagte ja er soll ab vc2005 verwenden weils vorher noch nciht so das wahre ist

[Coda]

AlphaTier irgendwie find ich es sinnvoller ein Gitter mittels Lines anstatt einer Textur zu zeichenen :|

[Gast]

AlphaTier irgendwie find ich es sinnvoller ein Gitter mittels Lines anstatt einer Textur zu zeichenen :|

das war auch meine erste Idee ... das ganze ist aber nicht so flexibel .. und generiert nen haufen Aufrufe. Bei mir kann jeder das Grid machen wozu er lust hat, verstehst ^^

[del_4901]

das war auch meine erste Idee ... das ganze ist aber nicht so flexibel .. und generiert nen haufen Aufrufe. Bei mir kann jeder das Grid machen wozu er lust hat, verstehst ^^
Alf

[Coda]

das war auch meine erste Idee ... das ganze ist aber nicht so flexibel .. und generiert nen haufen Aufrufe. Bei mir kann jeder das Grid machen wozu er lust hat, verstehst ^^Wozu gibt es denn bitte dynamische Vertexbuffer? Und das ist sehr viel flexibler, weil man Gitterlinien je nach Zoomfaktor ein- und ausblenden kann.