Hallo!

In meinem Projekt existiert ein Würfel, der sich aus kleineren Würfeln zusammen setzt. Er ist gefüllt mit... Würfeln! =D Nun sieht man diese Würfel aber überhaupt nicht, weil andere Würfel drum herum sind (dies ist aber nicht immer der Fall). Ich habe schon von so genannten Occlusion Queries gelesen, beschäftige mich aber nicht damit, weil OpenGL ES scheinbar keine Ahnung davon hat. Gibt es andere Möglichkeiten außer GL_CULL_FACE? GL_CULL_FACE verhindert ja auch nicht das zeichnen von verdeckten Objekten. Stichworte wären mir schon Hilfe genug =)

Sonst muss ich mit eigener Programmlogik an die Sache ran gehen. Mir fällt aber nur der Weg ein zu überprüfen, ob ein Würfel von anderen Würfeln umschlossen ist.

Gruß stoned4u

Stichwort: Tiefentest?

Also,... oder geht das bei GL ES nicht?

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

Für Tiefentest aktivier doch mal GL_DEPTH_TEST. Weiteres in glDepthFunc.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Der Tiefentest ist aktiviert, aber ich habe gedacht, er ist nur für die richtige Reihenfolge der Objekte verantwortlich - ich benutze an dieser Stelle GL_LESS. Merkt OpenGL selbst, wenn ich z.B. Alpha Blending aktiviere, dass er dann plötzlich doch die Objekte zeichnen muss, die nun durchschimmern müssten?

Ich habe gehofft noch eine Möglichkeit zu finden Performance gut zu machen =( so ein Ärger

Ahhh... so langsam kommen die Infos.

Transparenz bedeutet immer aufwand.

Nein OpenGL erkennt das nicht automatisch. (Siehe Artikel dazu im Wiki).

Du musst die Würfel der Reihe nach, von hinten nach vorn zeichnen. Anders gehts glaube ich nicht. (Naja, es geht schon noch anders. Es gibt da diverse Paper zu dem Thema. Aber ich glaube, dass läuft alles nicht so performant.)

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

stoned4u, ich kann dich "beruhigen". Wenn du bei Spielen genauer hinsiehst, wirst du oft Fehler beim Alphablending erkennen können. Genau solche Fehler, die darauf zurückzuführen sind, dass die Objekte in der falschen Reihenfolge gezeichnet werden. Den "großen" geht's also auch nicht anders

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Hallo,

ohne alpha blending fällt mir für diesen Fall nur der Trick ein, dass man erstmal alle Würfel in den Tiefenpuffer rendert ( was sehr schnell geht, wenn man alle anderen kostspieligen Effekte ausstellt ) und dann nochmal nur in den Farbpuffer.
Der Tiefentest ist leider erst sehr spät in der Renderpipeline aber unter Umständen könntest du damit etwas Performance gewinnen.

Wenn du nicht allzuviele Würfel hast, kommst du aber mit einer eigenen Sortierung besser weg.

Wenn du Würfel mit und ohne alpha blending hast, würd ich folgendermaßen vorgehen :
1. Alle 'festen' Würfel von vorne nach hinten zeichnen ( damit der Tiefentest optimal ausgenutzt wird )
2. Dann alle durchsichtigen Würfeln von hinten nach vorne ( damit das blending korrekt bleibt )


Viele Grüße
dj3hut1

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University

kannst du das nochmal genauer erklären. Sowas hatte ich von der Uni noch im Kopf. Aber wie es ganu ging, weiß ich nicht mehr. Irgendwie wurden die Objekte in der Tiefe "schichtweise abgetragen".

Ich weiß nicht mehr ganu wie...

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

Alphablending ist bei OpenGL ES nen mittelschweres Performance Problem.
dj3hut1 hat schon eine sehr gute Lösung genannt, wobei es weniger Fehler gibt, wenn du im ersten Durchgang(Z-Pass) die Transparenten Objekte garnicht zeichnest(spart zeit und da sie transparent sind, würden fehler auftreten, wenn der tiefentest und alpha kombiniert werden).

Wenn du Statische Objekte in der Szene hast, dann kannst du eine Sichtbarkeits-Tabelle aufbauen, welche die sichtbaren Nachbarn im jeweiligen Bereich enthält. Für geschlossende Räume z.B. BSP oder generell Octree mit einer Sichtbarkeits-Tabelle sind sehr Hilfreich.
Dabei werden dann die dynamischen Objekte einfach an ein oder mehreren Räumen gehängt und werden somit auch gleich mit einbezogen.

edit:

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Du renderst die Szene zweimal. Beim ersten Durchgang füllst du nur den z-Buffer. Dabei verwendest du einen minimalen Shader (oder fixed function) und deaktivierst das schreiben in den ColorBuffer (mit glColorMask). Im zweiten Durchgang renderst du dann nochmal ganz normal, allerdings ohne den z-Buffer zu schreiben. Da der z-Buffer bereits gefüllt ist wird kein Fragment unnötig berechnet.
=> Sowas macht aber nur Sinn, wenn du einen komplexen Fragmentshader oder extrem viele Texturen (etc.) verwendest. Und es funktioniert natürlich nur ohne Blending. Außerdem muss man darauf achten, dass man die Vertextransformation EXAKT auf identische Weise durchführt, den der Z-Wert muss für jedes Fragment identisch sein, sonst gibt es Löcher im Bild. Sollte man dennoch Probleme mit Rundungsfehlern haben, kann ein glDepthRange(0.01, 1.0) beim ersten Durchgang helfen, welches man beim zweiten Durchgang dann wieder auf glDepthRange(0.0, 1.0) zurücksetzt.

_________________
Yeah!

Ok. Das du damit nur die nötigen Fragmente behandelst ist klar. Aber wo hilft das beim Blendingproblem?

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

Es hilft beim Blending sofern, dass man das aufwendige Blending nicht auch noch für Objekte machen muss die man gar nicht sehen kann weil sie sich sowieso hinter undurchsichtigen Objekten befinden.

_________________
Yeah!

Ok... Es hilft mir nicht beim Algorithmus (sortieren etc. muss trotzdem sein), aber es beschleunigt den Rendervorgang.

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

Das ist so leider nicht ganz richtig, da der Tiefentest erst nach den Fragmentberechnungen stattfindet ( siehe Feste_Funktionspipeline#Fragment_Pipeline ).
Es könnte aber gut sein, dass es in der Hardware Optimierungen gibt, die dann trotzdem verhindern, dass z.B. komplexe Berechnungen im Fragment-Shader durchgeführt werden ( hab dazu eine interessante Diskussion gefunden ) .
Auf jeden Fall wird aber verhindert, dass die Fragmente gezeichnet werden.

Viele Grüße
dj3hut1

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University

Erst einmal danke für die Antworten! Ich werde es mir heute Abend mal in Ruhe genauer anschauen.



Darf ich fragen, was genau du studiert hast? Ich bin noch auf der Suche nach einem geeigneten Studium, das in die Nähe der Grafikentwicklung tritt (mit Blick auf die Entwicklung von Spielen). Bislang habe ich nur Medieninformatik gefunden, aber dort fällt mir der Schwerpunkt zu sehr auf die Webentwicklung.

Gruß stoned4u