Hallöchen,

ich hab eine (denke ich) relativ einfache Frage für die OpenGL Gelehrten hier:

Meinen Renderbereich richte ich wie folgt ein:

(C-Code)

Es geht mir dabei jetzt um die Far und Near Werte für die Tiefe Z.

Wenn ich den Renderbereich so einrichte bedeutet es doch, dass ich von +40 bis -1024 = 1065 Einheiten in die Tiefen habe. Was heißt, dass ich Objekte auf dieser Höhe platzieren kann und diese vom Tiefenbuffer sortiert werden, ja?
Dann nun die Frage dazu; macht die Größe des Tiefenbereichs einen großen Unterschied in der Geschwindigkeit, in der gerendert werden kann?
Also ist es besser, nur Tiefenwerte von z.B. +40 bis -40 = 81 Einheiten zu nehmen oder nimmt es sich nichts in Sachen Geschwindigkeit wenn ich auch von +40 bis -1024 = 1065 Einheiten gehe? Irgendwo kann ich mir vorstellen, dass es durchaus weniger Renderaufwand macht, wenn man von Vorne herein ausmacht, dass nur Höhen von +40 bis -40 möglich sind als wenn man mehr als 13 mal so große Höhen im Tiefenbuffer zulässt.
Wär nett wenn mir da jemand Klarheit verschaffen könnte, was es da so auf sich hat, mit dem Z-Bereich im Projektionsmodus.

mfg.

Sunny

Also eine 100% Antwort kann ich nicht geben, da hilft wohl auch nur einmal ausprobieren Allerdings rein von der Verarbeitung sollte es sich kaum von der Z-Achse im 3D-Raum unterscheiden und damit wohl keine ernsthaften Performance-Probleme im 2D-Bereich verursachen. Denke also in den von Dir genannten Bereichen sollte es keine wirklich merkbaren Unterschiede geben,

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Ok, danke schonmal für die Antwort. Vielleicht weiß es noch jemand genauer, ansonsten werd ich das mal so hinnehmen und bei Problemen mal den Bereich testweise runterdrehen.

Allerdings schein ich da noch ein anderes Problem zu haben. Jetzt funktionieren einige Objekte plötzlich nicht mehr in meinen Z Werten wie sie sollten. Also ich kann nur noch von - 20 bis - 1024 rendern, Werte > -20 werden nicht dargestellt auf der Renderfläche.
Woran könnte das liegen? Oder bedeutet "glOrtho(0, 1024, 0, 768, 40, 1024);" garnicht, dass man von +40 bis - 1024 Tiefeneinheiten hat?

OK, erstmal müssen deine "Einheiten" nicht immer ganze Zahlen sein. Kannst auch von 1.234 bis 9.876 gehen. Auf die Geschwindigkeit hat das überhaupt keinen Einfluss. Es sei denn, du cullst alle deine Dreiecke weg, aber das ist wohl kaum der Sinn der Übung. Dieser Bereich ist nur dafür da, dass man den Wertebereich des Depth-Buffers möglichst gut auf die verwendeten Entfernungen anpassen kann.

So, zu deinem Ortho:



Da müsste der Bereich von 40 bis 1024 gehen. Is also 984 lang. Eigentlich dürfte er nur Dreiecke in diesem Bereich (40 bis 1024) anzeigen.

_________________
[18:30] tomok: so wie ich das sehe : alles. was nich was anderes ist als nen Essay ist nen Essay

hi, i'm a signature viruz, plz set me as your signature and help me spread

Arggh, danke, hab gerade meinen Fehler bemerkt. Ich hab hier im Forum die Reichweite 40 bis - 1024 genannt aber im Code tatäschlich nur 20 bis -1024 gewählt. Und da, wie du AL ja sagtest, der Bereich vom ersten Wert erst beginnt, gings auch erst bei -20 los.
(Eigentlich seltsam warum es bei mir negativ ist. Also mein Bereich geht jetzt nominell von -20 bis 1024, tatsächlich muss ich meine Matrix aber so positionieren, dass die Objekte im Z Bereich von 20 bis - 1024 liegen. Also genau anders herum. Ebenso sonderbar, wenn ich CULL_FACE anstelle und die Rückseite webblende, dann wird meine Vorderseite weggeschaltet. Hab ich da etwa irgendwo einen Zahlendreher drinne, sodass ich von der Rückseite auf das Geschehen bicke? Wie ich meine Matrix einrichte hab ich ja oben beschrieben, ist da was falsch dran?)(Ich setze die Vertex-Punkte im Uhrzeiger-Sinn, ist das etwa genau falsch herum?^^ )

Nun ich denke als OpenGL steht man über den Dingen wie Schwarz/weiß, 0 und 1. Es gibt immer mehre Wahrheiten Aber um deine Frage zu beantworten. Mit den Standardwerten ist es genau falsch herum, ja http://wiki.delphigl.com/index.php/GlFrontFace

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

wieso falschrum?
GL_CCW heißt entgegen dem Uhrzeigersinn und das ist mathematisch positiv, genau wie alle Winkelangaben bei Rotationen.
Wenn ich nun von der Seite aus auf ein Polygon blicke, von der aus die Punkte entgegen dem Uhrzeigersinn am Polygon angeordnet sind, dann ist das vorne.
Es widerspricht lediglich der intuitiven Betrachtungsweise, bei der man davon ausgeht, dass die Uhrzeiger sich 'vorwärts' um die Achse drehen. Genaugenommen gehen aber alle Uhren rückwärts

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

Die "Größe" des Z-Buffers ist völlig egal und hat keinen Einfluss auf die Geschwindigkeit: intern wird der angegebene Bereich ohnehin auf den Bereich von 0 bis 1 (Fließkommanotation) bzw. 0 bis 2^n (Ganzzahlnotation, n=Bits des Z-Buffers) transformiert. Dies geschieht ganz automatisch im Zuge der Projektion (und nichts anderes als eine Projektionsmatrix für eine orthogonale, nicht perspektivische Darstellung setzt du ja mit glOrtho auf).
Was man natürlich sehr wohl berücksichtigen sollte, ist die "Weite" über die die Z-Bits "aufgespannt" werden. Wenn man z.B. nur 16 Bits zur Verfügung hat, ergibt dies 65536 diskrete Werte, d.h. die Szene kann maximal aus 65536 Tiefenabstufungen bestehen - und da macht es sehr wohl einen Unterschied, ob diese jetzt auf eine Einheit oder auf 1000 Einheiten aufgeteilt werden (das Problem zweier eigentlich unterschiedlicher Tiefenebenen, die auf der selben diskreten Tiefenabstufung liegen, ist auch als Z-Fighting bekannt).
Wie es mit Z-Fighting bei den (mehr oder weniger) neuen Fließkommapixelformaten aussieht, müsste man direkt mal ausprobieren - allerdings kann man sich ohnehin noch nicht drauf verlassen, dass Anwender diese überhaupt zur Verfügung haben ...

Interessant ist eventuell noch, dass alte Softwareengines teilweise mit einer Z-Buffertiefe von nur 8 Bit sehr beeindruckende Effekte erzielen konnten, zumindest im Vergleich zur sonst üblichen Methode des Painter-Algorithmus, der ganz ohne Z-Buffer auskommt, da hier Polygone vor dem Zeichnen sortiert werden.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Diese hervoragende Erklärung hab ich gleich ins Wiki übernommen.

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