Große Koordinaten (OpenGL)

[user0]

Hallo,

ich arbeite an einer Software, die Konstruktionen auf Koordinaten > 10.000.000
darstellen muss. Wir verwenden GLScene (OpenGL). Wenn man sich aber Objekte auf
diesen großen Koordinaten anschaut, dann sind Parallelen nicht mehr parallel
und bei jeder Kamerabewegung springen die Enden von Linien hin und her.

OpenGL scheint so große Koordinaten einfach nicht zu unterstüzen. Dabei wurden
alle Koordinaten der Endpunkte der Linien mit glVertex3d übergeben, also als
double.

Gibt es eine Art Flag, den man setzen muss, damit OpenGL mit großen Koordinaten
arbeiten kann? Oder ist das einfach nicht möglich? Wenn ja, wie lößt man dieses
Problem am besten? Ich habe versucht die ganze Scene zu skalieren, aber dann
kann man nicht mehr nah genug ranzoomen. Die Scene zu verschieben ist auch nicht
so einfach, da ein Teil bei (0|0) und ein anderer bei (10000000|-12000000)
liegen kann.

[turboPASCAL]

Ich nehme mal an das es an der Kamera liegt. Da ist eine bestimmte "Brennweite" eingestellt.

[Corpsman]

wenn du hergehst und deine Variablen scallierst ?

in OpenGL sind ja Double Koodrinaten.

D.h. wenn du deine 10.000.00 erst mal sagen wir durch 10.000 Teilst dann wird deine "OpenGL" welt kleiner.

bzw. kannst du denke ich mal nicht den ganzen Bereich auf einmal sehen. Das würde dann wohl recht viel Renderzeit brauchen. und bringt dir auch nichts da du ja in der Regel nur 1280x1024 Pixel zum anzeigen hast.

[3_of_8]

Also ersteinmal gibt es immer eine Back-Clippingplane, die alles abschneidet, was weiter weg ist als der Wert, den du mit gluPerspective eingestellt hast. Außerdem gibt es da tatsächlich relativ unschöne Ergebnisse mit Rundungsfehlern, auch wenn du es als Double übergibst. Und der Füllrate dürfte das auch nicht allzu gut tun.

Wozu brauchst du denn so hohe Werte?

[dizzy]

Das Problem ist das übliche, wenn man mit Gleitpunktwerten rechnet. Bei Werten die stark von 0 verschieden sind, sind einfach nicht mehr genug Werte zwischen 2 anderen überhaupt abbildbar um ein "Scheinkontinuum" zu sein. Am genausten sind Floats (egal wie viele Bits nun) wenn sie möglichst nah an 0 liegen. Wie weit man davon weg kann, hängt dann davon ab was man machen möchte, und wie genau der Datentyp nun ist. Da gibt es kein Patentrezept.
Allerdings ist man bei OpenGL, selbst wenn man Double-Werte übergibt, immer im Beriech von Single! Dass heisst, dass du bei 10mio schon ganz schön arg über der Genauigkeit bist. Skalieren hilft, aber nicht wenn du Details drin hast, die in ihrer Ausdehnung schon weit im Nachkommabereich liegen (das wäre aber eine wahnsinnig rieeeesige Szene mit unglaublichem Detailreichtum. Sowas ist mir zumindest noch nicht begegnet ).

Eine Mögliche Variante das ohne Skalierungen zu erledigen wäre es, den Raum in Octrees zu unterteilen, und mit einer Sichtbarkeitsprüfung nachher die Würfel zu identifizieren, die überhaupt nur dargestellt werden müssen (sollte man bei so großen Szenen ohnehin in Betracht ziehen). Noch netter wirds, wenn du die Geometrie in die Prüfung mit einbeziehst, so dass von Wänden verdeckte Raumwürfel, die zwar im Sichtfeld lägen, trotzdem ausgelassen werden.
Das was du dann noch an Raumteilen über hast, kannst du dann um den Weltmittelpunkt von OpenGL zentrieren, und die Kamera entsprechend anpassen.

Das ganze ist allerdings keine Kleinigkeit, sondern schon eher ein ziemlicher Hammer. Ich weiss ja nicht, wofür du das brauchst, jedoch weiss ich von einigen Spielen, dass sie ähnlich vorgehen (da meist aber mit Unterteilung in Zones von Hand bei Erstellung der Level, und evtl. danach Octrees).
Wenn du zudem in Echtzeit durch die Szene laufen möchtest, dann ist das ganze Prozedere was die Darstellung angeht ein immenser Zetisparer, aber auch nur, wenn man es intelligent und gut implementiert.


Wenn deine Szene also keine winzigen Details enthält, skalier besser einfach. Und wenn du nicht nah genug ran kommst, dann setz die Near-Clipping-Plane näher

[Oxmyx]

Prinzipiell ist es, wenn man's richtig macht, egal ob man große oder kleine Zahlen verwendet. Die Logik dahinter ist doch recht einfach: Wenn ich in Dimensionen von +- 10.000.000 rechne und darstelle, dann wird wohl ein Detail in einer Dimension von +- 0.1 überhaupt nicht ins Gewicht fallen, weil es einfach untergeht.

Was du bei der Darstellung noch beachten solltest, sind die Clippingebenen. Die nahe Clippingebene sollte nicht zu nahe an 0 sein, sondern so weit weg wie möglich. Die meiste Präzision des Z-Puffers verliert man nämlich nicht dadurch, dass man die ferne Clippingebene zu weit weg setzt, sondern dass man die nahe Clippingebene zu nah setzt.