Direct3D optimierte 3D-Modell Erstellung

[SilconDanny]

Hallo, ich hab folgende Frage zur erstellung eines einfachen Tisches,
bestehend aus einer Tischplatte und 4 rechteckigen Tischbeinen.

Im 3D-Modeller "Milkshape 3D" (oder anderen Programmen) kann ich einen einfachen Tisch
auf mindestens 2 verschiedenen Arten erstellen:

1.Schnell & einfach, indem die 4 Tischbeine einfach unter der Tischplatte platziert werden.
Nachteil:
Über die oberen offenen Enden der Tischbeine liegt eine Textur (von der Tischplattenunterseite),
die an den Tischbeinstellen nicht sichtbar ist (und auch nicht sein soll).

2.Die 4 Tischbeine unter der Tischplatte platzieren,
und bei den Tischbeinstellen Aussparungen (4 eckige "Löcher") an der unterseite der Tischplatte reinmachen.

Ich frage mich nun, welche der beiden Möglichkeiten ist für das schnelle & optisch Mangelfreie Rendern
mit Direct3D (DirectX 9.0c) die bessere?


Folgende Anhaltspunkte kann ich vorab schon geben:

Anhand meiner wenigen stichprobenartig rausgesuchten (und konvertierten) 3D-Modellen
von (schon etwas älteren) Spielen fiel mir folgendes auf:

-In Deus Ex 1 & Gothic 2 wurde für Tische die 1.Möglichkeit verwendet
-In Half Live 1 wurde für ein Pistolen 3D Modell jedoch die 2.Möglichkeit verwendet. Gleiches auch bei einen anderen 3D-Modell.

Ich persöhnlich würde eher die 2.Möglichkeit wählen, obwohl sie schwieriger & aufwendiger zu modellieren ist,
und mehr Vertices braucht. Da ich denke, daß sie Renderfreundlicher ist (obwohl mehr Vertices & Indices zur Grafikarte geschickt werden).

Wäre es denn beim Rendern nachteilig, die 1.Möglichkeit zu nutzen,
oder sorgt z.B. der Z-Buffer für die Entfernung der rechteckigen Texturbereiche über den 4 Tischbeinen?
Welche Nachteile gebe es sonst noch?


Vielen Dank für gut passende Vermutungen, kompetente Antworten, oder Extra-Infos.

P.s.: Wer Interesse hat, kann mein Egoshooter & Pacman ähnliches Spiel "Ghost World 3D v0.93" spielen usw.
Es ist mein 1. selbstprogrammiertes & weitgehend verbessertes 3D-Spiel & Freeware.
Infos & Download: GhostWorld3D.beepworld.de

[Krishty]

Willkommen!

Z Buffering sorgt dafür, dass nahe Pixel ferne Pixel überschreiben dürfen, aber nicht umgekehrt. Ob es die Teilflächen "entfernt" hängt also davon ab, in welcher Reihenfolge die Dreiecke zur Grafikkarte gesendet werden – falls erst die Tischplatte gezeichnet wird, landet sie komplett auf dem Bildschirm, aber die Tischbeinpixel überschreiben die vier Teilflächen später. Falls jedoch erst die Tischbeine gezeichnet werden, werden die Teilflächen der Tischplatte erst garnicht gezeichnet, weil sich dort bereits die näheren Pixel der Tischbeine befinden. Daraus eine erste Faustregel: Wenn man die Wahl hat, ob man von nah zu fern zeichnet oder umgekehrt, sollte man sich für nah-zu-fern entscheiden, weil dann möglichst wenige Pixel mehrfach gezeichnet werden (wenig Overdraw). Ausnahme ist z.B. Transparenz (aber das weicht jetzt ab).

So viel zu Z Buffering.

Jetzt zur Frage mit den Vertices. Es gilt: je weniger Vertices, desto besser. Aber es gilt auch: je weniger Pixel, desto besser. Du hast da einen Fall gefunden, in dem das direkt in Konflikt steht, und da kommt es auf die Situation an. Bremsen Vertices deine Engine aus (weil sehr komplexe Vertex Shader im Spiel sind, aber sehr einfache Pixel Shader), solltest du die Vertex-Nutzung minimieren. Bremst jedoch die Pixel-Füllrate deine Engine aus (weil sehr komplexe Pixelbeleuchtungen im Spiel sind, aber einfache Vertex-Transformationen), solltest du die Pixelzahl minimieren. Das tust du durch die vier Aussparungen. Da aber Z-Buffering im Spiel ist, kannst du das ebenso durch die Reihenfolge der Dreiecke tun, wie ganz oben erwähnt! Und falls die Reihenfolge günstig ist, geht diese gut gemeinte Optimierung halt nach hinten los. Und um die Sache noch zu verkomplizieren: GPUs berechnen nicht jeden Pixel einzeln, sondern ausschließlich in 2×2-Blöcken. Das bewirkt Verschnitt an den Kanten, also mehr Pixel, obwohl die Summe der Flächen mathematisch gleich groß bleibt[1]!

Verwirrt genug? Es kommt also auf den Einzelfall an. Oder auch nicht, denn:

Bei Tischen macht das auf modernen GPUs keinen messbaren Unterschied. Bei komplexen Modellen höchstens minimal. Beim Zeichnen von tausend Bäumen oder Gräsern oder Partikeln[2] wird es bemerkbar, aber das hat man äußerst selten. Es spielt also eigentlich keine Rolle für dich, so lange wir hier nicht über Millionen Dreiecke auf dem Bildschirm gleichzeitig reden.

Du solltest also tun, womit du beim Modellieren am schnellsten fertig wirst. Und das ist eindeutig Methode 1.

[1] Humus, Wednesday, January 14, 2009 – Triangulation
[2] Humus, Thursday, May 21, 2009 – New Particle Trimming Tool

[SilconDanny]

Antwort vom 20.10.2015: Erstmal danke für die ausführliche Antwort. Ich werde sie mir nochmal genauer durchlesen.

Antwort vom 22.10.2015:
Danke :-) und danke für die genauere und gute Z-Buffer usw Erklärung & den vielen Text - er enthält einige Antworten.
Ist es so, daß der Z-Buffer nicht nur die Pixelentfernung in Z-Richtung, sondern auch in X- & Y-Richtung berücksichtigt? In meinen Büchern war darüber nichts zu lesen.

Beim ersten lesen Deiner Antwort wars auch wegen meiner Müdigkeit an dem Abend teilweise schon verwirrend.
Aber heute wurde mir einiges klarer (Über Vertex- & Pixelshader hab ich nur mal gelesen, aber bisher noch nicht mit programmiert. Trotzdem hab ich das meiste von Dir verstanden).

Es wäre schon einfacher & schneller für mich, Methode 1 zu verwenden,
aber wenn es sich für meine Ansprüche usw lohnt, verwende ich auch gern die (etwas) aufwändigere Methode 2 (und zusätzlich bereits fertiggestellte 3D-Modelle anderer 3D-Modeller)
Und in einen meiner nächsten Spiele werden auch mehr als max. ca. 13 000 Vertices vorkommen, usw.

[Schrompf]

Krishty hat bereits schön die Grundlagen aufgelistet. Bei einem Tisch ist es wirklich egal, außer Du renderst davon wirklich tausende in jedem Frame. Falls Du aber komplexe Algorithmen darauf anwenden willst wie z.B. Occlusion-Vorberechnungen, haben die zumeist Probleme mit einander kreuzenden Flächen oder nicht wasserdichten Modellen. Dafür wäre also Methode 2 besser.

[SilconDanny]

Krishty hat bereits schön die Grundlagen aufgelistet. Bei einem Tisch ist es wirklich egal, außer Du renderst davon wirklich tausende in jedem Frame. Falls Du aber komplexe Algorithmen darauf anwenden willst wie z.B. Occlusion-Vorberechnungen, haben die zumeist Probleme mit einander kreuzenden Flächen oder nicht wasserdichten Modellen. Dafür wäre also Methode 2 besser.

Danke für die Antwort, :-) Deine letzten 2 Sätze sagen mir, daß es besser ist vorbeugend Methode 2 zu verwenden, um zukünftigen Problemen vorzubeugen (falls ich mal Occlusion Culling verwende).

[Schrompf]

Nene, Missverständnis. Also ja, Du kannst vorbeugend Methode 2 nutzen. Aber nein, mit Occlusion Culling hat das nix zu tun. Ich meinte mehr so Ambient Occlusion, also die Menge an diffusem Schatten, die das Objekt auf sich selbst wirft.

[Tiles]

Ich würde mir da keinen grossen Kopf machen und einfach Methode 2 nehmen. Vom Aufwand nimmt sich das bei einem einfachen Tisch fast nix. Und du umgehst so alle Pitfalls wie Clipping, Z Fighting oder Schattenartefakte. Methode 1 kann man zwar machen, aber da musst du halt wissen was du tust. Das ist schwer Situationsabhänging. Bei Methode 2 kannst du hingegen nix falsch machen :)

[SilconDanny]

Hallo Tiles, vielen Dank für Deine Antwort, Deine Zeit, und vielen, vielen Dank für einige Inhalte von www.ReinersTilesets.de.
Auch Deine Antwort machte mir etwas klarer, warum Methode 2 bei meiner Vorgehensweise optimaler wäre.

Der Tisch wäre ja auch nur ein wichtiges Beispiel zum Anfang, denn Antworten für den Tisch würden auch gleiche bzw ähnliche Problemstellungen beantworten:
-Bilder & Plakate an Wänden (Dahinter ohne oder mit Wandvertices "rendern"?)
-Säulen unter einer Decke
-Stege unter einen Botssteg
-Sehr viele Kirchenbänke in einer großen Kirche auf dem Fußboden (Bodenvertices unter Kirchenbank), und vielleicht noch vieles mehr

Ich kenne zwar das Z Fighting, aber ich kann mir nicht erklären, warum es bei Methode 1 & der Tisch/Tischbein-Problematik auftreten sollte.
Bei einen zu dicht an der Wand befindlichen Plakat (mit Wandvertices dahinter) wäre es mir jedoch klar.
Auch beim Clipping kann ich es mir nicht genauer erklären. Beim Schattenwurf hab ich bisher nur mal die Schattenart programmiertechnisch ausprobiert,
die mittels einer "Schatten-/Shadow-Matrix" je einen Schatten von einen 3D-Modell auf eine Fläche (Plane) wirft.
Wie würde sich Methode 1 beim Clipping oder Schattenwurf u.U. negativ bemerkbar machen?

Gibts noch weitere Pitfalls bzw Render-Vorteile oder wegfallende Rendernachteile bei Methode 2?

Denn ich möchte die 3D-Modelle, die ich erstelle, für Direct3D usw optimal erstellen.

[SilconDanny]

Nene, Missverständnis. Also ja, Du kannst vorbeugend Methode 2 nutzen. Aber nein, mit Occlusion Culling hat das nix zu tun. Ich meinte mehr so Ambient Occlusion, also die Menge an diffusem Schatten, die das Objekt auf sich selbst wirft.

Ok, danke. Auch dafür wäre es wichtig, falls ich mal Ambient Occlusion verwenden sollte.

[SilconDanny]

Ich würde mir da keinen grossen Kopf machen und einfach Methode 2 nehmen. Vom Aufwand nimmt sich das bei einem einfachen Tisch fast nix. Und du umgehst so alle Pitfalls wie Clipping, Z Fighting oder Schattenartefakte. Methode 1 kann man zwar machen, aber da musst du halt wissen was du tust. Das ist schwer Situationsabhänging. Bei Methode 2 kannst du hingegen nix falsch machen :)

Meine Antwort siehe etwas weiter oben, wg. Flüchtigkeitsfehler.

[Zudomon]

Vor über einem Jahrzehnt hab ich mir auch mal diese Frage stellt. Methode 1, für mich ganz klar die bessere Wahl.
Methode 2 war mal relevant, als die Level im letzten Jahrtausend noch BSP optimiert waren.
Würde es beim Stencil Schatten einen Unterschied machen? Ich glaube selbst da nicht.
Von dem Renderspeed her glaube ich auch nicht, dass da großer Overhead drin ist, wenn du nicht meterlange PixelShader verwendest und wenn es Deferred Rendering ist, sollte es noch weniger ins Gewicht fallen.

Anders Methode 2. Auch wenn ich sonst immer relativ freizügig mit der Dreiecksanzahl umgehe, halte ich die hier für reine Verschwendung. Nehmen wir die Unterseite der Tischplatte mit den vier Beinen als Beispiel. Tischbeine nicht direkt am Rand. Methode 1 kommt mit 2 Dreiecken aus. Methode 2 mit 26 Dreiecken, wenn ich mich nicht verzählt habe.

Wie man sieht entstehen dabei sehr unschöne langgestrecke Dreiecke, die sehr ungeeignet für Octrees sind im Gegensatz zu kleineren, gleich verteilten Dreiecken. Dazu kommt, dass Vertex AO da wohl grausigst bei aussehen würde. Außerdem ist tesselieren hier wohl auch sehr unschön.
Also optimiert ist anders. Hinzu kommt, dass du Sonderfälle optimierst. Denn ein Tisch ist noch recht einfach von der Geometrie her. Aber was ist, wenn der uneben ist, gekrümmt oder sonst was? Außerdem wenn du den Tisch optimierst, solltest du auch den Boden, auf dem der Steht, optimieren. Dadurch müsstest du dann aber deine Welt an die Objekte anpassen und es wäre natürlich nicht mehr dynamisch. Wenn du dann den Tisch verschiebst, hättest ja die Löcher im Boden, tja.

(Sorry für die nicht mehr zeitgemäße Grafik, März 2007 ;) )

In dem Bild kann man übrigens erahnen, wie viel Overdraw man letztendlich spart... nämlich gar nichts, weil alles durch Backface Culling raus fällt (zumindest bei den Unterseiten der Tischplatten).

Beim Schattenwurf mit Shadowmaps denke ich auch, dass Methode 2 langsamer ist, wenn auch wohl nicht messbar. Eben weil es mehr Dreiecke werden. Und ich glaube Krishty hatte auch schon die 2x2 Pixel Problematik angesprochen. Da erinnere ich mich auch noch an irgendwas, sicher kennt das jemand wenn ich es jetzt erwähne. Da wurde gezeigt, dass die Dreiecksverteilung schon eine, wenn auch kleine, Rolle spielt. Z.B. bei dem Deckel eines Zylinders ist es langsamer, wenn die Dreiecke alle Strahlenförmig von einem Vertex ausgehen, statt erstmal das Größtmöglichste zu erstellen und dann den Rest durch kleinere Dreiecke abzudecken.
EDIT: Tja, wenn man dann hochscrollt und bei Krishtys Post mal Spasseshalber auf die Quellen klickt, sieht man auch genau den Link den ich meinte :lol: doppelt hält besser! :D

Also alles in allem glaube ich, du hättest einen größeren Optimierungseffekt wenn du alle Objekte in ein VS packst und State Changes rausoptimierst. Optimieren des Objektes durch die vorhandenen DX Funktionen um den VertexCache besser zu nutzen sind natürlich auch sinnvoll. Aber mithilfe von CSG da was zu optimieren halte ich heut zu tage für überflüssig und nur in Ausnahmefällen überhaupt für relevant. Ein dagegen sinnvoller Case kommt mir da z.B. bei einem Terrain + Waterplane in den Sinn. Da sollte man vielleicht das Waterplane auch in kleinere Dreiecke zerteilen und dann da, wo Berge aus dem Wasser ragen direkt die Dreiecke löschen (nicht unbedingt mit dem Terrain schneiden, aufwand/nutzen lohnt sich da wohl kaum). Der Case wäre für mich ne Ausnahme, denn ein Terrain besteht ja überwiegend über Wasser und da würde dann das Wasser mit einem Fullscreenoverdraw (wenn man runter schaut) zu buche schlagen.

[Tiles]

Ich kenne zwar das Z Fighting, aber ich kann mir nicht erklären, warum es bei Methode 1 & der Tisch/Tischbein-Problematik auftreten sollte.

Das war mehr allgemein gemeint :)

Konkret am Tisch: das kann zu flackern am Übergang zwischen Tischbein und Tischplatte führen. Nun schaut man ja aber seltenst unter den Tisch. Sondern allermeistens von oben drauf. Ausser man kann ihn umschmeissen. Womit wir wieder beim Verwendungszweck wären ...

[Krishty]

Aber dann müsste man schon sehr weit vom Tisch weg sein, oder die Z-Einstellungen *extrem* am Limit sein, oder?

[Tiles]

Also ich hatte dieses unschöne Flackern auch schon im Normalbereich. Wobei Normalbereich relativ ist. Wenn du den Tisch umkippen kannst kannst du mit deiner Kamera mit grösster Wahrscheinlichkeit auch wirklich nah ran.^^

[Krishty]

Aber je näher man dran ist, desto genauer wird Z Buffering … bei Postern an der Wand kann ich es mir ja vorstellen, aber in solchen Fällen muss IMO technisch wirklich was schieflaufen, bis das auftaucht.

[Schrompf]

Dann denk Dir Shadow Mapping. Da ist die Auflösung viel geringer und das Kantenflackern amtlich.

[Tiles]

Aber je näher man dran ist, desto genauer wird Z Buffering …

Und je näher du dran bist um so mehr fallen dir die kleinen Unregelmässigkeiten auf ^^

[Krishty]

Aber je näher man dran ist, desto genauer wird Z Buffering …

Und je näher du dran bist um so mehr fallen dir die kleinen Unregelmässigkeiten auf ^^

Welche?

Dann denk Dir Shadow Mapping. Da ist die Auflösung viel geringer und das Kantenflackern amtlich.

Kannst du mir zeigen, was du damit meinst? Ich kapier’s irgendwie nicht.

[Zudomon]

Wenn es wegen dem Z-Buffer flackert, wird er einfach falsch verwendet. Bei mir flackert da nichts. Es kommt auf die Near- und Far-Plane an. Allerdings kann man nicht jeden belieben Bereich verwenden. Ich benutze bei SQ 0.1 - 10000. Und die Grashalme haben kein Z-Fighting, obwohl die dicht beieinander sind.
Bei den Shadowmaps, wo ich nur 16 Bit verwende, habe ich auch kein Problem. Allerdings speichere hier auch den Abstand zur Kamera linear und nur in einem Bereich von -400 - 400 um das Zentrum. Hab da auch keine Probleme aufgrund des Wertebereichs.

Wie schon erwähnt, Wand mit Poster oder Fälle sind problematisch fürs Z-Fighting, bei den meisten anderen Sachen kann man wohl von ausgehen, dass der Wertebereich nicht optimal gewählt ist. Und ja, im Vorderen Bereich ist der Z-Buffer ja detaillierter. Also wenn der Tisch so weit weg ist, dass da Z-Fighting entsteht, sollte der schon so klein sein, dass man nichts mehr davon erkennt.

Im moment etwas brachial, aber zum demonstrieren reichts:

Der Tisch

Im Wireframe, da die Tischbeine abgerundet sind, stecken sie ziemlich mittig in der Tischplatte.

Selbst von einigem Abstand ist kein Z-Fighting zu sehen

Und auch wenn man noch weiter weg geht. Allerdings ist da das Mipmapping dann auch schon so stark, dass wohl Z-Fighting hier gar nicht mehr auffallen sollte, selbst wenn es auftritt.

[Tiles]

Machen wir es mal provoziert extrem, damit es offensichtlich wird um was es geht: Mein Lieblingssaurier trueSpace lässt sich da am leichtesten zu überreden. Das Ding hat ne alte DX 9 Realtime Engine drin. Optimiert ist da dran gar nix ^^

Standardcube 2 Meter. Der Pfosten in der Mitte ist Teil des Würfels. Der Pfosten links davon ist lose. Beim festen Pfosten ist alles einigermassen gut. Wie du siehst sieht es aber danach aus als ob der lose Pfosten oben rechts und unten links unterschiedlich weit drinsteckt. Die roten Pfeile. Ist aber jeweils der gleiche Würfel. Und wenn du dich dann noch bewegst ploppt das hin und her. Weil die Floats gar nicht präzise genug sein können um da immer die gleichen Werte zu liefern. Das fightet dann eben so vor sich hin.

Klar bin ich hier in den Grenzgebieten unterwegs. Und ich habe das natürlich extrem provoziert indem ich die Geometrie weit vom Mittelpunkt gesetzt habe. Und mit der Kamera ordentlich reingezoomt bin. Was den Effekt verstärkt. So stark ist der Effekt natürlich selten zu sehen. Aber schon leichte Unterschiede können eben zu einem Flackern bei Bewegung führen. Und das kannst du dann auch schon bei optimalen Einstellungen sehen. Den Effekt habe ich definitiv auch schon in Unity so gesehen.

[Zudomon]

Machen wir es mal provoziert extrem, damit es offensichtlich wird um was es geht: Mein Lieblingssaurier trueSpace lässt sich da am leichtesten zu überreden. Das Ding hat ne alte DX 9 Realtime Engine drin. Optimiert ist da dran gar nix ^^

Standardcube 2 Meter. Der linke Pfosten ist Teil des Würfels. Der Rechte ist lose. Beim festen Pfosten ist alles einigermassen gut. Wie du siehst sieht es aber danach aus als ob der lose Pfosten oben rechts und unten links unterschiedlich weit drinsteckt. Ist aber jeweils der gleiche Würfel. Und wenn du dich dann noch bewegst ploppt das hin und her. Weil die Floats gar nicht präzise genug sein können um da immer die gleichen Werte zu liefern. Das fightet dann eben so vor sich hin.

Klar bin ich hier in den Grenzgebieten unterwegs. Und ich habe das natürlich extrem provoziert indem ich die Geometrie weit vom Mittelpunkt gesetzt habe. Und mit der Kamera ordentlich reingezoomt bin. Was den Effekt verstärkt. So stark ist der Effekt natürlich selten zu sehen. Aber schon leichte Unterschiede können eben zu einem Flackern bei Bewegung führen. Und das kannst du dann auch schon bei optimalen Einstellungen sehen. Den Effekt habe ich definitiv auch schon in Unity so gesehen.

Sorry, aber das absoluter Quatsch und kommt nur zustande, wenn man man anfängt, Werte so ins schlechte zu verändern, dass die grenzen der Technik sichtbar werden.

Hier steckt auch alles ineinander und es flakert nichts! Und es ist immer noch das Near- / Far-Plane von 0.1 - 10000.

[Tiles]

Sorry, aber das absoluter Quatsch und kommt nur zustande, wenn man man anfängt, Werte so ins schlechte zu verändern, dass die grenzen der Technik sichtbar werden.

Quatsch? Mit Beweisfoto? Sei in Ordnung :lol:

Noch mal, ich habe den Effekt auch schon in Unity gesehen. Bei meinem eigenen Game. Ich sagte doch ich habe es in dem Shot extra extrem gemacht damit man den Effekt deutlich sieht, und damit wir wissen über was wir hier reden. Die Grenzen der Technik sind die Floats. Und die können dir auch schon unter normalen Umständen ins Gesicht springen. Da ist kein Quatsch dabei. Sondern ganz normale Mathematik.

Ich habe zum Beispiel in meinem Alister einen Weidezaun drin. Da sind die Balken auch nur gesteckt, das war mir zu viel Akt da nachzuarbeiten und das zu einer geschlossenen Geometrie zu machen. Da flackert es ab und zu ganz leicht unter bestimmten Umständen. Aber das sieht man auch nur wenn man weiss worauf man achten muss.

Bei Gras bleibt dir natürlich nichts anderes übrig. Billboards kannst du schlecht mit dem Untergrund zu einer geschlossenen Geometrie machen. Schon gar nicht wenn die sich auch noch drehen sollen. Und normalerweise sieht man da auch nicht wirklich was vom Z Fighting. Weil der Winkel da viel zu flach ist um sichtbar zu poppen. Die Ungenauigkeiten die da entstehen sind viel zu gering um zu sichtbarem Flackern zu führen.

Und unter Umständen ist auf anderen Sachen auch noch ein spezieller Shader drauf der das Ganze zehn Meter über dem Grund rendert damit da erst gar nichts fighten kann. So einen Shader verwendet zum Beispiel das Easyroads System für Unity für seine Strassen. Damit die nicht in der Ferne im Grund versinken ( fighten tat da dann zwar nix mehr, aber der Projektorschatten mochte damit auch nicht mehr Und so manch Grasbüschel verschwand unter der Strasse, hehe) . Deswegen sagte ich ja schon weiter oben, das kommt immer schwer auf die Situation an. Mit loser Geometrie musst du eben wissen was du tust.

Jedenfalls, Geometrie die ich geschlossen modeln kann modele ich in der Regel auch geschlossen. Um genau diese Probleme gleich von vornherein zu umgehen. Denn was du da an Optimierung bezüglich Geometrie rausholen kannst ist in der Regel vernachlässigbar. Erfahrungswerte eben.

Aber letztenendes ist eh erlaubt was funktioniert. Und wenn es bei dir funktioniert, prima :)

[Krishty]

Warum genau geht in deinem Beispiel das Tischbein in die Platte hinein statt es nur zu berühren?

[Tiles]

Um den Effekt deutlich zu zeigen. Die Grundplane des Würfels ist ja in beide Richtungen ungenau. Das würde auch flackern wenn der Pfosten mit der Fläche abschliessen würde. Wie man unten links sieht wird der Pfosten fast verdeckt.

[Zudomon]

Ja, aber da sind dann schon so krass die Werte verbogen. Wenn du in deiner Engine oder eben Unity, die Near- und Far-Plane nicht richtig verwendet, dann kann der Z-Buffer und die Float Zahlen da nichts für. Und ja, du hast ein Beweisfoto, wie man es nicht machen sollte. Ich ein Beweisfoto, dass es selbst bei kleinste Geometrie, wenn man über den Boden kriecht keine Probleme geben muss, wenn man es vernünftig macht.

Erfahrungswerte eben.

Eigentlich will ich nur darauf hinaus, dass es im Endeffekt egal ist, was man macht. Methode zwei aber eher aufwendiger und überhaupt nur in Sonderfälle umsetzbar ist. Wenn man ohne Probleme die Möglichkeit hat saubere Geometrie zu bekommen, ist da gar nichts gegen einzuwenden. Denn zusammengesteckt ist halt irgendwie gefuscht. Aber in dem Fall des Tisches ist mir, nachdem ich jetzt auch drüber nachgedacht habe, lieber die Möglichkeit, beim tesellieren die Dreiecke vernünftig zu verteilen, als da so komische Dreieckshaufen raus zu bekommen. Übrigens mein Drache besteht auch aus "einem Guss"... da überschneidet sich dann nur was, wenn sich das Ding bewegt.

[Tiles]

Ja sicher hab ich das krass verbogen. Sonst sieht man das ja nicht so doll. War ja ein Beispiel um zu zeigen dass es überhaupt passiert, und um zu zeigen was genau passiert :)

Das mit dem Z Fighting wie in dem Beispiel passiert eigentlich immer. Das hat nichts mit verbogenen Werten zu tun. Das sind einfach Floatingpointungenauigkeiten. Aber in der Regel passieren die eben auf so mikroskopisch kleiner Ebene dass du davon nichts siehst.

Nur gibt es eben Situationen wo das dann doch sichtbar wird. Und das auch im Normalbetrieb. Mein Weidezaun steht eben nicht in einem Extrembereich. Und ich habe da in meinem Spiel auch einen normalen Clippingbereich wie du. Ist glaube ich das Unity Standard 0.3/1000 Clipping.

Eigentlich will ich nur darauf hinaus, dass es im Endeffekt egal ist, was man macht. Methode zwei aber eher aufwendiger und überhaupt nur in Sonderfälle umsetzbar ist.

Eigentlich ist Version 2 die Regel, die geschlossene Geometrie. Und die getrennte Geometrie der Sonderfall. Denn es ist eben nicht egal was man macht. Das kommt echt auf die Situation an :)

Es gibt da neben dem Z Fighting auch noch ein paar andere Gründe lieber geschlossen und aus einem Stück zu bauen. Shadowmapping wurde ja schon genannt.

[Zudomon]

Aber in der Regel passieren die eben auf so mikroskopisch kleiner Ebene dass du davon nichts siehst.

Das ist mir schon klar. Aber ob jetzt ein Pixel mal wo anders hin fällt als er vielleicht sollte, ist ziemlich unerheblich, wenn man nicht gerade Krishtys Sternenhimmel nach bauen möchte.

Wenn du DEIN Tisch Beispiel mal so baust, wie Krishty es sagt, also dass dein Tischbein nicht durch die Platte ragt, sondern bündig mit abschließt, dann sollte es auch nicht so "extrem" zu sehen sein.
Zumindest auch nicht weniger, als bei dem anderen Bein, welches mit der Tischplatte verbunden ist. Ich frage mich sowieso, warum das da relativ Artefaktfrei ist, denn da sind die Flächen genauso überlagert. Der einzige Unterschied ist ja vom sichtbaren her (oder eben nicht sichtbar, weil es ja versteckt ist), das ein kleines Quadrat noch hinzu gerendert wird.

Eigentlich ist Version 2 die Regel, die geschlossene Geometrie. Und die getrennte Geometrie der Sonderfall.

Die Regel? Hmm... das mag auf die Standardgrundkörper zutreffen. Aber bei Planes versagt die Regel, weil diese keine Ausdehnung haben. Sind die nun geschlossen oder nicht? Und wenn man aus diesen Grundkörpern neue Objekte zusammen baut, dann sind diese auch getrennt... man kann sie gruppieren, damit sie als ganzes auftreten, aber sie entsprechen topologisch betrachtet immer noch getrennten Objekten. Erst wenn du sie per CSG zusammen fügst, kannst du deinen Regelfall erzeugen. Aber dann verschiebst du das ganze halt nur eine Ebene höher. Denn wenn du aus den Objekten ein Level zusammen baust, dann handelt es sich hier wieder um getrennte Geometrie. Außer du machst es eben wie in den alten ID-Engines oder Unreal, dass du ALLES zusammen merged zu einem geschlossenen Objekt. Ich habe ja damals viel mit Unreal 1 gebaut. Und kann daher sagen, dass diese CSG-Zeug bei einfachen Objekten ganz gut ist. Aber wenn das Level dann nicht mehr aus axis aligned boxen besteht, sondern mehr Details vor allem mit runden Oberflächen hinzu kommen, dann explodiert irgendwann die Polygonzahl.
Ich glaube, bei Doom 3 wurde ja dann auch nicht mehr CSG verwendet, um die Einzelobjekte zu verbinden.

Shadowmapping wurde ja schon genannt.

Also ich würde mal behaupten, gerade beim Shadow Mapping ist es egal, ob die Objekte geschlossen sind oder nicht. Oder verwechselt ihr das mit Stencil?
Vorteile von geschlossener Geometrie hätte man bei Operatoren die darauf arbeiten, wie z.B. Subdivides. Ansonsten noch bei organischen Sachen. Zum einen, weil eine geschlossene Oberfläche hier besser zur Geltung kommt, durch die gemeinsamen Normalen und der Texturfilterung an der Kante, zum anderen eventuell noch bei Skelett-Vertex-Weighting. Vielleicht bringt es noch Vorteile bei Transparenz-Geschichten oder andere Techniken, vielleicht Peeling, aber da kenn ich mich nicht aus. Und Stencil wird wohl keiner mehr machen. Wobei, worüber reden wir hier eigentlich? Dem Sencil ist es sogar egal, ob die Tischbeine nun extra Objekte sind oder nicht... weil die Grundkörper, aus denen der Tisch besteht, immer noch geschlossen sind...

[Tiles]

Wenn du DEIN Tisch Beispiel mal so baust, wie Krishty es sagt, also dass dein Tischbein nicht durch die Platte ragt, sondern bündig mit abschließt, dann sollte es auch nicht so "extrem" zu sehen sein. Zumindest auch nicht weniger, als bei dem anderen Bein, welches mit der Tischplatte verbunden ist.

Du meinst so wie im Anhang? :P

Ich habe doch gesagt das ist genau der gleiche Effekt, und dass der nach beiden Seiten ausschlägt. Du bist echt schwer zu überzeugen ^^

Ich frage mich sowieso, warum das da relativ Artefaktfrei ist, denn da sind die Flächen genauso überlagert.

Mathemagie. Wir betrachten hier eine schräge Fläche. Und je nach Floatingpoint Error wandern die Texel der Fläche mal ein wenig nach oben mal ein wenig nach unten. Oder besser gesagt vor und zurück. Mein loses Tischbein wird nun mal mehr oder mal weniger überdeckt. Weil es eben beim Berechnen der Geometrie erst mal nicht mitberechnet wird. Der wird erst mit dem nächsten Berechungsschritt der Geometrie reingerechnet. Selbst wenn der lose Pfosten mit dem Objekt gemerged ist. Und bekommt da einen anderen Floatingpoint Error mit als für die Hauptgeometrie. Die zwei Dinger haben nie die gleiche Position. Und dann flackerts eben bei Bewegung.

Der fest verbundene Pfosten hingegen ist Teil der Geometrie. Und wird gleich beim ersten Zusammenrechnen mitberechnet. Der bekommt den gleichen Floatingpoint Error mit wie der Rest der Geometrie. Und der Pfosten wird da dargestellt wo er hingehört. Klar dass es da nicht so doll flackert.

Kann natürlich auch sein dass ich hier kompletten Stuss über die Ursache erzähle. Ich bin kein Mathematiker. Und die Engine Internas sind mir aus Grafikersicht eigentlich egal. Was aber eigentlich keine Rolle spielt, denn dass es passiert dürfte wohl nun hoffentlich unstrittig sein. Wichtig ist darum zu wissen, und vor allem zu wissen wie man den Effekt vermeidet wenn er denn störend auftritt.

Zum Rest, ich sage doch es kommt auf den Einzelfall an. Da gibts keine Regel. Nur dass man mit geschlossener Geometrie für so Sachen wie einen Tisch mit Tischbeinen ein paar Vorteile hat die man auch nutzen sollte, weswegen es eher die Regel ist. Zfighting haben wir hier ja nun im Detail auseinanderklabüsert. Das ist einfach da. Kann stören, muss nicht.

Mit Lightmapping kannst du bei deinem Tisch mit geschlossener Geometrie ein paar Texel einsparen. Das kann die Performance erhöhen. Das kann, wenn es viele solcher verdeckter Flächen gibt auch gehörig Texturspace und Lightmapspace einsparen. Da sind die paar Extra Vertices unerheblich. Und das Lightmapping um den Pfosten herum ist sehr viel genauer durch das Unterteilen in mehr Flächen.

Bei Realtime Shadow kann es unter Umständen ein Flackern geben. Auch wieder durch die Floatingpoint Errors, und die unterschiedliche Berechnung. Auch da: Kann stören, muss nicht.

Letztenendes ist erlaubt was funktioniert :)

[Krishty]

Sehr interessant. Wer kann das erklären? Cat? eXile?

[Zudomon]

Sehr interessant. Wer kann das erklären? Cat? eXile?

Also ich jedenfalls nicht. Von meinem Verständnis her sollte das nicht sein. Ach nein, moment, doch... an das Phänomen erinnere ich mich...
Nun hab ich aber eine Vermutung.

Probier das Beispiel nochmal aus und unterteile die die Oberseite der Fläche erstmal gleichmäßig in z.B. 32 x 32 Segmente... verbinde dann den einen Pfosten, und den anderen lässt du wieder einfach nur drauf liegen. Wenn ich mit meiner Vermutung richtig liege, dann sollten nun beide Pfosten relativ sauber dargestellt werden.

Jetzt bin ich gespannt... :)