Camera schaut durch Cube

Übersicht

BlitzBasic

Blitz3D

Gehe zu Seite 1, 2 Weiter

	funkmaster5000 Betreff: Camera schaut durch Cube	Mi, Okt 16, 2013 13:09 Antworten mit Zitat
Hi alle, mein Level ist aus Cubes aufgebaut, durch die sich der Spieler (Camera) in Ego-Ansicht bewegt. Die Steuerung ist wie bei einem Dungeon-Crawler. Pro Tastendruck bewegt sich der Spieler ein Feld nach vorne (in Cubelängen natürlich, also im Endeffekt Spielerx = Spielerx + 2). Drückt man die Pfeiltasten links/rechts rotiert die Camera jeweils um 90°. Wenn ich jetzt an der Wand stehe und die Camera um -90° rotieren lasse, dann schaut der Spieler durch den Cube! Das selbe geschieht, wenn ich die Camera um -90° rotiert habe und mich dann 1 Feld (1 Cubelänge) vorbewege. Dann läuft der Spieler durch den Cube. Nicht komplett, aber man kann hindurchschauen. Kann ich diesen Effekt verhinden? Rotiere ich um 90°, funktioniert alles perfekt. Habe mein Beispiel mal als .rar angehängt. https://www.blitzforum.de/upload/file.php?id=12601

funkmaster5000

Betreff: Camera schaut durch Cube

Mi, Okt 16, 2013 13:09
Antworten mit Zitat

Hi alle,

mein Level ist aus Cubes aufgebaut, durch die sich der Spieler (Camera) in Ego-Ansicht bewegt. Die Steuerung ist wie bei einem Dungeon-Crawler. Pro Tastendruck bewegt sich der Spieler ein Feld nach vorne (in Cubelängen natürlich, also im Endeffekt Spielerx = Spielerx + 2). Drückt man die Pfeiltasten links/rechts rotiert die Camera jeweils um 90°. Wenn ich jetzt an der Wand stehe und die Camera um -90° rotieren lasse, dann schaut der Spieler durch den Cube! Das selbe geschieht, wenn ich die Camera um -90° rotiert habe und mich dann 1 Feld (1 Cubelänge) vorbewege. Dann läuft der Spieler durch den Cube. Nicht komplett, aber man kann hindurchschauen. Kann ich diesen Effekt verhinden? Rotiere ich um 90°, funktioniert alles perfekt.

Habe mein Beispiel mal als .rar angehängt.

https://www.blitzforum.de/upload/file.php?id=12601

	bjh	Mi, Okt 16, 2013 15:04 Antworten mit Zitat
einfach ein BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN] CameraRange camera,.5,500 unter createcamera einfügen, und das problem ist gelöst.

bjh

Mi, Okt 16, 2013 15:04
Antworten mit Zitat

einfach ein
BlitzBasic: [AUSKLAPPEN]

CameraRange camera,.5,500

unter createcamera einfügen, und das problem ist gelöst. Wink

	funkmaster5000	Mi, Okt 16, 2013 15:42 Antworten mit Zitat
Super! DANKE! Was ich mich frage...warum? Ich will ja auch was lernen

funkmaster5000

Mi, Okt 16, 2013 15:42
Antworten mit Zitat

Super! DANKE!

Was ich mich frage...warum? Ich will ja auch was lernen Very Happy

	Jolinah	Mi, Okt 16, 2013 16:28 Antworten mit Zitat
Die Kamera hat 2 Begrenzungsflächen (clip planes). Beide liegen üblicherweise vor der Kamera. Gerendert wird nur was sich zwischen diesen 2 Flächen befindet. Was durch die Flächen durchgeht wird an den Flächen sozusagen abgeschnitten (clip). Mit CameraRange kannst du die Distanz dieser Flächen einstellen. Wenn die erste Fläche zu weit Weg von der Kamera ist, siehst du diesen Abschneide- oder Durchblick-Effekt. Indem du also den ersten Wert kleiner machst und damit die erste Fläche näher heran rückst, kann das Abschneiden verhindert werden. Die zweite Fläche bestimmt somit die maximale Sichtdistanz. Alles hinter der 2. Fläche wird ebenfalls abgeschnitten, bzw. nicht gerendert. Hoffe das hilft

Jolinah

Mi, Okt 16, 2013 16:28
Antworten mit Zitat

Die Kamera hat 2 Begrenzungsflächen (clip planes). Beide liegen üblicherweise vor der Kamera. Gerendert wird nur was sich zwischen diesen 2 Flächen befindet. Was durch die Flächen durchgeht wird an den Flächen sozusagen abgeschnitten (clip).

Mit CameraRange kannst du die Distanz dieser Flächen einstellen. Wenn die erste Fläche zu weit Weg von der Kamera ist, siehst du diesen Abschneide- oder Durchblick-Effekt. Indem du also den ersten Wert kleiner machst und damit die erste Fläche näher heran rückst, kann das Abschneiden verhindert werden.

Die zweite Fläche bestimmt somit die maximale Sichtdistanz. Alles hinter der 2. Fläche wird ebenfalls abgeschnitten, bzw. nicht gerendert.

Hoffe das hilft Wink

	DAK	Mi, Okt 16, 2013 16:37 Antworten mit Zitat
Ich hab kein B3D mehr installiert, also nur interessehalber: Was passiert eigentlich, wenn man die Near-Plane auf 0 oder gar einen negativen Wert setzt?
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Mi, Okt 16, 2013 16:37
Antworten mit Zitat

Ich hab kein B3D mehr installiert, also nur interessehalber: Was passiert eigentlich, wenn man die Near-Plane auf 0 oder gar einen negativen Wert setzt?

Gewinner der 6. und der 68. BlitzCodeCompo

	funkmaster5000	Mi, Okt 16, 2013 16:44 Antworten mit Zitat
Cool! Danke für die Erklärung Wirkt sich diese Einstellung auch eventuell negativ auf die Darstellung aus? Wenn ich 2 Cubes nebeneinander setze und ein wenig entfernt bin, sind sie durch eine schwarze Linie/Bildfehler scharf begrenzt. Das erweckt nicht gerade den Eindruck einer durchgehenden Wand Hier mal ein Screenshot: https://www.blitzforum.de/upload/file.php?id=12602 Und von der Seite: https://www.blitzforum.de/upload/file.php?id=12603 Und höher Aufgelöst. Da ist es etwas subtiler, aber trotzdem vorhanden! https://www.blitzforum.de/upload/file.php?id=12604

funkmaster5000

Mi, Okt 16, 2013 16:44
Antworten mit Zitat

Cool! Danke für die Erklärung Wink

Wirkt sich diese Einstellung auch eventuell negativ auf die Darstellung aus?

Wenn ich 2 Cubes nebeneinander setze und ein wenig entfernt bin, sind sie durch eine schwarze Linie/Bildfehler scharf begrenzt. Das erweckt nicht gerade den Eindruck einer durchgehenden Wand Sad

Hier mal ein Screenshot:
https://www.blitzforum.de/upload/file.php?id=12602

Und von der Seite:
https://www.blitzforum.de/upload/file.php?id=12603

Und höher Aufgelöst. Da ist es etwas subtiler, aber trotzdem vorhanden!
https://www.blitzforum.de/upload/file.php?id=12604

	Jolinah	Mi, Okt 16, 2013 17:21 Antworten mit Zitat
Je nach dem Die nahe Fläche (near clip plane) wirkt sich auch auf die Genauigkeit des DepthBuffers aus. Man sollte diese immer so weit wie möglich (so dass halt nichts beschnitten wird) von der Kamera entfernt setzen, auch wenn es gegen die Logik spricht. Der DepthBuffer ist zuständig um die Distanz von Objekten oder Flächen zu unterscheiden. Wenn der DepthBuffer durch eine schlechte Einstellung der CameraRange zu ungenau wird, kann bei sehr nahe aneinander liegenden Flächen nicht mehr unterschieden werden, welche denn nun näher oder weiter entfernt ist. Dann wird unter Umständen die dahinterliegende Fläche vor der anderen gezeichnet. Und es kommt zu einem Flacker-Effekt bei beiden Flächen (da es zufällig einmal davor und einmal dahinter gerendert wird). Ob das nun damit zusammenhängt kann ich nicht sagen. Es könnte auch nur daran liegen dass die Würfel halt nicht verbunden sind. Selbst wenn die theoretisch exakt aneinander stehen, ist es vielleicht nicht exakt genug. Die Position ist ja auch nur ein Float, und bei diesen wird beim Rechnen durch Rundungsfehler oft der Wert leicht verfälscht. Aber es könnte auch an ganz etwas anderem liegen. @DAK: Das funktioniert so ähnlich wie beim menschlichen Auge. Die Near-Plane ist im Prinzip auch die Fläche die man auf dem Bildschirm zu sehen bekommt. Jedes Pixel/Punkt auf dieser Fläche ist mit einem Lichtstrahl vergleichbar. Wäre die Near-Plane bei 0, dann wäre es keine Fläche mehr, sondern nur noch ein Punkt. Es macht aber nicht viel Sinn eine Szene in einem einzigen Punkt abzubilden Wenn die Near-Plane hinter der Kamera ist, sieht man ein gespiegeltes Bild: http://ksimek.github.io/img/in...no-box.png

Jolinah

Mi, Okt 16, 2013 17:21
Antworten mit Zitat

Je nach dem Smile

Die nahe Fläche (near clip plane) wirkt sich auch auf die Genauigkeit des DepthBuffers aus. Man sollte diese immer so weit wie möglich (so dass halt nichts beschnitten wird) von der Kamera entfernt setzen, auch wenn es gegen die Logik spricht.

Der DepthBuffer ist zuständig um die Distanz von Objekten oder Flächen zu unterscheiden. Wenn der DepthBuffer durch eine schlechte Einstellung der CameraRange zu ungenau wird, kann bei sehr nahe aneinander liegenden Flächen nicht mehr unterschieden werden, welche denn nun näher oder weiter entfernt ist. Dann wird unter Umständen die dahinterliegende Fläche vor der anderen gezeichnet. Und es kommt zu einem Flacker-Effekt bei beiden Flächen (da es zufällig einmal davor und einmal dahinter gerendert wird).

Ob das nun damit zusammenhängt kann ich nicht sagen. Es könnte auch nur daran liegen dass die Würfel halt nicht verbunden sind. Selbst wenn die theoretisch exakt aneinander stehen, ist es vielleicht nicht exakt genug. Die Position ist ja auch nur ein Float, und bei diesen wird beim Rechnen durch Rundungsfehler oft der Wert leicht verfälscht. Aber es könnte auch an ganz etwas anderem liegen.

@DAK:
Das funktioniert so ähnlich wie beim menschlichen Auge. Die Near-Plane ist im Prinzip auch die Fläche die man auf dem Bildschirm zu sehen bekommt. Jedes Pixel/Punkt auf dieser Fläche ist mit einem Lichtstrahl vergleichbar. Wäre die Near-Plane bei 0, dann wäre es keine Fläche mehr, sondern nur noch ein Punkt. Es macht aber nicht viel Sinn eine Szene in einem einzigen Punkt abzubilden Wink

Wenn die Near-Plane hinter der Kamera ist, sieht man ein gespiegeltes Bild:
http://ksimek.github.io/img/in...no-box.png

	DAK	Mi, Okt 16, 2013 19:12 Antworten mit Zitat
Das wäre in etwa das was ich erwartet hätte. Mich hat es nur interessiert, wie B3D das umsetzt, und ob es dann nicht einfach einen Fehler wirft, wie ich es eher erwartet hätte. Verzieht sich das Bild bei einer negativen Nearplane auch?
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Mi, Okt 16, 2013 19:12
Antworten mit Zitat

Das wäre in etwa das was ich erwartet hätte. Mich hat es nur interessiert, wie B3D das umsetzt, und ob es dann nicht einfach einen Fehler wirft, wie ich es eher erwartet hätte. Verzieht sich das Bild bei einer negativen Nearplane auch?

Gewinner der 6. und der 68. BlitzCodeCompo

	Kruemelator	Mi, Okt 16, 2013 21:58 Antworten mit Zitat
Blitz3D kann nicht darstellen bei einer Annäherung an null, genau null oder negativ. Welche Bit-Tiefe hat der z-Buffer in B3D? Die Linien entstehen weil die Würfel auch Seiten haben die hinter den Sichtbaren liegen. Da die Polygone dieser, eigendlich nicht sichtbaren, Seiten aber die selben Vertex (oder eigene Vertex aber mit genau den selben Werten) nutzen. Die Pixel zwischen den beiden Vertex sind bei beiden Polygonen (sichtbar und nicht sichtbar) dieselben, deshalb kann nicht zwischen ihnen unterscheiden werden Einfach nur die Seite anzeigen die sichtbar sein sollen, dann verschwinden die Linien.

Kruemelator

Mi, Okt 16, 2013 21:58
Antworten mit Zitat

Blitz3D kann nicht darstellen bei einer Annäherung an null, genau null oder negativ.
Welche Bit-Tiefe hat der z-Buffer in B3D?

Die Linien entstehen weil die Würfel auch Seiten haben die hinter den Sichtbaren liegen. Da die Polygone dieser, eigendlich nicht sichtbaren, Seiten aber die selben Vertex (oder eigene Vertex aber mit genau den selben Werten) nutzen. Die Pixel zwischen den beiden Vertex sind bei beiden Polygonen (sichtbar und nicht sichtbar) dieselben, deshalb kann nicht zwischen ihnen unterscheiden werden
Einfach nur die Seite anzeigen die sichtbar sein sollen, dann verschwinden die Linien.

	funkmaster5000	Mi, Okt 16, 2013 22:05 Antworten mit Zitat
Aaah das macht Sinn! Wie verstecke ich denn Würfelseiten? Oder wäre es besser, ich erstelle anstelle eines Würfels einfach aus 6 Vertricess ein neues Mesh und rotiere es so, dass es sichtbar ist? Ist natürlich ungleich aufwändiger, aber ich schätze, es gibt keinen einfachen Befehl, um eine spezielle Würfelseite zu verstecken oder?

funkmaster5000

Mi, Okt 16, 2013 22:05
Antworten mit Zitat

Aaah das macht Sinn! Wie verstecke ich denn Würfelseiten? Oder wäre es besser, ich erstelle anstelle eines Würfels einfach aus 6 Vertricess ein neues Mesh und rotiere es so, dass es sichtbar ist? Ist natürlich ungleich aufwändiger, aber ich schätze, es gibt keinen einfachen Befehl, um eine spezielle Würfelseite zu verstecken oder?

	DAK	Mi, Okt 16, 2013 23:38 Antworten mit Zitat
Die Idee ist, dass du nur Außenseiten deiner Wand zeigst. Soll die Wand von beiden Seiten sichtbar sein, dann erstellst du einfach beide Seiten, und lässt die anderen weg. Das mit dem Rotieren wäre wohl einen Schritt zu kompliziert gedacht. Was auch geht, ist dass du Sprites verwendest, um die Wände darzustellen. Brauchst hald für jede Seite ein Sprite. Oder du modellierst dir dein ganzes Level (oder Levelsegmente) als Mesh in dem 3D-Editor deiner Wahl, und lädst die in dein Spiel rein.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Mi, Okt 16, 2013 23:38
Antworten mit Zitat

Die Idee ist, dass du nur Außenseiten deiner Wand zeigst. Soll die Wand von beiden Seiten sichtbar sein, dann erstellst du einfach beide Seiten, und lässt die anderen weg. Das mit dem Rotieren wäre wohl einen Schritt zu kompliziert gedacht.

Was auch geht, ist dass du Sprites verwendest, um die Wände darzustellen. Brauchst hald für jede Seite ein Sprite.

Oder du modellierst dir dein ganzes Level (oder Levelsegmente) als Mesh in dem 3D-Editor deiner Wahl, und lädst die in dein Spiel rein.

Gewinner der 6. und der 68. BlitzCodeCompo

Zuletzt bearbeitet von DAK am Do, Okt 17, 2013 9:16, insgesamt einmal bearbeitet

	Kruemelator	Mi, Okt 16, 2013 23:38 Antworten mit Zitat
Ne, Seiten nicht anzuzeigen geht nicht so einfach. Erstell einfach ein Mesh welches nur eine Seite eines Würfels ist, das sind 4 Vertices und 2 Triangle. Diesen kannst du dann einfach passend drehen wenn du die Seite in eine andere Richtung brauchst. Ein Tip: Wenn sich die Würfel nicht verändern dann packe sie alle in ein Mesh, das um einiges schneller als 1000 Entitys zu haben. Die nötigen Befehle dazu sind: BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN] CreateMesh() AddMesh() ScaleMesh();wie ScaleEntity RotateMesh();wie TurnEntity PositionMesh();wie TranslateEntity Dabei immer erst skalieren, dann rotieren und zum Schluss positionieren. FreeEntity nach dem AddMesh nicht vergessen.

Kruemelator

Mi, Okt 16, 2013 23:38
Antworten mit Zitat

Ne, Seiten nicht anzuzeigen geht nicht so einfach. Erstell einfach ein Mesh welches nur eine Seite eines Würfels ist, das sind 4 Vertices und 2 Triangle. Diesen kannst du dann einfach passend drehen wenn du die Seite in eine andere Richtung brauchst.
Ein Tip: Wenn sich die Würfel nicht verändern dann packe sie alle in ein Mesh, das um einiges schneller als 1000 Entitys zu haben.
Die nötigen Befehle dazu sind:
BlitzBasic: [AUSKLAPPEN]

CreateMesh()
AddMesh()
ScaleMesh();wie ScaleEntity
RotateMesh();wie TurnEntity
PositionMesh();wie TranslateEntity

Dabei immer erst skalieren, dann rotieren und zum Schluss positionieren. FreeEntity nach dem AddMesh nicht vergessen.

	Mr.Floppy	Do, Okt 17, 2013 12:43 Antworten mit Zitat
Kruemelator hat Folgendes geschrieben: ... Die Linien entstehen weil die Würfel auch Seiten haben die hinter den Sichtbaren liegen. Da die Polygone dieser, eigendlich nicht sichtbaren, Seiten aber die selben Vertex (oder eigene Vertex aber mit genau den selben Werten) nutzen. Die Pixel zwischen den beiden Vertex sind bei beiden Polygonen (sichtbar und nicht sichtbar) dieselben, deshalb kann nicht zwischen ihnen unterscheiden werden Einfach nur die Seite anzeigen die sichtbar sein sollen, dann verschwinden die Linien. Das verstehe ich nicht. Es werden doch in diesem Fall ohnehin alle Seiten des Würfels gerendert, ob nun sichtbar oder nicht. Zudem haben Triangles nur zwei Dimensionen, insofern haben die Seiten eines Würfels bei Frontalansicht keinerlei Ausdehnung. Wäre nett wenn du das nochmal erläutern könntest.

Mr.Floppy

Do, Okt 17, 2013 12:43
Antworten mit Zitat

Kruemelator hat Folgendes geschrieben:

...

Die Linien entstehen weil die Würfel auch Seiten haben die hinter den Sichtbaren liegen. Da die Polygone dieser, eigendlich nicht sichtbaren, Seiten aber die selben Vertex (oder eigene Vertex aber mit genau den selben Werten) nutzen. Die Pixel zwischen den beiden Vertex sind bei beiden Polygonen (sichtbar und nicht sichtbar) dieselben, deshalb kann nicht zwischen ihnen unterscheiden werden
Einfach nur die Seite anzeigen die sichtbar sein sollen, dann verschwinden die Linien.

Das verstehe ich nicht. Es werden doch in diesem Fall ohnehin alle Seiten des Würfels gerendert, ob nun sichtbar oder nicht. Zudem haben Triangles nur zwei Dimensionen, insofern haben die Seiten eines Würfels bei Frontalansicht keinerlei Ausdehnung.

Wäre nett wenn du das nochmal erläutern könntest. Smile

	Kruemelator	Do, Okt 17, 2013 12:57 Antworten mit Zitat
Jede Seite eines Würfels hat zwei Triangle. Wenn zwei Seiten aneinandergrenzen (nur die gegenüberliegende grenzt nich an) dann teilen sie sich genau zwei Vertices. Jeder Punkt zwischen diesen beiden Vertices gehört praktisch beiden Triangles und wenn jetzt erst das verdeckte Triangle gerendert wird, dann gibt es für das zweite Triangle für diese Pixel schon einen Wert im z-Buffer.

Kruemelator

Do, Okt 17, 2013 12:57
Antworten mit Zitat

Jede Seite eines Würfels hat zwei Triangle. Wenn zwei Seiten aneinandergrenzen (nur die gegenüberliegende grenzt nich an) dann teilen sie sich genau zwei Vertices. Jeder Punkt zwischen diesen beiden Vertices gehört praktisch beiden Triangles und wenn jetzt erst das verdeckte Triangle gerendert wird, dann gibt es für das zweite Triangle für diese Pixel schon einen Wert im z-Buffer.

	PhillipK	Do, Okt 17, 2013 12:59 Antworten mit Zitat
Berufen wir uns mal auf diesen screenshot: Hier ist deutlich zu sehen, das die würfel ziemlich grade sind (haha). Damit meine ich von der kamera verzerrung - der tiefeneffekt bleibt aus. Das könnte das genannte problem - die würfel haben auch innenflächen - untermauern. in ausnahme fällen kann es passieren, das im depthbuffer durch die eigentlich unsichtbaren seitenfaces die selben werte gesetzt sind, wie von den frontwänden. Klar, alle faces werden gerendert, zumindest die, die richtung kamera zeigen. Bei einer solchen kamerarotation und der vermutung, das alle seiten des würfels existieren, sind das immer genau 1 face welches an der kante 2er blöcke liegt. Überschreibt dieses feld nun depthbuffer werte, weil es exakt auf der selben kante liegt wie das frontface, können die depthbufferwerte identisch sein und das frontface kriegt die pixelreihe nicht gerendert, da der depthbuffer sagt: "hier ist schon was, was näher an der kamera liegt oder gleichauf mit dir ist. Sorry" <Edit> hier mal eine kritzelei, wie das aussehen könnte: Wenn ich nicht vollkommen blöde bin.. müsste es etwa so aussehen. Die blöcke stellen die cubes dar, der kegel den kamera sichtbereich. Der fehler ist an dem punkt mit dem roten kreis makiert. Die seiten der würfel müssten - rein logisch betrachten - alle auf einen fluchtpunkt hinzeigen, um den tiefen effekt zu zeigen. Die linie mittig stellt den "nullpunkt" dar, wo absolut keine verzerrung auftritt. je weiter weg das ganze ist, desto mehr verzerrt es sich. Aber: Hier ist es übertrieben dargestellt. Worauf ich hinaus will: Im bild, roter bereich, seitenkante des linken würfels. Diese wird gerendert und überschreibt auf der exakten kanten beider würfel den depthbuffer mit einem wert, der der frontfläche des würfels rechts daneben entspricht. Dieser ist irgendwo weiter hinten in der renderreihenfolge und denkt, er dürfe da nicht rendern, weil der depthbuffer dies untersagt. Das der fehler nur bei bestimmten rotationen und scheinbar nur "links" vom fluchtpunkt auftritt lässt sich damit erklären, das die surfaces in einer gewissen reihenfolge gerendert werden. Auf der rechten seite hat dann vielleicht das frontface priorrität , erst danach wird die verzerrte seitenfläche gerendert, darf dies aber aufgrund des depthbuffers ebenfalls nicht </Edit> Das ist eine kleine erklärung für Kruemelator's ansatz Zitat: Zudem haben Triangles nur zwei Dimensionen, insofern haben die Seiten eines Würfels bei Frontalansicht keinerlei Ausdehnung. Ja und nein. Die ausdehnung ist extrem gering, aber die pixelreihe oben verrät mir, das dort eine vorhanden ist. Ebenso die flächen an der rechten seite! Nur weil es von vorne grade zu sein scheint, muss das nicht für die tiefe gelten. Und ja, die frontalansicht, nämlich dort wo garkeine faces zu kamera hinzeigen, ist korrekt. Aber daneben, wo ein teil der ausdehnung sichtbar sein könnte, ist der fehler - wieder eine untermauerung für die these. Anyways, das ganze beruht auf der annahme, das die würfel auch seitenflächen haben. Vielleicht sind es keine würfel, sondern zusammengebaute meshes? Dann liegt der hund woanders begraben

PhillipK

Do, Okt 17, 2013 12:59
Antworten mit Zitat

Berufen wir uns mal auf diesen screenshot:

user posted image

Hier ist deutlich zu sehen, das die würfel ziemlich grade sind (haha). Damit meine ich von der kamera verzerrung - der tiefeneffekt bleibt aus.

Das könnte das genannte problem - die würfel haben auch innenflächen - untermauern.

in ausnahme fällen kann es passieren, das im depthbuffer durch die eigentlich unsichtbaren seitenfaces die selben werte gesetzt sind, wie von den frontwänden.
Klar, alle faces werden gerendert, zumindest die, die richtung kamera zeigen. Bei einer solchen kamerarotation und der vermutung, das alle seiten des würfels existieren, sind das immer genau 1 face welches an der kante 2er blöcke liegt.
Überschreibt dieses feld nun depthbuffer werte, weil es exakt auf der selben kante liegt wie das frontface, können die depthbufferwerte identisch sein und das frontface kriegt die pixelreihe nicht gerendert, da der depthbuffer sagt: "hier ist schon was, was näher an der kamera liegt oder gleichauf mit dir ist. Sorry"

<Edit>
hier mal eine kritzelei, wie das aussehen könnte:
user posted image

Wenn ich nicht vollkommen blöde bin.. müsste es etwa so aussehen.
Die blöcke stellen die cubes dar, der kegel den kamera sichtbereich.
Der fehler ist an dem punkt mit dem roten kreis makiert.

Die seiten der würfel müssten - rein logisch betrachten - alle auf einen fluchtpunkt hinzeigen, um den tiefen effekt zu zeigen.
Die linie mittig stellt den "nullpunkt" dar, wo absolut keine verzerrung auftritt. je weiter weg das ganze ist, desto mehr verzerrt es sich. Aber: Hier ist es übertrieben dargestellt.

Worauf ich hinaus will:
Im bild, roter bereich, seitenkante des linken würfels. Diese wird gerendert und überschreibt auf der exakten kanten beider würfel den depthbuffer mit einem wert, der der frontfläche des würfels rechts daneben entspricht. Dieser ist irgendwo weiter hinten in der renderreihenfolge und denkt, er dürfe da nicht rendern, weil der depthbuffer dies untersagt.
Das der fehler nur bei bestimmten rotationen und scheinbar nur "links" vom fluchtpunkt auftritt lässt sich damit erklären, das die surfaces in einer gewissen reihenfolge gerendert werden.
Auf der rechten seite hat dann vielleicht das frontface priorrität , erst danach wird die verzerrte seitenfläche gerendert, darf dies aber aufgrund des depthbuffers ebenfalls nicht Smile

</Edit>

Das ist eine kleine erklärung für Kruemelator's ansatz Smile

Zitat:

Zudem haben Triangles nur zwei Dimensionen, insofern haben die Seiten eines Würfels bei Frontalansicht keinerlei Ausdehnung.

Ja und nein. Die ausdehnung ist extrem gering, aber die pixelreihe oben verrät mir, das dort eine vorhanden ist. Ebenso die flächen an der rechten seite!
Nur weil es von vorne grade zu sein scheint, muss das nicht für die tiefe gelten.
Und ja, die frontalansicht, nämlich dort wo garkeine faces zu kamera hinzeigen, ist korrekt.
Aber daneben, wo ein teil der ausdehnung sichtbar sein könnte, ist der fehler - wieder eine untermauerung für die these.

Anyways, das ganze beruht auf der annahme, das die würfel auch seitenflächen haben. Vielleicht sind es keine würfel, sondern zusammengebaute meshes? Dann liegt der hund woanders begraben Smile

	Mr.Floppy	Do, Okt 17, 2013 14:58 Antworten mit Zitat
Vielen Dank für die ausführliche Erklärung euch beiden! Von dieser Problematik hatte ich absolut keine Ahnung. Gibt es denn Möglichkeiten diese "Depth-Buffer-Ungenauigkeit" weitestgehend auszuschließen, ohne auf derlei Würfelobjekte verzichten zu müssen?

Mr.Floppy

Do, Okt 17, 2013 14:58
Antworten mit Zitat

Vielen Dank für die ausführliche Erklärung euch beiden! Von dieser Problematik hatte ich absolut keine Ahnung. Gibt es denn Möglichkeiten diese "Depth-Buffer-Ungenauigkeit" weitestgehend auszuschließen, ohne auf derlei Würfelobjekte verzichten zu müssen?

	Kruemelator	Do, Okt 17, 2013 15:22 Antworten mit Zitat
@Mr.Floppy: Nein, da selbst wenn du einen unendlichgenauen Depth-Buffer hättest gleich Z-Werte gleich bleiben. Man könnte eine unendlich große auflösung nehmen, dann würde man den Fehler nicht sehen, da der Fehler immer 1 Pixel breit ist (bei einer unendlichen Auflösung wäre ein Pixel dann unendlich klein ). In modenem DirectX würde Multisampling etwas helfen. In B3D ist einzige sinnvolle Idee im Mesh nur die Seiten zu haben die auch gesehen werden können. @PhillipK: Wenn dein Sichtbereich ein Dreieck ist(genaugenommen ist es ein Trapez, da es durch das Near-Plane abgeschnitten ist) dann ist gibt es keinen gemeinsamen Fluchtpunkt. Erst beim rendern wird dann das Near-Plane so breit und hoch scaliert das es so groß wie das Far-Plane ist. Dann wäre dein Sichtbereich Rechteckig und alles was nah ist ist größer und was fern ist ist kleiner. Dann hast du den Fluchtpunkt. Hier ein Beispielbild, rot ist der Sichtbereich und grün die Objekte in der Welt: http://www.cg.tuwien.ac.at/res...igure2.png

Kruemelator

Do, Okt 17, 2013 15:22
Antworten mit Zitat

@Mr.Floppy:
Nein, da selbst wenn du einen unendlichgenauen Depth-Buffer hättest gleich Z-Werte gleich bleiben.
Man könnte eine unendlich große auflösung nehmen, dann würde man den Fehler nicht sehen, da der Fehler immer 1 Pixel breit ist (bei einer unendlichen Auflösung wäre ein Pixel dann unendlich klein Very Happy

). In modenem DirectX würde Multisampling etwas helfen.
In B3D ist einzige sinnvolle Idee im Mesh nur die Seiten zu haben die auch gesehen werden können.

@PhillipK:
Wenn dein Sichtbereich ein Dreieck ist(genaugenommen ist es ein Trapez, da es durch das Near-Plane abgeschnitten ist) dann ist gibt es keinen gemeinsamen Fluchtpunkt. Erst beim rendern wird dann das Near-Plane so breit und hoch scaliert das es so groß wie das Far-Plane ist. Dann wäre dein Sichtbereich Rechteckig und alles was nah ist ist größer und was fern ist ist kleiner. Dann hast du den Fluchtpunkt.

Hier ein Beispielbild, rot ist der Sichtbereich und grün die Objekte in der Welt:
http://www.cg.tuwien.ac.at/res...igure2.png

	funkmaster5000	Do, Okt 17, 2013 15:31 Antworten mit Zitat
Danke Kruemelator! Gibt es eine Begrenzung, wie viele Würfel/Würfelseiten ich einem Mesh hinzufügen darf?

funkmaster5000

Do, Okt 17, 2013 15:31
Antworten mit Zitat

Danke Kruemelator!

Gibt es eine Begrenzung, wie viele Würfel/Würfelseiten ich einem Mesh hinzufügen darf?

	AnniXa	Do, Okt 17, 2013 15:37 Antworten mit Zitat
die begrenzung liegt eher bei den verticles. wenn du das klever machst und flächen die man nie sehen würde nicht hinzufügst geht da eine ganze menge. wenn ich mich nicht irre waren es ca. 32000 verticles bei blitz3d wenn du die grenze erreichst must du die map aufteilen in bereiche, minecraft z.b. macht das ja auch so, da heisen die dann immer chunks.
\|moonForge\| Ich bin Pokémon Meisterin seit 1998!

AnniXa

Do, Okt 17, 2013 15:37
Antworten mit Zitat

die begrenzung liegt eher bei den verticles.
wenn du das klever machst und flächen die man nie sehen würde nicht hinzufügst geht da eine ganze menge.

wenn ich mich nicht irre waren es ca. 32000 verticles bei blitz3d

wenn du die grenze erreichst must du die map aufteilen in bereiche, minecraft z.b. macht das ja auch so, da heisen die dann immer chunks.

|moonForge|
Ich bin Pokémon Meisterin seit 1998!

	PhillipK	Do, Okt 17, 2013 15:47 Antworten mit Zitat
@Kruemelnator: Ohje, mein gehirn Ja, die nearplane habe ich nicht eingezeichnet, weil ich die typischerweise so nah an die kamera setze (0.5, 1.0..), das sie praktisch nicht korrekt einzeichenbar wäre. Mein beispiel mag etwas ungenau / schwammig sein, aber ich denke das ich im groben die problematik erklärt habe, oder? :X @funkmaster5000: Ja es gibt eine begrenzung. Ob es eine fixe begrenzung in b3d an sich gibt, weiß ich nicht. Allerdings ist diese grenze von der hardware abhängig. 16.000 bis 32.000 Vertices sollten eigentlich kein problem darstellen und da man üblicherweise mit triangles arbeitet, sollten ~5400 bis 10800 triangles kein problem darstellen. Das sind über 2000 würfelseiten, also eine ganze menge. Das beste wird sein, wenn du eine meshes bündelweise zusammenbaust, zb 16x16x16 blöcke in einem mesh zusammenfasst. Der wert, 16, kann beliebig variert werden, ich verwende aus gewohnheit immer power of 2. (2^4, 2^5... ) Wovon ich abrate ist, meshes solange zusammenzuschrauben, bis sie diverse softcaps wie 16.000 vertices erreicht haben. Warum? Geschwindigkeit. Jedes mesh hat kanten im raum. Quasie ein quader der drumrum gestreckt ist. Ist nur eine dieser kanten im bild, dh im sichtbereich der kamera, kriegt das ding einen vollen renderaufruf. Wenn du halbwegs zusammenliegende würfel in meshes packst, ist das weniger daramatisch. Aber stell dir vor, du nimmst reihen von blöcken. zb 16^3 würfel wäre 4096 würfel. Das heißt, du hast 4096 würfel in einer reihe und von diesen reihen sind 20 im bild: 409620 würfle müssten gerendert werden, obwohl effekt nur 3030 im bild sind. Das ist overkill der übelsten sorte. Durch begrenzungen im raum, dh durch das zusammenfassen von paaren (161616 blöcke als beispiel) verminderst du also die ausmaße, die das ganze insgesamt hat. So wird überwiegend auch nur das gerendert, was effektiv zu sehen ist und nur wenig durchgetestet, was offscreen liegt.

PhillipK

Do, Okt 17, 2013 15:47
Antworten mit Zitat

@Kruemelnator: Ohje, mein gehirn Very Happy

Ja, die nearplane habe ich nicht eingezeichnet, weil ich die typischerweise so nah an die kamera setze (0.5, 1.0..), das sie praktisch nicht korrekt einzeichenbar wäre.
Mein beispiel mag etwas ungenau / schwammig sein, aber ich denke das ich im groben die problematik erklärt habe, oder? :X

@funkmaster5000:
Ja es gibt eine begrenzung. Ob es eine fixe begrenzung in b3d an sich gibt, weiß ich nicht. Allerdings ist diese grenze von der hardware abhängig.
16.000 bis 32.000 Vertices sollten eigentlich kein problem darstellen und da man üblicherweise mit triangles arbeitet, sollten ~5400 bis 10800 triangles kein problem darstellen. Das sind über 2000 würfelseiten, also eine ganze menge.
Das beste wird sein, wenn du eine meshes bündelweise zusammenbaust, zb 16x16x16 blöcke in einem mesh zusammenfasst. Der wert, 16, kann beliebig variert werden, ich verwende aus gewohnheit immer power of 2. (2^4, 2^5... )

Wovon ich abrate ist, meshes solange zusammenzuschrauben, bis sie diverse softcaps wie 16.000 vertices erreicht haben.

Warum?
Geschwindigkeit.
Jedes mesh hat kanten im raum. Quasie ein quader der drumrum gestreckt ist. Ist nur eine dieser kanten im bild, dh im sichtbereich der kamera, kriegt das ding einen vollen renderaufruf.
Wenn du halbwegs zusammenliegende würfel in meshes packst, ist das weniger daramatisch.
Aber stell dir vor, du nimmst reihen von blöcken. zb 16^3 würfel wäre 4096 würfel. Das heißt, du hast 4096 würfel in einer reihe und von diesen reihen sind 20 im bild: 4096*20 würfle müssten gerendert werden, obwohl effekt nur 30*30 im bild sind. Das ist overkill der übelsten sorte.
Durch begrenzungen im raum, dh durch das zusammenfassen von paaren (16*16*16 blöcke als beispiel) verminderst du also die ausmaße, die das ganze insgesamt hat. So wird überwiegend auch nur das gerendert, was effektiv zu sehen ist und nur wenig durchgetestet, was offscreen liegt.

Gehe zu Seite 1, 2 Weiter

Übersicht

BlitzBasic

Blitz3D

Nach Oben

BlitzBasic Portal

Camera schaut durch Cube

Betreff: Camera schaut durch Cube