MegaTexture-Verfahren

[Mephisto]

Ich bin über einen Artikel gestolpert:
As John Carmack said in his keynote speech, we have a 32,000 by 32,000 unique texture that covers the entire terrain, so visually you have a unique landscape. You can have rocks, cliffs, and tarmac blending into sand, grass or gravel. And we can also draw all the way to the horizon.

You know how other developers will fog a big terrain so they can include more stuff? We don't do that. We Brute Force Render right to the horizon as far as you can see. You can stand at one end of the map and look across it diagonally and see for a mile and a half. But what's really cool about this is, besides the visual benefits of having what is effectively a very high resolution texture with full dynamic lighting, is that it has an effect on gameplay.
Quelle (http://www.gamedaily.com/pc/preview/?id=133&type=1&source=00001&gameid=4393)

So ganz verstehe ich das nicht. Wenn die Terraintextur in der Größe begrenzt ist, wie kann sie sich dann "meilenweit" erstrecken?
Was ist der Vorteil gegenüber vielen kleinen Texturen? Da sieht man doch auch keine Texturränder im Terrain, oder?
Können heutige 3D-Karten das überhaupt verarbeiten?

Hat jemand Links zu Artikeln, die das gut erklären?
Vielen Dank!

[Demirug]

Die Textur muss natürlich für die 3D-Karten natürlich wieder in kleinere zerlegt werden.

Das Problem dabei ist allerdings die riesige Datenmenge. Da muss man schon etwas tricksen.

[Gast]

klingt interessant, aber wie soll diese textur in den VRAM passen?

[Demirug]

klingt interessant, aber wie soll diese textur in den VRAM passen?

Gar nicht. Die wird gestreamt.

[Gast]

Gar nicht. Die wird gestreamt.

na toll, die performance wird dann aber nicht wirklich gut sein.

außerdem braucht man ja auch noch andere texturen, gelände alleine ist ja auch ein wenig fad ;)

[Demirug]

na toll, die performance wird dann aber nicht wirklich gut sein.

Das geht eigentlich ganz gut. Da kann man wenigstens mal die PCIe Bandbreite nutzten. Das Problem ist das Prechaching. Mann muss die Daten rechtzeitig von der Festplatte in den Speicher holen und von dort weiter in die Grafikkarte. Das Timeing muss da genau passen.

außerdem braucht man ja auch noch andere texturen, gelände alleine ist ja auch ein wenig fad ;)

Da kann man ähnlich verfahren.

[Gast]

Das geht eigentlich ganz gut. Da kann man wenigstens mal die PCIe Bandbreite nutzten.

und 4GB/s sollen da reichen, wo wir beim VRAM schon bei fast 10-facher bandbreite sind?

außerdem müsste die textur dann ja im hauptspeicher liegen was bei 32000² mit 32bit ja schon fast 4GB ausmacht, was ein "normaler" computer ja nicht gerade zur verfügung hat. außerdem könnte die textur dann ja selbst über PCIe 16x kaum mehr als 1x/s übertragen, und 1fps ist ja doch etwas wenig ;)

[MeLLe]

Man muss sie aber auch nicht jedes Frame erneut in den VRAM laden.

[Gast]

Man muss sie aber auch nicht jedes Frame erneut in den VRAM laden.

klar, wie den sonst, wenn sie nicht komplett in den VRAM passt?

[Coda]

Man teilt sie in einzelne Stücke. GPUs können eh nur maximal 4096x4096 derzeit.

Vorraussetzung ist dann natürlich dass man niemals das ganze Terrain auf einmal sieht, was sich z.B. durch Nebel recht gut machen lässt. Oder man läd für die Distanz nur die Mips hoch.

[Gast]

Man teilt sie in einzelne Stücke. GPUs können eh nur maximal 4096x4096 derzeit.

Vorraussetzung ist dann natürlich dass man niemals das ganze Terrain auf einmal sieht, was sich z.B. durch Nebel recht gut machen lässt. Oder man läd für die Distanz nur die Mips hoch.

dann zitiere ich nochmal aus der oberen quelle.

And we can also draw all the way to the horizon.

You know how other developers will fog a big terrain so they can include more stuff? We don't do that. We Brute Force Render right to the horizon as far as you can see.

diese technologie soll ja genau das unnötig machen.

wenn ich nicht alles auf einmal sehen kann brauch ich doch eh nicht so eine riesige texture ;)

[Demirug]

Der Horizont ist nicht identisch mit dem Rand der Texture. Zudem gibt es ja auch noch eine große Fläche hinter dem Spieler sowie rechts und links von ihm die er nicht sieht. Entsprechend sieht man auch beim rendern bis zum Horizont nur einen Teil der großen Textur. Genau diesen Teil muss man im Speicher der Grafikkarte vorhalten. Zudem noch die Teile die wahrscheinlich gleich in den Sschtbaren Bereich kommen.

[Coda]

Man kann in der Distanz ja auch nur die Mips hochladen (hab ich das nicht schon erwähnt?)

[Gast]

stimmt, allerdings bräuchte man noch immer extreme hauptspeichermengen, von der festplatte zu streamen dürfte wohl deutlich zu langsam sein.

im hauptspeicher müssen dann ja neben der haupttextur auch die ganzen mips vorliegen, was nochmal den speicherbedarf erhöht.

[del_4901]

stimmt, allerdings bräuchte man noch immer extreme hauptspeichermengen, von der festplatte zu streamen dürfte wohl deutlich zu langsam sein.

im hauptspeicher müssen dann ja neben der haupttextur auch die ganzen mips vorliegen, was nochmal den speicherbedarf erhöht.

1. gibt es genug kompressionsverfahren
2. sind die 256MB der Graka gegenüber den 4GB des RAM wirklich ein klachs.
3. sind 64bit CPUs im kommen (aber auch nur wg der 4Gb Grenze was Spiele betrifft)
4. wenn der Hauptspeicher wirklich knapp wird, dann wird halt geswapped

Wenn das alles gut ineinandergreift und rechtzeitig erkannt wird, was ich demnächst benötige, so ist das alles kein Problem.

[Coda]

Carmack sollte auch wissen was er sagt, bisher hat er bei sowas noch nie gelogen.

[del_4901]

Carmack sollte auch wissen was er sagt, bisher hat er bei sowas noch nie gelogen.

Das ist ja auch ein Freak, wenn selbst Sweeny von Carmi sagt das er ein programmierGott ist ... allerdings kann er dafür nicht so gut mit seinem Team, und deswegen gräbt Epic immer mehr id das Wasser ab.

[StefanV]

4. wenn der Hauptspeicher wirklich knapp wird, dann wird halt geswapped
Was aber auch nur solange möglich ist, solang man noch Adressraum hat, der ja, wenn man 'ne x1800XT mit 512MB, 'optimalerweise' gar im Crossfireverbund, durchaus reichlich knapp ist, da sich diese beiden Kärtchen gleich mal 'nen Gigabyte krallen...

[del_4901]

Was aber auch nur solange möglich ist, solang man noch Adressraum hat, der ja, wenn man 'ne x1800XT mit 512MB, 'optimalerweise' gar im Crossfireverbund, durchaus reichlich knapp ist, da sich diese beiden Kärtchen gleich mal 'nen Gigabyte krallen...
Auch da gibt es Mittel und wege, keine Sorge :) und die krallen sich auch nur 512MB weil es doppelt vorkommt

[StefanV]

Auch da gibt es Mittel und wege, keine Sorge :) und die krallen sich auch nur 512MB weil es doppelt vorkommt
Bei Crossfire würd ich das mal stark bezweifeln...
Da kann die eine Karte garnicht wissen, was die andere macht.

[del_4901]

Bei Crossfire würd ich das mal stark bezweifeln...
Da kann die eine Karte garnicht wissen, was die andere macht.

Du hast genau den Grund genannt weswegen auch beides doppelt vorkommen muss!

[Coda]

Bei Crossfire würd ich das mal stark bezweifeln...
Da kann die eine Karte garnicht wissen, was die andere macht.Doch doch, der Treiber shared alles was die Karten beide brauchen im selben Raum.

[Mephisto]

Meiner Meinung nach lassen die Formulierungen des Artikels darauf schliessen, dass das Verfahren mit heutigen Systemen funktionieren soll (nix 4GB RAM, nix SLI) , und dabei Vorteile bringt, keine Nachteile.

Hat jemand Links zu einer genaueren Erklärung?

[Coda]

Man streamt die Textur halt. Das machen Spiele wie GTA und WoW ja schon lange, man muss nur rechtzeitig prefetchen.

[Cyphermaster]

Der angestrebte optische Vorteil ist wohl, daß keine "Kachel"-Übergänge mehr sichtbar werden und sich kein Makro-Muster mehr erkennen läßt, wie wenn man kleinere Texturen in einem sehr großen Sichtbereich aneinanderreiht. Das kommt bei WoW z.B. ja noch sehr exzessiv vor. Steppengebiete etc. wirken bei großen Sichtbereich regelmäßig "gestreift" - und damit sehr unecht.

[Expandable]

Was ich nicht verstehe: Wozu braucht man die riesige Textur überhaupt, inwiefern kann eine Textur fürs Terrain-Rendern verantwortlich sein? Hat das irgendwas mit Displacement Mapping zu tun? Und kann man mit einer 32000x32000 Pixel großen Textur wirklich kilometergroßes Gelände "darstellen"? Irgendwie kommt mir die Textur rein gefühlsmäßig dazu zu klein vor... bitte um Aufklärung ;)

[aths]

Die Textur muss natürlich für die 3D-Karten natürlich wieder in kleinere zerlegt werden.

Das Problem dabei ist allerdings die riesige Datenmenge. Da muss man schon etwas tricksen.Oder Xmas fragen :)

Man teilt sie in einzelne Stücke. GPUs können eh nur maximal 4096x4096 derzeit.NV40+ kann eigentlich auch 8192-er. Warum das via Treiber nicht freigeschaltet wurde, entzieht sich meiner Kenntnis.

4. wenn der Hauptspeicher wirklich knapp wird, dann wird halt geswapped.Geswappt.

Doch doch, der Treiber shared allesDer Treiber shart. Sieht doof aus? Dann könnte man es auch deutsch formulieren :)

[Demirug]

Oder Xmas fragen :)

Wenn du deinen Designer sagst sie dürfen eine große Karte völlig frei zeichnen und kommst dann plötzlich damit das sie sich aber aus überlagerten Tiles zusammensetzten muss bringen die dich um.

NV40+ kann eigentlich auch 8192-er. Warum das via Treiber nicht freigeschaltet wurde, entzieht sich meiner Kenntnis.

AFAIK funktioniert das nicht bei allen Formaten und sie dürfen nur die Größe melden die immer funktioniert.

[aths]

Wenn du deinen Designer sagst sie dürfen eine große Karte völlig frei zeichnen und kommst dann plötzlich damit das sie sich aber aus überlagerten Tiles zusammensetzten muss bringen die dich um.32k-Texturen reichen sowieso nicht für große Karten, wenn man nicht noch mit Detailtexturing arbeitet. Selbst mit DXT1 nimmt die 32k-Map ca. 683 MiB ein. Mit dem Speicher wüsste ich besseres anzufangen.

Man sollte wegen der Skalierbarkeit imo sowieso mit Materialien arbeiten. Zum Besipiel unregelmäßige Pflastersteine neben einem Sandweg neben einer Wiese – je leistungsfähiger die Hardware, desto mehr Texturvariationen stellt man zur Verfügung.

AFAIK funktioniert das nicht bei allen Formaten und sie dürfen nur die Größe melden die immer funktioniert.Das klingt logisch.

[Hauwech]

Wenn du deinen Designer sagst sie dürfen eine große Karte völlig frei zeichnen und kommst dann plötzlich damit das sie sich aber aus überlagerten Tiles zusammensetzten muss bringen die dich um.



AFAIK funktioniert das nicht bei allen Formaten und sie dürfen nur die Größe melden die immer funktioniert.

Nutzt das dann irgendjemand ueberhaupt aus? Bei OGL koennte ich es mir ja vorstellen, aber bei DX?

[Xmas]

32k-Texturen reichen sowieso nicht für große Karten, wenn man nicht noch mit Detailtexturing arbeitet. Selbst mit DXT1 nimmt die 32k-Map ca. 683 MiB ein. Mit dem Speicher wüsste ich besseres anzufangen.
Was hast du da denn gerechnet?

[aths]

Na:

32768*32768 // Größe
*4 // DXT1 (4 Bit)
/8 // in Byte
/1024 // in kiB
/1024 // in MiB
*1.3333333 // mit MIPs

[micki]

1. dxt kann man sehr gut packen, mit lzss bekommt man es oft auf <30%
2. man kann für sowas auch durchaus jpg nehmen, selbst bei guter kompression (<dxt) ist die bildqualität noch sehr hoch.
3. für sowas eignen sich auch wavelets, weil man die "mipmaps" schon von veronherain hat, natürlich hat wavelet/jpg den nachteil, dass es auf der graka unkomprimiert rumliegt


aber gerade jpg zu entpacken und auf die graka zu laden kann heutzutage viel fixer sein als die datenmengen von der platte zu ziehen (testet einfach mal die intelJPGlib). und man bekommt es am ende auf < 200MB (meinen berechnungen nach)

MfG
micki

[Expandable]

Was ich nicht verstehe: Wozu braucht man die riesige Textur überhaupt, inwiefern kann eine Textur fürs Terrain-Rendern verantwortlich sein? Hat das irgendwas mit Displacement Mapping zu tun? Und kann man mit einer 32000x32000 Pixel großen Textur wirklich kilometergroßes Gelände "darstellen"? Irgendwie kommt mir die Textur rein gefühlsmäßig dazu zu klein vor... bitte um Aufklärung ;)

Kann da denn keiner was dazu sagen? ;(

[Coda]

Die Details werden dann wohl noch durch zusätzliche Texturlayer ergänzt.