Ich hab' da 'n doofes Problem.

Wenn ich das Near-Clipping-Plane auf 0.1 setze, dann kann ich zwar schön nah an meine Objekte ran, aber ich bekomme Darstellungs-Fehler wenn ich ein wenig weiter weg bin. Diese Fehler wirken sich so aus, dass Surfaces durch irgendwelche komischen Zeilen unterbrochen werden. Aber eben erst ab 'ner gewissen Entfernung.

Setze ich das Near-Clipping Plane auf 1, dann kann das Objekt soweit weg sein wie es will, es gibt einfach keine Darstellungs-Fehler. Aber ich kann nicht richtig ran gehen, da es zu früh geclippt wird. Das gibt eben nun das Problem in einer 3D-Engine. Ich kann nicht richtig vor einer Wand stehen, da diese zu früh abgeschnitten wird.

Als FOV hab' ich 45 und als Far-Clipping-Plane 1000. Um nach 'ner Lösung zu suchen hab' ich einfach 'nen Blick in den Quake2-Source geworfen und bin nun völlig verwirrt. Carmack verwendet einen Near-Cliping-Plane von 4!?! Wenn ich das mache, komm ich niemals in die Verlegenheit nah' an meine Objekte heran zu treten, da diese vorher verschwinden!

Hat jemand 'ne Idee?

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Das Problem ensteht dadurch, dass der Z-Buffer von OpenGL nur eine begrenzte Auflösung hat - meistens 16, 24 oder 32 Bit (obwohl es auch schräge Implementationen gibt (gab), die z.B. nur einen Z-Buffer von 12 Bit haben).
Diese Bandbreite wird nun immer zwischen ZNear und ZFar aufgespannt - also kannst du dir aussuchen, ob du einen hoch auflösenden Z-Buffer haben willst, der nur einen begrenzten Bereich darstellt, oder aber einen großen Bereich darstellen möchtest, in dem der Z-Buffer nur begrenzt nützlich ist (das Problem nennt sich übrigens Z-Fighting).

Die Near Clipping Plane wirkt sich übrigens stärker aus (wie du schon bemerkt hast), da der Z-Buffer nicht linear zwischen ZNear und ZFar aufgespannt wird - vielmehr braucht man für nahe Geometrie mehr Bit des Z-Buffers - wenn du in die Entfernung siehst, sieht das gleiche Objekt ja auch viel kleiner aus und muss daher nicht so genau dargestellt werden. Daher ist es für die Auflösungsgenauigkeit völlig wurscht, ob du den Z-Buffer von 0.1 bis 100 oder von 1 bis 1000 gehen läßt.
Das ist übrigens genau dein Problem - dass eine Einheit im Z-Buffer in weiteren Entfernungen eine viel größere Distanz abdeckt, als in der Nähe.

Was kann man tun:
1) Umgehe Z-Fighting mittels Stencil-Buffer oder dem Polygon Offset (verlangsamt Darstellung)
2) Teile deine Geometrie in mehrere Tiefenteile auf (z.B. 2), setze den Z-Buffer entsprechend und zeichne die Geometrie (z.B. von 0.1 bis 10 und von 10 bis 1000) - noch langsamer
3) Skalier deine Geometrie entsprechend größer und setze ZMin auf eins (dann kannst du auch vor einer Wand stehen). Die Quake2 Modelle sind übrigens RIESIG, wenn man sie einfach so lädt - ich nehme an, Carmack hat genau (3) gemacht
4) Far Clipping Plane von 1000 kommt mir relativ viel vor (hängt natürlich von deiner Geometrie ab). Ich verwende meistens 100 bis 500 (meist so um 150 bis 200 herum). Evtl. kannst du ZMax problemlos niedriger setzen
5) Vielleicht hast du ein Pixelformat mit 16 Bit Z-Buffer aktiviert - dann könntest du ein anderes (mit 24 oder 32 Bit) wählen. Von (5) würde ich aber abraten, da dein Programm sicher auch auf älteren Grafikkarten, die nur 16 Bit haben, funktionieren soll.

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

Das mit dem Z-Buffer dachte ich mir schon halber. Hatte aber im stillen die Hoffnung dass es irgend was gibt, was ich übersehen hab.


Stimmt, das End-Produkt sollte auch auf 16-Bit Z-Buffer laufen. Wäre zumindest praktisch, da es sich im aktuelle Fall um einen Bildschirmschoner handelt. Anderer seits, bei einem kompletten, aktuellen Game.... Ich meine, sobald man anfängt, 'nen Stencil-Buffer zu verwenden hat man sowieso 24-Bit ZBuffer und muss mit 'nem 32-Bit Back-Buffer arbeiten, wass dann wieder das Aus für ältere Grafikkarten ist.


Ist eigentlich auch wieder war. Mal rumspielen, was noch akzeptable Werte sind.


Ich steh' gerade auf der Leitung. Wie bitteschön soll ich meine Level-Geometrie runterskalieren. Das fällt doch trotzdem auf dass man nicht davor steht, oder?!?

Auf jeden Fall schonmal danke.

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Bin verwirrt. Carmack verwendet in Quake 2 für NearClip 4 und FarClip 4096. Das iss aber ziemlich happig. Wenn ich (z.B. die Demo von Jahn Horn (Baisic-Engine)) mit diesen Werten initialisiere, dann werden die Level-Daten extrem Früh abgeschnitten. Was also mach ich falsch? Denn wenn ich ein Near-Wert >= 0.1 verwende, ist meine Geometrie nicht mehr voll und ganz Fenster-Füllend. Es bleibt bedingt durch das Clippen imm erin gewisser Rand bzw. die Wände werden einfach zu früh abgesägt.

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Also ich kenne zwar beide Engines nicht aber was Mars sagen wollte ist. Wenn du ein größeres Clipping einsetzen möchtest, dann musst du dementsprechend auch deine gesamte Geometry vergrößern.
Sprich bei ein Clipping von 0.5 und einem Würfel von 1.
Wenn du das Clipping auf 1 setzen möchtest, dann musst du, um die richtigen Größen zu bekommen, dem Würfel eine Größe von 2 geben.

Und deswegen klappt das auch bei Jan Horn nicht. Denn dort müsstest du die Geometry , um einen bestimmten Faktor, vergrößern.

Genau das habe ich gemeint. Wenn der Würfel sehr groß ist, schauts trotzdem so aus, als ob du nahe davor stehst, auch wenn du in Wirklichkeit gar nicht so nahe dran bist. Es bleibt ja völlig dir überlassen, was für einen RL-Maßstab du auf deine Geometrie umlegst (ist 1 ein Meter, Zentimter, 3.1415926 Kilometer ?). In Kombination damit kannst du mit der Projektionsmatrix herumspielen (FoV um die 60), und für den Betrachter sieht es aus, als würde man ein riesiges Gebiet überblicken. Übrigenst kannst du selbst nachrechnen: Carmacks 4096 / 4 entspricht (ungefähr) 1 / 1000 - und mit diesem Wert funktioniert dein Programm ja (genau so wie es mit 0.1 / 100 funktionieren würde).

Etwas Off-Topic - hat konkret nichts mit OpenGL zu tun:
Um etwaige Rundungsfehler zu vermeiden nimmt Carmack dann auch noch Zweierpotenzen - das ist aber nicht notwendig, weil sogar single floats eine viel höhere Genauigkeit haben, als dieser Zahlenbereich benötigen würde. Man darf aber nicht vergessen, dass Carmacks ältere Spiele ja auch auf Software Renderern gelaufen sind (vor Quake sogar nur darauf) - und da ist mann dann froh, wenn man Fließkommaarithmetik durch die um einiges schnellere Festkommarithmetik ersetzen kann (unter anderem weil man für sämtliche komplexen Funktionen schnelle Lookup-Tabellen verwenden kann) - und wenn ich z.B. nur 10 Bit Nachkommastellen habe, macht es schon einen Unterschied, ob der Divisor eine Zweier- oder eine Zehnerpotenz ist.

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

Jetzetle. Jetzt hab' ich's geblickt...und gleich getestet. Hab' mal ein 1 für Near-Clipping verwendet. Nach einer Skalierung um 8 (pro Achse) sah alles wei gewohnt aus und Funktionierte!!!! Jetzt muss ich nur noch prüfen, ob das blöde Flackern der Objekte weiter Weg auch weg ist.

Doch wo verwendet man den Aufruf von glScale am besten: für die Modell-Matrix (also vor jedem DrawScene) oder für die Projektions-Matrix (also nach gluPerspective)? Und wird das Near-Clpping-Plane nicht davon beinflusst? Denn wenn ich mir in der OpenGL-SDK anschaue, welche Werte in der Matrix verändert werden so spielt das alles dann doch irgendwie zusammen. (Da macht man alles mögliche in OpenGL und versagt dann an so 'nem Müll )

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Die near und far clipping plane bleiben von ModelView und Projektionsmatrix ziemlich unbeeindruckt - wenn einem Pixel ein Z-Wert zugeordnet wird, kann das logischerweise erst dann geschehen, wenn dessen Position bekannt ist - und da sind sämtliche Matrixoperationen über die Schnittpunktdaten schon längst vorbei. Nicht dass du das Z-Clipping und den Depth-Buffer mit den (mindestens) sechs in OpenGL zusätzlich implementierten Clipping Planes verwechselst, die auf einer viel höheren Ebene funktionieren .

Das glScale käme auf jeden Fall in die ModelView Matrix (obwohl's im Endeffekt auf das Selbe rausläuft) - wenn ich die Wahl hätte, würde ich aber nur in Notfällen Skalierungen <> 1 verwenden, also lieber die Geometriedaten beim Laden oder Erstellen selbst mit einem Faktor multiplizieren - dann musst du dich z.B. bei der Verwendung von OpenGL Licht auch nicht darum kümmern, dass die Normalvektoren richtig skaliert werden.


Wie schon Albert Einstein so schön sagte - das Wichtigste für einen Wissenschaftler ist ein großer Papierkorb

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

Mist, soviel zur Theorie. Jetzt hab ich 'nen Near-Clipping von 2. Und es gibt keine Clipping-Fehler mehr! Aber wenn ich dann die Skalierung verwende um nah am Objekt zu stehen, gibt's in der Ferne eben doch wieder diese blöden Fehler. Dabei weiss ich gar nicht, ob das wirklich am Z-Buffer liegt. Ich hab' mal ein Screen-Shot gemacht, um das Problem zu verdeutlichen. Beide Varianten sind mit 32-Bit Color und Z-Buffer sowie einem Far-Clipping von 50 erstellt worden. Die Verschiebung auf der Z-Achse betrug in beiden Fällen -14. Das Near-Clipping war beim Linken 0.1 und beim Rechten 1. In der Mitte des Flügels des Objektes (richtig, es handelt sich um einen Tie-Fighter) ist deutlich zu sehen, was ich meine.

Zwar ist der Fehler bei einem Far-Clipping von 1 weg, aber dafür kann ich nicht Nah genug an das Objekt ran, da es vorher abgeschnitten wird. Wenn ich nun eine Skalierung einführe, kann ich zwar wieder näher an das Objekt (also so richtig nah), aber dafür kommt es ab einer gewissen Entferung zu dem Effekt wie auf der Linken Seite. Also was tun...

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Hmm, wenn du das Objekt größer skalierst, sollten die Z-Probleme sogar sinken - da ja die Distanzen zwischen Polygonen ebenfalls steigen. Ich nehme deshalb mal an, dass in deinem Tie Fighter einige Polygone zu finden sind, die wirklich sehr nahe beisammen liegen, bzw. sich sogar teilweise überschneiden (muss fast der Fall sein, 32 Bit Z-Buffer auf eine Distanz von 0.1 bis 50 sollten ja -zig mal ausreichen)

Aber was kann man nun noch tun :
1) Wenn du die Möglichkeit hast, das Objekt zu verändern, schiebst du die fraglichen Polygone einfach etwas weiter nach außen (ja ja, weiß schon - ist lästig), oder du nimmst ein anderes Modell
2) sicher stellen, dass als Depth-Test GL_LESS eingestellt ist (könnte evtl. helfen)
3) als Depth Test GL_LEQUAL einstellen und fragliche Objekte (in diesem Fall die Nabe) als letztes zeichnen - wenn du auf die einzelnen Unterobjekte überhaupt Zugriff hast

Kannst du den Source evtl. online stellen, dass man mal ein bisschen rumprobieren kann ?

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

Ja und nein. Das ist ein Beispiel-File vom AC3D-Modeller. Dieses kann man sich auf dessen HomePage herrunterladen. Ich hab' auf Basis der C-Version des AC3D-Loaders eine Delphi-Klasse zum Laden der Dateien erstellt (wäre evtl. was für dein MCAD, aber das nur Nebenbei). Dieser wird dann in einem (evtl. demnächst folgenden) ScreenSaver verwendet.

Den Loader samt Demo-App und Tie-Modell hab' ich bereits an Phob zugeschickt. Wird vorraussichtlich demnächst erhälltlich sein Damit kann man dann nach belieben 'rumspielen, allerdings nicht die Nabe getrennt zeichnen Ich könnte lediglich mal das Objekt bearbeiten, das wäre 'ne Idee.

Wenn das allerdings so ist, dass das Problem es mit entsprechenden Modell-Design zu umgehen geht, muss ich bei eigens erstellten Objekte eben darauf achten, dass keine Polygone zu nah beieinander liegen.

Erklärt aber immer noch nicht, wo großartig der Unterschied zwischen 0.1 und 1 für das Near-Clipping-Plane liegen soll...

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Stell mal ZNear ganz auf 0, dann siehst du's . Je näher dein ZNear Wert bei Null liegt, desto größer sollte der Wertebereich sein, der für sehr nahe Geometrie verbraten wird (damit die auch noch korrekt dargestellt werden kann, dort ist dann evtl. schon eine tausendstel Einheit wichtig) - desto weniger Bits im Z-Buffer bleiben dann aber für entferntere Geometrie übrig. Aus diesem Grund ist auch das Verhältnis und nicht nur die Differenz zwischen ZNear und ZFar wichtig, somit hat eine kleine Verschiebung des ZNear Wertes den selben Effekt wie eine große Verschiebung des ZFar Wertes .

@Import Filter
Auf der ToDo List stehen bereits 3DS-Max ASE Importe sowie ein robuster WaveFront Obj Filter, ist aber ein guter Vorschlag, ich wollte AC3D ohnhin mal genauer unter die Lupe nehmen.

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

Iss Offtopic, aber:
Ich find' AC3D ziemlich gut, da es einfach zu bedienen ist, alles hat was ein Hobby-Game-Designer brauch (z.B. UV-Texture-Mapping) per PlugIn quasi erweiterbar ist (PlugIn-Header hab' ich auch schon konvertiert) und das komplette Dateiformat ist offen. Es gibt sogar ein Blender-Phyton Script welches den Im- und Export von AC3D Nach Blender ermöglicht!

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Ich hab's mir jetzt runtergeladen - soweit scheint es ganz nett zu sein (hab's nur kurz ausprobiert). Wenn's dich nicht nervt, hätte ich aber folgende Fragen :
- Kann man Texturkoordinaten nur an XY/XZ/YZ Ebene ausrichten ???
- wie schaut's mit Animationen aus ?
- gibt's irgendwo eine Objektsammlung zum runterladen ?

Nachdem das Format ja wirklich sehr einfach ist, werde ich es ziemlich sicher implementieren. Ah ja, noch eine Frage: kann man bei einem Polygonsurface davon ausgehen, dass es tatsächlich konvex ist, oder muss man noch selbst tesselieren (steht leider nicht in der Beschreibung). Wahrscheinlich kommen auch noch Milkshape Dateien dazu, da dies ja anscheinend sehr weit verbreitet ist (ausserdem ist das Format auch nicht so sehr komplex).

Nochmal zurück zum ursprünglichen Thema, vielleicht wird es so klarer:
Die Werte im Z-Buffer kannst du als Ganzzahlen ansehen, das heißt jeder Nachfolger ist definiert, es gibt keine Zwischenwerte, und sie gehen (für 16 Bit Zahlen) immer von 0 bis 65535. Wenn dein ZNear - ZMax von 0.1 bis 1000 geht, entsprechen die Z-Buffer Werte 5 und 6 vielleicht den realen Z-Werten 0.11 und 0.111, die ZBuffer-Werte 65534 bis 65535 den realen Z-Werten 990 und 1000.
Ich möchte eigentlich nur rüber bringen, dass Geometrie einen umso größeren Bereich der real in der Grafikkarte abgelegten Z-Werte frißt, je näher sie am Nullpunkt liegt - dieses Verhalten ist ja auch gut so, immerhin fallen Fehler bei naher Geometrie halt viel eher auf, als bei entfernten Grafiken, die man ohnehin kaum noch sieht - nur ist der Z-Buffer halt sehr begrenzt, und der Bereich der draufgeht nahe Geometrie exakt abzudecken, fehlt dann weiter hinten.

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

Nö. Es gibt auch einen U/V-Editor. Du Erstellst Dein Objekt und weist eine Textur zu. Dann Wechselst Du in den Surface-Modus und wällst das Surface, dessen Textur-Koordinaten Du anpassen möchtest. Dannach wählst Du Tools -> Texture Coordinate Editor. Das dürfte das sein, was Du suchst (oder hab' ich da was falsch verstanden?)


Momentan leider noch nicht implementiert. Ist aber IMO geplant.


Nicht wirklich. Mann kann sich lediglich im Download-Bereich von AC3D 'n paar Demo-Modelle herrunterladen.


Ich bin mir nicht sicher, ob ich Dich richtig verstanden hab. Aber die Standard-Objekte haben eben ihre Standard-Surfaces die IMO immer Konvex sind. Freihand erstellte Polygone sind nicht zwingend Konvex. Je nach dem wie Du sie erstellst. Aber du kannst auch Surfaces markieren und dann im Menu Surface -> Triangluate verwenden. Dadurch wird das Surface in Triangles aufgeteilt. Leider, wie es eben bei deisen Triangulate-Algos fast immer der Fall ist, nicht unbedingt so wie man will. Aber immerhin brauchbar.

Ich find' das Prog nicht schlecht. Es ist recht günstig und kann relativ viel. Zumindest. In Zusammenarbeit mit Blender muss ich sagen, kann ich dann auf so Progs wie 3DS und Co verzichten. Lediglich mit Milkshape liebäugle ich noch etwas. Dann bin ich aber wirklich gut eingedeckt. Naja, wahrscheinlich auch Geschmacksache. Es war halt das erste 3D-Prog das ich in die Finger bekam, welches ich auf Anhieb relativ gut bedienen konnte. Stefan Zerbst hat damit übrigens sein BSP-Tutorial-Test-Level erstellt. So bin ich auch überhaupt zu dem Programm gekommen.

@OnTopic: Also im Klartext: Level- und Modellgeometrie anpassen und so abändern, dass solche Fehler vermieden oder gar nicht mehr sichtbar sind. Das einzigste was mich wunrder ist z.B Seriuos Sam: Dort gibt es mit dem OpenGL-Renderer das gleiche Problem. Falsches Klipping bei Objekten, die Weit weg sind (und per Fernglas sichtbar gemacht werden). Jezt aber kommt der Gag: Mit dem Direct3D-Renderer (also gleiche Level-Geometrie, gleiche Grafikkarte, gleiche Bit-Tiefe, gleiche Entfernung des Objektes und gleiches Fernglas nur statt OpenGL eben Direct3D) tritt der Fehler nicht auf! Was sagt man dazu?!?

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?