Sichtbarkeits-Bugs bei entityfx 34 und textureflag 3

Übersicht

BlitzBasic

Blitz3D

	Der_Schläfer Betreff: Sichtbarkeits-Bugs bei entityfx 34 und textureflag 3	Sa, Apr 19, 2008 22:07 Antworten mit Zitat
Hallo susammn. Ich bastle gerade an einer Mesh-Terrain-Ladefunktion. Ich hab ein Mesh, das hat mehere Surfaces mit Gras, Steins usw. Übergänge mache ich mit der Vertexcolor-Funktion (indem ich die Alpha Werte der Verts verändere und für das ganze Mesh entityfx 34 aktiviere) Das Problem: Einzelne Surfaces werden falsch dargestellt, bzw sind immer Sichtbar, also die Steinfläche, die eingentlich hinter dem Grashügel WÄHRE wird immer in den Vordergrund gerendert. Ich hatte schon ähnliche Probleme, als ich ein maskiertes PNG mit textureflag benutzt hatte, und wollte mal fragen, ob jemand mir N00b vielleicht erklären kann, woher diese Bugs kommen und was man da am besten machen kann... Falls das wichtig ist: Ich hab Geforce 8600 GTS (schnell und verbuggt )

Der_Schläfer

Betreff: Sichtbarkeits-Bugs bei entityfx 34 und textureflag 3

Sa, Apr 19, 2008 22:07
Antworten mit Zitat

Hallo susammn.

Ich bastle gerade an einer Mesh-Terrain-Ladefunktion. Ich hab ein Mesh, das hat mehere Surfaces mit Gras, Steins usw.
Übergänge mache ich mit der Vertexcolor-Funktion (indem ich die Alpha Werte der Verts verändere und für das ganze Mesh entityfx 34 aktiviere)

Das Problem: Einzelne Surfaces werden falsch dargestellt, bzw sind immer Sichtbar, also die Steinfläche, die eingentlich hinter dem Grashügel WÄHRE wird immer in den Vordergrund gerendert.

Ich hatte schon ähnliche Probleme, als ich ein maskiertes PNG mit textureflag benutzt hatte, und wollte mal fragen, ob jemand mir N00b vielleicht erklären kann, woher diese Bugs kommen und was man da am besten machen kann...

Falls das wichtig ist: Ich hab Geforce 8600 GTS (schnell und verbuggt Very Happy

)

	Mr.Keks	Sa, Apr 19, 2008 22:34 Antworten mit Zitat
das ist ein ganz gängiges problem bei 3dgrafik, das nicht nur blitz3d und nicht nur deine eine graka hat. es entsteht wie folgt: beim rendern von dreiecken wird ja stets in den z-buffer geschrieben, sodass klar ist, wo die bisher vorderste fläche an einem bildpunkt ist. beim rendern des nächsten dreiecks wird für jeden pixel entschieden, ob er vor oder hinter dieser fläche liegt und er nur gezeichnet, wenn er davor liegt. es gibt also nur entweder zeichnen oder nicht zeichnen. bei sich überlagernden transparenten flächen funktioniert dieses entweder-oder-system dann natürlich nicht mehr so. darum schreibt man mit transparenten flächen einfach nicht in den z-buffer, da man ja auch dinge dahinter noch sehen können soll. entsprechend funktioniert die z-buffer-einschätzung, ob etwas vor oder hinter etwas anderem liegt, nicht mit transparenten objekten. stattdessen scheint einfach das am weitesten vorne, was zuletzt gezeichnet wurde. die zeichenreihenfolge wird bei blitz weitesgehend durch die reihenfolge der erstellung festgelegt. auf einem terrain kannst du das z-buffer-problem aber halbwegs simpel lösen. du solltest ein surface nutzen, das keine transparenz unterstützt und nur die grundlegenden tiles enthält und darüber ein surface nur für die übergänge legen. so machte eizdealer das beispielsweise seinerzeit bei der eqil-engine, soweit ich mich erinnere.
MrKeks.net

Mr.Keks

Sa, Apr 19, 2008 22:34
Antworten mit Zitat

das ist ein ganz gängiges problem bei 3dgrafik, das nicht nur blitz3d und nicht nur deine eine graka hat.

es entsteht wie folgt: beim rendern von dreiecken wird ja stets in den z-buffer geschrieben, sodass klar ist, wo die bisher vorderste fläche an einem bildpunkt ist. beim rendern des nächsten dreiecks wird für jeden pixel entschieden, ob er vor oder hinter dieser fläche liegt und er nur gezeichnet, wenn er davor liegt.
es gibt also nur entweder zeichnen oder nicht zeichnen. bei sich überlagernden transparenten flächen funktioniert dieses entweder-oder-system dann natürlich nicht mehr so. darum schreibt man mit transparenten flächen einfach nicht in den z-buffer, da man ja auch dinge dahinter noch sehen können soll. entsprechend funktioniert die z-buffer-einschätzung, ob etwas vor oder hinter etwas anderem liegt, nicht mit transparenten objekten. stattdessen scheint einfach das am weitesten vorne, was zuletzt gezeichnet wurde. die zeichenreihenfolge wird bei blitz weitesgehend durch die reihenfolge der erstellung festgelegt.

auf einem terrain kannst du das z-buffer-problem aber halbwegs simpel lösen. du solltest ein surface nutzen, das keine transparenz unterstützt und nur die grundlegenden tiles enthält und darüber ein surface nur für die übergänge legen.
so machte eizdealer das beispielsweise seinerzeit bei der eqil-engine, soweit ich mich erinnere.

MrKeks.net

	Der_Schläfer	Sa, Apr 19, 2008 22:40 Antworten mit Zitat
Danke für die prompte Antwort! Macht irgendwie Sinn... Zitat: du solltest ein surface nutzen, das keine transparenz unterstützt und nur die grundlegenden tiles enthält und darüber ein surface nur für die übergänge legen. Wer ich auf jeden Fall mal probieren. Mfg

Der_Schläfer

Sa, Apr 19, 2008 22:40
Antworten mit Zitat

Danke für die prompte Antwort! Macht irgendwie Sinn... Rolling Eyes

Zitat:

du solltest ein surface nutzen, das keine transparenz unterstützt und nur die grundlegenden tiles enthält und darüber ein surface nur für die übergänge legen.

Wer ich auf jeden Fall mal probieren.

Mfg

Übersicht

BlitzBasic

Blitz3D

Nach Oben

BlitzBasic Portal

Sichtbarkeits-Bugs bei entityfx 34 und textureflag 3

Der_Schläfer

Betreff: Sichtbarkeits-Bugs bei entityfx 34 und textureflag 3

Mr.Keks

Der_Schläfer