Alpha-to-coverage vs alpha blending... [Archiv]

Benedikt

2005-07-03, 10:35:37

Hi Leute,

nachdem ja mittlerweile Glättung von Alphatest-Texturen per Software möglich ist (http://www.humus.ca/index.php?page=3D&ID=61) (quasi Transparency AA "für den Rest von uns") - der DXTweaker kanns ja AFAIK auch -, ich aber ehrlich gesagt nicht sehr viel Ahnung habe, worin nun genau die Unterschiede bzw. Vor- und Nachteile zu Alpha-Blending liegen, hier meinerseits dazu einige Fragen:
1.) Ist dieses Verfahren konkurrenzfähig zu Alpha-Blending, auch von der Geschwindigkeit her?
2.) Welche Eigenheiten weisen beide Verfahren auf, von der Implementierung her? Wann ist es möglich bzw. sinnvoll, eines der Verfahren einzusetzen?

BTW, es gibt jetzt ein kleines Tool, mit dem man Alpha-to-coverage unter OpenGL für Doom3, UT, UT2004, Unreal forcen kann, siehe hier (http://www.beyond3d.com/forum/viewtopic.php?t=24595)!

MFG,
Benedikt

Coda

2005-07-03, 11:31:27

Alpha-Blending:
- Vorteil: "Perfekte" Lösung mit der man keinerlei Tricks braucht
- Nachteil: Man muss alle Polygone mit Alpha-Blending von hinten nach vorne sortieren.

Alpha-Testing:
- Vorteil: Keine Sortierung nötig. Deutlich schneller.
- Nachteil: Harte Kanten. Es greift kein MSAA.

Alpha-To-Coverage versucht nun Alpha-Testing mit der Qualität von Alpha-Blending zu kombinieren, was auch teilweiße gelingt.

Allerdings finde ich die Aussage von Humus inzwischen sehr biased. Er behauptet das TSSAA von nVIDIA sei "schlechter", was einfach Schwachsinn ist.

RLZ

2005-07-03, 11:39:06

Allerdings finde ich die Aussage von Humus inzwischen sehr biased. Er behauptet das TSSAA von nVIDIA sei "schlechter", was einfach Schwachsinn ist.
Was erwartest du von nem ATi-Mitarbeiter? Doch nicht etwa Lob für die Konkurrenz? ;)

Spasstiger

2005-07-03, 12:04:09

Was erwartest du von nem ATi-Mitarbeiter? Doch nicht etwa Lob für die Konkurrenz? ;)

Evtl. ist er auch schon so von sich selbst überzeugt, dass er sich zu solchen Aussagen hinreißen lässt.

Coda

2005-07-03, 14:07:41

Was erwartest du von nem ATi-Mitarbeiter? Doch nicht etwa Lob für die Konkurrenz? ;)Nein, aber ich würde an seiner Stelle versuchen mich dann gar nicht dazu zu äußern und auch nicht offensichtlich Demos zu produzieren die zeigen sollen dass die ach-so-tolle ATi-Hardware genauso gut wie die von nVIDIA ist, weil man ja eh alle Features auch so haben kann (zuerst mit Branching, jetzt mit AA für Alphatesting. Beides mehr schlecht als recht gelöst).

Aber das ist natürlich meine Meinung, vielleicht wird er ja auch dafür bezahlt. Würde mich auch nicht wundern...

Demirug

2005-07-03, 14:10:05

RLZ

2005-07-03, 14:33:19

Nein, aber ich würde an seiner Stelle versuchen mich dann gar nicht dazu zu äußern und auch nicht offensichtlich Demos zu produzieren die zeigen sollen dass die ach-so-tolle ATi-Hardware genauso gut wie die von nVIDIA ist, weil man ja eh alle Features auch so haben kann (zuerst mit Branching, jetzt mit AA für Alphatesting. Beides mehr schlecht als recht gelöst).

Aber das ist natürlich meine Meinung, vielleicht wird er ja auch dafür bezahlt. Würde mich auch nicht wundern...
Vielleicht identifiziert er sich auch nur mit seiner Firma?
Allerdings hab ich da wohl den gleichen Verdacht wie du.
Mit Humus hat man jemand, der von den Leuten nicht als ATi-Mitarbeiter angesehen wird, weil er schon vorher recht bekannt war. Viele vertrauen seiner Meinung weil er immer recht objektiv war.
Nun kann man über ihn Meinungen ändern. Wenn man in einer Newsmeldung etwas über seine Demos liest steht nie ATi-Mitarbeiter dabei. Man will offensichtlich auch nicht, dass er mit der Firma direkt in Verbindung gebracht wird.
Wenn keine solche Absicht hintendran stecken würde, wäre es bei ihm nur logisch, wenn seine Demos auch automatisch alle auf der Developerpage von ATi erscheinen würden...

Benedikt

2005-07-03, 20:05:20

Spasstiger

2005-07-03, 20:18:46

Ist Alpha-Testing mit Alpha-To-Coverage immer noch schneller als echtes Alpha-Blending?

Bei mir kostet Alpha-To-Coverage in der Demo rund 20% Performance, also deutlich weniger als echtes Alpha-Blending kosten würde.

Coda

2005-07-03, 21:03:50

Woher weißt du was echtes Alpha-Blending kosten würde? Ich würde das nämlich auch nicht bei mehr als 20% einordnen.

Das positive an Alphablending ist ja auch dass es schon ganz ohne AA glatte Kanten hat.

Xmas

2005-07-03, 21:33:25

Woher weißt du was echtes Alpha-Blending kosten würde? Ich würde das nämlich auch nicht bei mehr als 20% einordnen.
Wie wäre es mit: Demo runterladen, Alpha-Blending einstellen? ;)

Übrigens ist auf meiner Mobility Radeon 9600 Alpha Bending in der Startposition konsistent ~2% schneller als Alpha Test, A2C dagegen 5-10% langsamer. Erst wenn man schön nah und bildschirmfüllend an eine Alpha-Fläche herangeht, so dass sich möglichst große "Löcher" ergeben, wird Alpha-Test dann manchmal deutlich schneller. In einigen Situationen ist dann auch A2C schneller.

Das ist auch verständlich wenn man betrachtet dass die Demo rein grafiklimitiert ist, und wie Framebuffer-Kompression funktioniert. Alpha-Test hindert die Z-Buffer-Kompression. A2C hindert sowohl Z- als auch Color-Compression. Alpha-Blending nicht.
Und geht bei AT oder A2C eine Kante quer durch ein Tile, muss, genauso wie beim AB, der Framebuffer-Inhalt erst einmal gelesen werden.

Coda

2005-07-03, 21:34:44

Wie wäre es mit: Demo runterladen, Alpha-Blending einstellen? In dem Demo gibt es nur AT und ATC zur Auswahl.

Xmas

2005-07-03, 21:39:34

Nimm die aktuelle Version.

Gast

2005-07-03, 22:03:46

Das ist auch verständlich wenn man betrachtet dass die Demo rein grafiklimitiert ist, und wie Framebuffer-Kompression funktioniert. Alpha-Test hindert die Z-Buffer-Kompression. A2C hindert sowohl Z- als auch Color-Compression. Alpha-Blending nicht.

wieso wird da die kompression verhindert?

Coda

2005-07-03, 22:10:29

Weil es einen sehr hochfrequenten Z-Buffer erzeugt. Bei Alpha Blending sind Z-Buffer-Writes deaktiviert.

Xmas

2005-07-04, 02:08:31

wieso wird da die kompression verhindert?
Nicht ver-, sondern gehindert. Tiles in denen eine Kante ist, können (mit den aktuell verwendeten Verfahren) nicht mehr komprimiert werden. Für die Color-Compression müssen alle Farbsamples identisch sein. Für die Z-Kompression müssen alle Samples auf einer Ebene liegen.

Alpha-Blending (mit deaktiviertem Alpha-Test) erzeugt keine zusätzlichen Kanten. Zu GeForce 2-Zeiten wurde empfohlen, mit Alpha-Test die völlig transparenten Stellen beim Alpha-Blending herauszumaskieren. Damals war das sinnvoll, heute häufig sogar kontraproduktiv.

Ailuros

2005-07-04, 03:32:08

Nein, aber ich würde an seiner Stelle versuchen mich dann gar nicht dazu zu äußern und auch nicht offensichtlich Demos zu produzieren die zeigen sollen dass die ach-so-tolle ATi-Hardware genauso gut wie die von nVIDIA ist, weil man ja eh alle Features auch so haben kann (zuerst mit Branching, jetzt mit AA für Alphatesting. Beides mehr schlecht als recht gelöst).

Aber das ist natürlich meine Meinung, vielleicht wird er ja auch dafür bezahlt. Würde mich auch nicht wundern...

Demos wuerde ich schon produzieren (als Alternative), aber die Loesungen der Konkurrenz wuerde ich nicht versuchen niederzumetzeln, ueberhaupt wenn die bevorzugte HW nicht die besseren Loesungen unterstuetzt. Dann wird es eine Sache der Integritaet; ich will bezweifeln dass wenn er bezahlt wird dass die Vereinbarung auch PR-Schranzen betrifft. Fuer PR gibt es Profis bei den IHVs und nicht unbedingt eine Aufgabe/Arbeit auf die ich positiv eingestellt bin (egal bei welcher Firma).

ScottManDeath

2005-07-04, 04:24:09

Aber das ist natürlich meine Meinung, vielleicht wird er ja auch dafür bezahlt. Würde mich auch nicht wundern... Tuesday, May 3, 2005 Last saturday it was one year since I arrived to Canada and today it's one year since I started working at ATI. Er kann gar nicht anders als solche Demos zu schreiben ;)

zeckensack

2005-07-04, 05:05:14

Er kann gar nicht anders als solche Demos zu schreiben ;)Trotzdem finde ich es unsauber. Immerhin ist das öffentlich zugängliches Material, und nicht irgendeine Hetzschrift, die nur im privaten Kämmerlein herumgereicht wird.

Die politisch korrekte Entscheidung wäre gewesen, das ganze einfach als "qualtitativ besser als purer Alpha-Test und unkomplizierter als Blending" zu verkaufen. Wenn die Konkurrenz etwas besseres hat, dann kann man das in solchen Fällen einfach verschweigen. Besser als plumpe Lügen zu verbreiten wäre das allemal.

Xmas

2005-07-04, 05:09:49

Benedikt

2005-07-04, 07:25:52

Wobei die Nachteile von Alpha-Test in Verbindung mit Mipmapping tatsächlich nicht ganz von der Hand zu weisen sind. Und Supersampling kann dann auch nicht verhindern dass eben ab einer gewissen Mipmap beispielsweise der Zaun völlig transparent wird.
Also, so entnehme ich euren Postings, wird sich Alpha-To-Coverage nicht wirklich gegen echtes Alpha-Blending durchsetzen können, da ja offenbar Alpha-Blending nicht viel mehr Performance kostet? Kann man das so stehen lassen?

Wie lange gibt's denn eigentlich Alpha-To-Coverage schon, ist das ein verhältnismäßig "neues" Verfahren, oder wird das schon wo in aktuellen Titeln eingesetzt? Warum eigentlich nicht, ist doch eine passable Möglichkeit, Flimmern bei Alpha-Test-Texturen zu vermeiden...

Ailuros

2005-07-04, 08:08:04

Wobei die Nachteile von Alpha-Test in Verbindung mit Mipmapping tatsächlich nicht ganz von der Hand zu weisen sind. Und Supersampling kann dann auch nicht verhindern dass eben ab einer gewissen Mipmap beispielsweise der Zaun völlig transparent wird.

Wenn ich Dich richtig verstanden habe bei B3D, waere die rundum idealste Loesung (nach Deiner Meinung) eine Kombination von TSAA (magnification) und alpha blending (oder alpha to coverage) (mignification) unter der Vorraussetzung dass man eventuell einen dual pass Mechanismus verwendet.

Wie schwer/umstaendlich waere ein dual pass und falls es moeglich ist ohne besondere Umstaende (und da alpha to coverage/blend SW basierende Methoden sind), wer haette in solch einem Fall immer noch den Vorteil?

Von dem abgesehen, wie schwer wird es fuer NVIDIA sowieso sein alpha to coverage in den Treiber CP reinzuschieben als Gegenreaktion?

Asmodeus

2005-07-04, 08:08:30

Also, so entnehme ich euren Postings, wird sich Alpha-To-Coverage nicht wirklich gegen echtes Alpha-Blending durchsetzen können, da ja offenbar Alpha-Blending nicht viel mehr Performance kostet? Kann man das so stehen lassen?

Wie lange gibt's denn eigentlich Alpha-To-Coverage schon, ist das ein verhältnismäßig "neues" Verfahren, oder wird das schon wo in aktuellen Titeln eingesetzt? Warum eigentlich nicht, ist doch eine passable Möglichkeit, Flimmern bei Alpha-Test-Texturen zu vermeiden...

glSampleCoverage() (ohne ARB) gibt es schon seit OpenGL 1.3. Und sicher ist es richtig, dass der AlphaBlending-Vorgang nicht sooo viel mehr Performance kostet und auch viele Vorteile mit sich bringt. Der Knackpunkt ist aber eher das Vorsortieren der Szene. Und das kann bei gewissen Szenarien einfach mal "unmöglich" sein, so dass man um AlphaTesting und/oder Alpha to Coverage nicht herumkommt.

Gruss, Carsten.

Asmodeus

2005-07-04, 08:10:36

ScottManDeath

2005-07-04, 12:49:11

Trotzdem finde ich es unsauber. Immerhin ist das öffentlich zugängliches Material, und nicht irgendeine Hetzschrift, die nur im privaten Kämmerlein herumgereicht wird.

Die politisch korrekte Entscheidung wäre gewesen, das ganze einfach als "qualtitativ besser als purer Alpha-Test und unkomplizierter als Blending" zu verkaufen. Wenn die Konkurrenz etwas besseres hat, dann kann man das in solchen Fällen einfach verschweigen. Besser als plumpe Lügen zu verbreiten wäre das allemal.

Klar. Es ist doof wenn das jetzt so rüberkommt das Humus das alles besser kann was die NV Hardwarejungs auch können ;)

Xmas

2005-07-04, 15:43:50

Also, so entnehme ich euren Postings, wird sich Alpha-To-Coverage nicht wirklich gegen echtes Alpha-Blending durchsetzen können, da ja offenbar Alpha-Blending nicht viel mehr Performance kostet? Kann man das so stehen lassen?
Alpha-to-Coverage kann man im Treiber erzwingen, Alpha-Blending nicht (es sei denn man heißt PowerVR). Neue Spiele sollten idR Alpha-Blending verwenden.

Wie lange gibt's denn eigentlich Alpha-To-Coverage schon, ist das ein verhältnismäßig "neues" Verfahren, oder wird das schon wo in aktuellen Titeln eingesetzt? Warum eigentlich nicht, ist doch eine passable Möglichkeit, Flimmern bei Alpha-Test-Texturen zu vermeiden...
Gibt es seit NV20, nur unglücklicherweise nicht in DirectX.

Wenn ich Dich richtig verstanden habe bei B3D, waere die rundum idealste Loesung (nach Deiner Meinung) eine Kombination von TSAA (magnification) und alpha blending (oder alpha to coverage) (mignification) unter der Vorraussetzung dass man eventuell einen dual pass Mechanismus verwendet.

Wie schwer/umstaendlich waere ein dual pass und falls es moeglich ist ohne besondere Umstaende (und da alpha to coverage/blend SW basierende Methoden sind), wer haette in solch einem Fall immer noch den Vorteil?
Inwiefern "SW basierende Methoden"? Dual-Pass wäre einfach zu realisieren, aber vergleichsweise teuer. Und ich weiß nicht wie gut der Übergang aussehen würde.

Von dem abgesehen, wie schwer wird es fuer NVIDIA sowieso sein alpha to coverage in den Treiber CP reinzuschieben als Gegenreaktion?
Für ATI meinst du wohl. Sehr einfach IMO. Ich rechne damit in einer der nächsten Treiberversionen.

Xmas

2005-07-04, 15:50:04

Der Knackpunkt ist aber eher das Vorsortieren der Szene. Und das kann bei gewissen Szenarien einfach mal "unmöglich" sein, so dass man um AlphaTesting und/oder Alpha to Coverage nicht herumkommt.
"Unmöglich" ist es nur bei sich schneidenden Alpha-Polygonen.
Ansonsten ist die Anzahl transparenter Objekte meist recht gering so dass das Sortieren kein großes Problem darstellt. Bei Vegetation kann Alpha-to-Coverage allerdings sehr praktisch sein.

Naja, wobei man die Sache auch noch abmildern/umgehen kann, indem man einfach die Mipmap-Stufen von Alpha-Texturen selbst generiert und dabei eben ein anderes Verfahren einsetzt als das Standardverfahren.
Das geht bei "geraden", breiten Strukturen wie Lattenzäunen und Leitern einigermaßen, aber bei schmalen Maschendrahtzäunen kannst du kaum was retten. Bei Vegetation geht der Effekt zum Glück meist unter.

Asmodeus

2005-07-04, 16:00:51

...
Das geht bei "geraden", breiten Strukturen wie Lattenzäunen und Leitern einigermaßen, aber bei schmalen Maschendrahtzäunen kannst du kaum was retten. Bei Vegetation geht der Effekt zum Glück meist unter.

Ja, da kann man über die Mipmap-Stufen hinweg halt nur die schmalen Strukturen "etwas dicker" werden lassen und dafür z.B. mit dem SampleCoverage allgemein die Durchsichtigkeit steigern, so daß trotzdem der Eindruck einer Struktur mit "wenig Substanz und viel Luft dazwischen" entsteht. Aber Du hast natürlich recht, es bleibt trotzdem nur ein Hack.

Gruss, Carsten.

KiBa

2005-07-05, 00:06:46

"Unmöglich" ist es nur bei sich schneidenden Alpha-Polygonen.
Auch von der Betrachterposition aus sich zyklisch überlappende Dreiecke sind ein Problem, was bei Vegetation sogar häufig auftreten kann. Dabei kommt es unweigerlich zu Fehldarstellungen mit Alpha Blending.

MadManniMan

2005-07-05, 09:48:17

Alpha-Blending (mit deaktiviertem Alpha-Test) erzeugt keine zusätzlichen Kanten. Zu GeForce 2-Zeiten wurde empfohlen, mit Alpha-Test die völlig transparenten Stellen beim Alpha-Blending herauszumaskieren. Damals war das sinnvoll, heute häufig sogar kontraproduktiv.

*irritiert ist*

Wäh, war das nicht so, daß man für einen Drawcall nur ein Renderstate haben kann?

Demirug

2005-07-05, 10:00:17

*irritiert ist*

Wäh, war das nicht so, daß man für einen Drawcall nur ein Renderstate haben kann?

Für einen Drawcall können alle Renderstates nur einen Zustand einnehmen. Da der Alphatest und Alphablend zwei Renderstates sind können sie beide gleichzeitig aktiv sein.

MadManniMan

2005-07-05, 10:07:37

Für einen Drawcall können alle Renderstates nur einen Zustand einnehmen. Da der Alphatest und Alphablend zwei Renderstates sind können sie beide gleichzeitig aktiv sein.

Hilfe! Langsam!

Aaalso wie du ja sagst, gibts pro Drawcall nur einen Renderstatezustand - warum können dann aber 2 Renderstates auf einmal gleichzeitig aktiv sein?

Demirug

2005-07-05, 10:29:58

Hilfe! Langsam!

Aaalso wie du ja sagst, gibts pro Drawcall nur einen Renderstatezustand - warum können dann aber 2 Renderstates auf einmal gleichzeitig aktiv sein?

Nicht ein Renderstate pro Call sondern ein Zustand pro State pro Call.

Die entsprechenden Zustände werden alle im Context bzw. bei D3D im Device gespeichert. Man darf so viele Zstände vor dem Drawcall verändern wie man möchte. Sobald der Drawcall aber dann erfolgt ist gelten die eingestellten Zuständen für alle Verticen, Primitive, Pixel usw welche diesen Drawcall betreffen. Für den nächsten Drawcall darf man dann wieder alles verändern. Abhängig davon was man verändert können diese Änderungen günstig oder teuer sein.

MadManniMan

2005-07-05, 12:26:35

Ah, schon besser!

Heißt also, daß es durchaus praktisch machbar ist, für eine ... äh ... Vegetationstextur z.B. den Rand des Blattes Zu Blenden, die komplett durchsichtigen dann mit Alpha-Test zu behandeln?

Demirug

2005-07-05, 12:36:15

Benedikt

2005-07-05, 13:04:51

Theoretisch ja nur bringt das keinen Vorteil.
Alternativ kann man also die besagte Pflanze in Alpha-Blending realisieren, oder eben die "ausgefransten Kanten" mittels Alpha-To-Coverage behandeln.

Und kann mir bitte nochmal jemand einsteigerkompatibel erklären, wann genau Alpha-Blending nicht möglich ist - hab ich das richtig verstanden wenn man durch die Pflanze durch auf eine weitere mittels Alpha-Blending realisierte Pflanze blickt? Kann doch nicht sein, oder?

Asmodeus

2005-07-05, 13:14:33

Alternativ kann man also die besagte Pflanze in Alpha-Blending realisieren, oder eben die "ausgefransten Kanten" mittels Alpha-To-Coverage behandeln.

Und kann mir bitte nochmal jemand einsteigerkompatibel erklären, wann genau Alpha-Blending nicht möglich ist - hab ich das richtig verstanden wenn man durch die Pflanze durch auf eine weitere mittels Alpha-Blending realisierte Pflanze blickt? Kann doch nicht sein, oder?

Nein, es geht vielmehr bei den Fällen nicht, wo sich Geometrie überkreuzt, schneidet oder gegenseitig durchdringt und somit nicht einwandfrei beim Sortieren bestimmt werden kann, welcher Teil der Geometrie von welchem Standpunkt aus betrachtet hinten und welcher Teil vorn liegt. Und vorallem bei komplexeren Pflanzenmodellen treten diese Fälle quasi ständig auf.

Gruss, Carsten.

micki

2005-07-05, 13:44:41

Theoretisch ja nur bringt das keinen Vorteil.
in einigen papern von NV steht, dass es fixer ist, wenn man alphatest zusätzlich einschaltet, da hatten die karten wohl aber noch kein earlyz. wenn man jedoch ohne zbuffer zeichnen (z.b. GUI), sollte es noch einiges bringen zusätzlich zum alphablend den alphatest zu aktivieren denk ich mir.

MfG
micki

Xmas

2005-07-05, 14:16:26

in einigen papern von NV steht, dass es fixer ist, wenn man alphatest zusätzlich einschaltet, da hatten die karten wohl aber noch kein earlyz. wenn man jedoch ohne zbuffer zeichnen (z.b. GUI), sollte es noch einiges bringen zusätzlich zum alphablend den alphatest zu aktivieren denk ich mir.
Wenn AA aktiv ist und man damit nicht gerade großflächige Teile wegschneiden kann bringt es praktisch nichts.

Coda

2005-07-05, 15:15:43

Nein, es geht vielmehr bei den Fällen nicht, wo sich Geometrie überkreuzt, schneidet oder gegenseitig durchdringt und somit nicht einwandfrei beim Sortieren bestimmt werden kann, welcher Teil der Geometrie von welchem Standpunkt aus betrachtet hinten und welcher Teil vorn liegt. Und vorallem bei komplexeren Pflanzenmodellen treten diese Fälle quasi ständig auf.

Gruss, Carsten.Man kann die Polygone entsprechend splitten, damit eine Sortierung möglich ist.

Asmodeus

2005-07-05, 15:41:18

Man kann die Polygone entsprechend splitten, damit eine Sortierung möglich ist.

Ich möchte bei einem Baummodell mit 100.000 Dreiecken nicht für das Splitten verantwortlich sein und für das Sortieren noch weniger. ;)

Gruss, Carsten.

Gast

2005-07-05, 15:47:28

Ich möchte bei einem Baummodell mit 100.000 Dreiecken nicht für das Splitten verantwortlich sein und für das Sortieren noch weniger. ;)

Gruss, Carsten.

also wenn du ein baummodell mit 100000 polygonen hast, dann wird für das restliche level nicht mehr viel übrig sein.

wenn man einen wald darstellen will und nicht nur einen einzigen baum wird es noch schlimmer ;)

Asmodeus

2005-07-05, 15:52:37

also wenn du ein baummodell mit 100000 polygonen hast, dann wird für das restliche level nicht mehr viel übrig sein.

wenn man einen wald darstellen will und nicht nur einen einzigen baum wird es noch schlimmer ;)

Man sollte vielleicht auch nicht immer nur von Spielen als einzige 3D-Anwendung ausgehen. ;)

Gruss, Carsten.

Neomi

2005-07-05, 16:02:46

Ich möchte bei einem Baummodell mit 100.000 Dreiecken nicht für das Splitten verantwortlich sein und für das Sortieren noch weniger. ;)

Splitten ist simpel und geht problemlos automatisch. Die Sortierung muß man auch nicht manuell machen, nur leider ist die vom Blickwinkel abhängig und trotzdem zu rechenintensiv, um sie zur Laufzeit zu machen. Ein paar vorsortierte Listen kann man aber problemlos in einen Indexbuffer packen. Dann nimmt man eben in jedem Bild die Liste, deren Blickwinkel dem tatsächlichen am nächsten kommt. Recht schnell, recht einfach und in fast allen Fällen ausreichend.

micki

2005-07-05, 16:07:38

Wenn AA aktiv ist und man damit nicht gerade großflächige Teile wegschneiden kann bringt es praktisch nichts.
du meinst also wirklich, dass in fällen in denen es keine vorteile hat, dass es da auch nichts bringt.;)

hmm

dem kann ich einfach nicht wiedersprechen, aber sagen wir mal so, in den fällen, in denen es was bringt, da hat es auch vorteile.

*kopfkratz*
man kann für alle optimierungen sagen, dass sie außer in den fällen für die sie gedacht sind, nichts bringen. aber was willst du damit jetzt sagen?

MfG
micki

Asmodeus

2005-07-05, 16:18:48

Splitten ist simpel und geht problemlos automatisch. Die Sortierung muß man auch nicht manuell machen, nur leider ist die vom Blickwinkel abhängig und trotzdem zu rechenintensiv, um sie zur Laufzeit zu machen. Ein paar vorsortierte Listen kann man aber problemlos in einen Indexbuffer packen. Dann nimmt man eben in jedem Bild die Liste, deren Blickwinkel dem tatsächlichen am nächsten kommt. Recht schnell, recht einfach und in fast allen Fällen ausreichend.

Da gebe ich Dir recht, aber mit dieser Methode bekommt man natürlich den Speicher schön schnell voll, und bei mehreren hundert Megabyte Geometrie- und Texturdaten für die Modelle dürfte der Overhead nicht unbedeutend sein. Und das Splitten an sich treibt den Polycount natürlich auch noch in die Höhe.

Gruss, Carsten.

micki

2005-07-05, 17:09:14

Splitten ist simpel und geht problemlos automatisch. Die Sortierung muß man auch nicht manuell machen, nur leider ist die vom Blickwinkel abhängig und trotzdem zu rechenintensiv, um sie zur Laufzeit zu machen. Ein paar vorsortierte Listen kann man aber problemlos in einen Indexbuffer packen. Dann nimmt man eben in jedem Bild die Liste, deren Blickwinkel dem tatsächlichen am nächsten kommt. Recht schnell, recht einfach und in fast allen Fällen ausreichend.
nur in fällen bei denen man das objekt von außen sehen kann, sobald du durch das 100 000 poly gebäude läufst, bräuchtest du unheimlich viele indexlisten.
MfG
micki

Neomi

2005-07-05, 18:47:14

nur in fällen bei denen man das objekt von außen sehen kann, sobald du durch das 100 000 poly gebäude läufst, bräuchtest du unheimlich viele indexlisten.

Nicht wirklich. Die Sortierung ist abhängig von der Richtung, in die man schaut, aber nicht von der Kameraposition. OK, die Blickrichtung ist zwar von der Position abhängig, aber die grobe Richtung wird ja beibehalten. Was vor der Kamera liegt, ist weiterhin grob (ist eben leider nur eine Näherung) richtig sortiert, was dahinter liegt wird rausgeclippt.

Es ist nicht perfekt, aber es liefert ein recht gutes Ergebnis bei ordentlicher Performance. Bei Bäumen sollte es auch nicht allzu schlimm sein, wenn man mal drin steht und eine Tannennadel zufälligerweise eine nähere Tannennadel überdeckt.

zeckensack

2005-07-05, 20:18:28

Ich möchte bei einem Baummodell mit 100.000 Dreiecken nicht für das Splitten verantwortlich sein und für das Sortieren noch weniger. ;)

Gruss, Carsten.IMO wirst du umso weniger splitten müssen, je komplexer deine Modelle sind.

Als krasses Beispiel sei hier der mittels zweier Dreiecke realisierte "Baum" genannt. Verdopplung der Geometriemenge durch den Split. Schlimmer wird es praktisch nie kommen, eher im Gegenteil.

Asmodeus

2005-07-06, 07:06:43

IMO wirst du umso weniger splitten müssen, je komplexer deine Modelle sind.

Als krasses Beispiel sei hier der mittels zweier Dreiecke realisierte "Baum" genannt. Verdopplung der Geometriemenge durch den Split. Schlimmer wird es praktisch nie kommen, eher im Gegenteil.

Ich hätte ja fast Lust mal einen "Wettbewerb" zu starten. Ich stelle eins unserer Baummodelle zur Verfügung, und wer dann mit dem wenigsten zusätzlichen Overhead und dem besten visuellen Ergebnis ein Alpha-Blending realisiert, der hat gewonnen. ;)

Gruss, Carsten.

Demirug

2005-07-06, 07:30:34

Ich hätte ja fast Lust mal einen "Wettbewerb" zu starten. Ich stelle eins unserer Baummodelle zur Verfügung, und wer dann mit dem wenigsten zusätzlichen Overhead und dem besten visuellen Ergebnis ein Alpha-Blending realisiert, der hat gewonnen. ;)

Gruss, Carsten.

GPU oder CPU Overhead?

Asmodeus

2005-07-06, 07:34:54

GPU oder CPU Overhead?

Natürlich beides. Wobei bei einem einzelnen Modell der CPU Overhead nicht so riesig sein dürfte, da ja nicht so viel sortiert werden muss, wie bei einer kompletten Szene.

EDIT: Ausgangspunkt wäre quasi die Dreiecksanzahl des Ursprungsmodells und der daraus resultierende Speicherverbrauch für Geometrie-, Index- und Texturdaten. Und natürlich die FPS bei sagen wir mal 1024 x 768 mit 4xAA und 8xAF, dabei ohne Beleuchtung, einfach nur das texturierte Modell.

Gruss, Carsten.

Asmodeus

2005-07-06, 08:14:12

So, lassen wir den Worten doch einfach mal Taten folgen. ;)

Im Programmierforum habe ich jetzt mal einen Wettbewerb ausgerufen:

Programmierwettbewerb (AT vs AB) (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=233603)

Und ich bin mal gespannt, ob jemand seine Vorschläge auch in die Tat umsetzt. ;) Und zu gewinnen gibt es natürlich auch noch etwas. :)

Gruss, Carsten.