Hi,

also steigen wir gleich voll ein, ich habe ein Liste von Objekten die ich zu sortieren habe, zwecks Transparenz. Die Objekte enthalten unter anderem eine ModelMatrix und eine Vertexliste.
Ich habe hier auch so eine Art Beschreibung gefunden:
http://www.opengl.org/wiki/Transparency_Sorting

Gut, die Nicht transparenten Objekte vor den transparenten zu zeichnen ist erstmal unproblematisch, ich wollte nun aber die untransparenten Objekte von vorne nach hinten (Füllrate sparen) und die transparenten Objekte von hinten nach vorne sortieren, ich weis nur leider nicht wonach ich da genau sortieren soll. In meinem Fall sind die Objekte glücklicherweise alle planar, also es handelt sich nicht wirklich um 3 Dimensionale Gebilde, dass sollte die Sache vereinfachen, in dem Artikel steht nun das es falsch ist nach dem nächsten oder entferntesten Vertex zu sortieren, macht ja auch Sinn, auch der Mittelpunkt gibt falsche Ergebnisse, macht auch Sinn, es wird gesagt man solle nach dem "span" sortieren, aber was ist damit gemeint?

Und um die Frage etwas auszudehnen, ich habe hauptsächlich Quads, wie kann ich den "span" (von dem ich derzeit nichtmal weis was es genau ist ) möglichst günstig berechnen? Muss ich dafür alle Vertizes auf der CPU transformieren?

Viele Grüße und Danke schon mal für eure Hilfe .

Also, soweit ich weiß, funktioniert dieses Konzept (Objekte sortieren) sowieso nur, wenn sich die Objekte nicht überschneiden. Da kannst du also gerne nach Mittelpunkt sortieren und hoffen, dass keine Fehler auftreten.
Alle Vertices transformieren hilft dir da übrigens auch nicht (wie im Artikel steht).

Die Lösung steht übrigens auch im Artikel, ist nur nicht näher beschrieben: Depth Peeling (die Pixel werden sortiert).

Wenn dir das zu langsam ist, gibt´s glaub ich noch einen MSAA-Hack, der allerdings nur die (bis zu) acht ersten Werte berücksichtigt (also die, die zuerst kommen, nicht die, die weiter vorne sind. Also sollten die Objekte von Vorne nach Hinten(!) sortiert sein)

Hm... das Problem ist, dass ich nur OpenGL ES 1.1 zur Verfügung habe, dass ist in etwa vergleichbar mit OpenGL 1.5 würd ich schätzen, mir fehlt also sehr vieles, ich habe bspw. (leider!) kein MSAA zur Verfügung, dass kommt erst mit OpenGL ES 2.0 und Shader stehen mir auchnicht zur Verfügung genauso wenig wie Framebuffer Objekte ...

Gibt es denn irgendeine halbwegs vernünftige Möglichkeit mit begrenzter CPU Geschwindigkeit und OpenGL ES 1.1 Transparenz auf den Bildschirm zu kriegen (natürlich meine ich damit nicht additive Transparenz ). Sonst müsste ich eben vorläufig auf Transparenz verzichten...

Ich würds über die Mittelpunkte machen, wenn die Objekte sowieso nur halb-3D sind. Du musst auch nur die Mittelpunkte über die Matrix transformieren. Also einfach den Mittelpunkt der Vertices ausrechnen, den dann transformieren und vergleichen.

greetings

_________________
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

Theoretisch kann man auch mit dem Stencilbuffer die Pixel markieren, die von anderen transparenten Objekten überlagert werden, und jeweils nur markierte Pixel zeichnen. Allerdings ist der Aufwand ziemlich hoch.
Ich denke man müsste dabei wie folgt vorgehen:

1. wiederhole Punkt 2 für i=0 bis n-1 (n ist die Anzahl der transparenten Flächen)
2. wiederhole Punkt 3-7 für j=0 bis n-1
3. man initialisiert den Tiefenbuffer mit der undurchsichtigen Geometrie
4. man zeichnet Fläche j mit glColorMask(false,...) um die Tiefe zu schreiben.
5. man löscht den Stencilbuffer auf 0
6. man zeichnet alle anderen Flächen mit glColorMask(false,...) und glStencilOp(GL_KEEP,GL_KEEP,GL_INCR)
7. man zeichnet die Fläche j aus Schritt 4 mit Farbe und glStencilFunc(GL_EQUAL, n-1-i, $FF)

Also die Idee war das man alle Pixel zeichnet, die durch n-1 Flächen (also alle anderen) verdeckt werden und damit am weitesten entfernt sind. Danach kommen alle Pixel dran die durch n-2 Flächen verdeckt sind. Das wären dann die die als nächstes in Richtung Kamera folgen.
Laufzeit wäre dann O(n³), was schon ziemlich schlimm ist. Für wenige Flächen aber vllt aktzeptabel. Aber sofern das oben funktioniert, würde es auch für überschneidende Flächen gehen.