Was ich herausgefunden habe:
Die Heightmap wird von (-255,0,-255) gezeichnet, geht dann die erste Reihe zu (256,0,-255)
und macht dann mit Reihe (-255,0,-254) bis (256,0,-254) weiter.
Die letzte gezeichnete Reihe wäre (256,0,-255) bis (256,0,256). (Die Heightmap(TGA) hatte Auflösung von 512x512, aus der nur Rot ausgelesen wird).
Die Displayliste wird vor dem Aufruf nicht translatet, also direkt im Ursprung gezeichnet.

Drehe ich die z-Koordinaten um, so ist die Blickrichtung bei der alles verschwindet die -z Richtung statt der z Richtung.
Verschiebe ich die ganze Heightmap um 255 Richtung z, so wird bei jedem Winkel alles angezeigt(egal ob via translate oder dem versetzen der Koordinatenvektoren).

Meine Mutmaßung ist, dass der "Ankerpunkt" bzw Koordinatenursprung des Heightmap-drawElements-Konstruktes irgendwie nach 0,0,-255 geraten ist oder so behandelt wird. Gerät dieser Punkt zu weit aus dem aktuellen Bild(ca 80° von der aktuellen Blickrichtung), so wird das ganze Konstrukt komplett als "nicht sichtbar" behandelt.

Eine andere Mutmaßung war, daß es vielleicht etwas mit Overdraw zu tun hat, was ich allerdings als sehr unwahrscheinlich erachte. Die Menge der gezeichneten Vertexe scheint keine Rolle zu spielen, da das ganze auch verschwindet, wenn ich nur 1/6 der Triangles zeichne.

Der einzige Workaraound wäre, jedes Dreieck mittels immediate Mode zu zeichnen statt mit drawElements, aber da bricht meine framerate auf unter 50 fps zusammen.

Wie kann man sowas überprüfen?

Mittels glIsEnabled(GL_CULL_FACE) geht das.

Du kannst natürlich auch einfach einmal testweise glDisable(GL_CULL_FACE) machen

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

@Skeltek ich weiß nicht wie es bei ATI ist, aber bei Nvidia gibt es auf dem Desktop eine "NVIDIA Systemsteuerung", mit der man die 3D-Einstellungen verwalten kann. Dort kann man so Sachen wie Antialiasing, Texturfilterung oder vSync einstellen.

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University

Vielleicht lohnt sich auch das Lesen von dieser Seite.

glEnableClientState() und glVertexPointer() machen in der Display-Liste keinen Sinn, da damit client und nicht server states verändert werden. Du müsstest diese Funktionen also nochmal extra vor glCallList aufrufen. glDisable(GL_LIGHTING) und glDisable(GL_CULL_FACE) dagegen würde ich sicherheitshalber lieber mit in die Display-Liste reinnehmen.

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University

Hatte ursprünglich nicht herausgelesen, daß du cullface meinst.
Mit der Orientierung der Polygonzüge hat das ganze leider nichts zu tun.
Und ja, Cullface hatte ich auch bereits disabled zur Sicherheit.

Das wäre der Code für die Liste:

Ich glaube kaum, dass man da so viel falsch machen kann.
Es scheint mir wirklich mit dem nördlichsten mittleren Punkt der Karte zusammenzuhängen...
Wie ich sagte, auf den anderen Rechnern geht es. Leider habe ich keinen zweiten Rechner mit Radeon Karte zum testen.

Rufst du auch glEnableClientState und glVertexPointer/glNormalPointer vor glCallLists auf?

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University

Wozu das denn? Die Vektoren sind doch bereits erstellt?

Ok, du hast recht, die Doku sagt: ...Because the array pointers and enables are client-side state, their values affect display lists when the lists are created, not when the lists are executed.

Von Vertex-Arrays in Displaylisten wird allerdings eher abgeraten (16.100). Durch den zusätzlichen Speicherverbrauch kann deine Anwendung sogar deutlich langsamer werden, kommt aber auf die Implementierung an.

Wieso nutzt du eigentlich keine VBOs?

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University

VBOs nicht, weil uns das Verwenden externer Bibliotheken untersagt wurde. Und VBOs ohne Bibs einzusetzen wäre laut vielen Leuten eine Unzumutbarkeit gewesen.

Interessanter Link den du angibst. Allerdings wird dort gesagt, daß Vertex Arrays mehr Speicherplatz verwenden wenn man pro Vertex Polygon-abhängig mehrere Normalenvektoren benötigt.
Allerdings ist das ja bei Smooth-Shading nicht der Fall.
Ich benutze pro Vertex den gewichteten Mittelwert den angrenzenden Flächennormalen, also ist es im Fall der Heightmap keine Vervielfachung(Versechsfachung) der zu speichernden Vektoren.

Im Übrigen habe ich vermutlich ohnehin den GPU-Speicher nicht annähernd ausgereizt. Es war ja nur ein Hochschulprojekt und keine professionelle Anwendung.
Ich habe nur gemerkt, dass die Anwendung eine deutlich langsamere Framerate aufweist, wenn ich statt dem Vertexarray die Triangles im Immediate Mode abspeichere...

Zumindest sollte man nicht VBOs und Displaylisten gleichzeitig verwenden, da dann der gesamte Speicherbereich kopiert wird (siehe diesen Forumsbeitrag).

Für Vertex Arrays machen VBOs sehr viel Sinn, das Zeichnen im Immediate Mode ist natürlich noch viel weniger zu empfehlen. Überzeugt euren Professor doch, dass ihr modernes OpenGL lernen wollt (wobei VBOs auch schon über 10 Jahre auf dem Buckel haben). VBOs gehören heute längst zum Standard und sollten problemlos auch in Hochschulprojekten benutzt werden dürfen.

Wenn ihr keine externen Bibliotheken benutzen sollt, dürftet ihr eigentlich auch kein freeglut verwenden. glew und freeglut oder openglut gehören aber nunmal zu den absoluten Basisbibliotheken, um mit OpenGL anständig zu programmieren.

Viele Grüße
dj3hut1

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University

Ja, wie gesagt. Projekt ist gelaufen, Ziel war es eher sich mit der zugrundliegenden Mechanik auseinander zu setzen.

Was ich allerdings nun Zeit gehabt habe zum testen:
Wenn ich das exakt selbe drawElements in meiner drawFunction aufrufe, tritt der Fehler nicht auf.
Hier der Code:

funktioniert

Dagegen:

funktioniert nur fehlerhaft, sodass die Heightmap gar nicht erst gerendert wird sobald man in diversen Winkeln Richtung -z schaut.

Verstehe es halt nicht... es ist exakt dieselbe Zeichenanweisung, nur dass sie einmal direkt ausgeführt und das andere mal gespeichert und dann ausgeführt.

ps:
DisplayList mit VertexArray(Triangles): 38 Frames/s (Heightmap wird bei Blickrichtung nach Süden nicht angezeigt, die Frame/s werden aber nicht erhöht; fraglich ob sie "unsichtbar" gerendert wird)
DisplayList mit ImmediateMode(Triangles): 26-28 Frames/s
DirectDraw mit VertexArray(Triangles): 18-19 Frames/s

Was ich noch sehe ist, dass du beim DirectDraw explizit Werte für glColor übergibst. Kann es sein, dass eines deiner anderen Display-Objekte beim Erstellen den Wert für glColor verändert? glColor4f sollte auf jeden Fall mit in die Display-Liste gespeichert werden, ansonsten wird beim Aufruf von glDrawElements ein zufälliger aktueller Farbwert gesetzt. Vor glCallList hätte glColor dann sowieso keine Wirkung.

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University

Ja, das ist mir auch schon aufgefallen
Das ist nur "fail-safe". Ich rufe glColor4f grundsätzlich sowohl in der Zeichenmethode als auch in der aufrufenden Funktion auf, um nach jedem Codeschnipsel den Standard wieder herzustellen.