2048x2048 Texturen, wann?

[up¦²]

und machen die überhaupt Sinn?

[gsx-r]

Sicher

[Liquaron]

Sinnvoll? = ja

Wann? = Wenn die Hardware dafür bereit und genug verbreitet ist

[R300]

Werden doch schon längst in UT2003/4 verwendet. :rolleyes:
Nicht viele aber imerhin ein paar...

[up¦²]

Aha, das bedeudet, daß 256mb-Vga-Karten Sinn machen!

[daPoppie]

mhhh... kommt drauf an ob du mit af und aa spielst

[Raff]

Gibts schon in Spielen. UT2003 hat ein paar dieser extrem hochauflösenden Texturen, UT2004 dann wohl auch. Da merkt man mit einer 128MB-Grafikkarte dann schon, dass man mehr VRAM braucht ... ;)

MfG,
Raff

[aths]

und machen die überhaupt Sinn?Sicher sind die sinnvoll.

Man könnte einerseits argumentieren, da kaum jemand überhaupt mal 2048x1535 fährt, bräuchte man höchstens 2048-er Texturen. Doch für bestimmte Zwecke sind auch noch größere Texturen von Vorteil. Leider unterstützt die Radeon maximal 2048².

[Gast]

Gibts die nich schon seit jedi knight 1?
ich dächte man konnte da die texturengröße beliebig hoch einstellen, führt dann aber auch zu massiven leistungseinbußen

[GloomY]

Solange ich in z.B. 1024x768 zocke und kein Übersampling (AA oder AF) verwende, bringen mir 2048² Textures doch gar nichts. Dann wird doch eh eine kleine Mip-Map verwendet.

Selbstverständlich begrüße ich grundsätzlich Texturen mit hoher Auflösung, weil genau deswegen hohe Auflösungen (Übersampling) erst richtig gut aussehen =)

[Chris Lux]

Solange ich in z.B. 1024x768 zocke und kein Übersampling (AA oder AF) verwende, bringen mir 2048² Textures doch gar nichts. Dann wird doch eh eine kleine Mip-Map verwendet.

ach und du kommst nie einer texturierten wand zu nahe und betrachtest alles aus der entfernung? wozu brauchst du dann überhaupt bilineares filtern bei texturvergrößerung?

[RLZ]

Vielleicht sollte man auch dran denken, dass man erstens mehreren Texturen in einer grösseren speichern kann (spart einem eine Texturstateänderung) oder Texturen auch einfach als Datenspeicher nutzen kann.
2048er Texturen machen aber noch lange nicht überall Sinn und mit DXT1 komprimiert brauchen sie mit allen MipMaps noch keine 3 MB.

[Mr. Lolman]

ach und du kommst nie einer texturierten wand zu nahe und betrachtest alles aus der entfernung? wozu brauchst du dann überhaupt bilineares filtern bei texturvergrößerung?


ACK. Texturen können nie hoch genug aufgelöst sein.

[Mr. Lolman]

Leider unterstützt die Radeon maximal 2048².

Bei so hohen Auflösungen ists fast schon wieder praktisch 4 gekachelte 2048² Texturen zu verwenden, anstatt eine 4096². (*hint* Speicherverbrauch, der Textur samt Mipmaps <> gleichzeitig sichtbare Teile einer so hoch aufgelösten Textur)

Die dafür zusätzlich anfallende Polygonlast sollte auch kein Problem sein.

[GloomY]

ach und du kommst nie einer texturierten wand zu nahe und betrachtest alles aus der entfernung? wozu brauchst du dann überhaupt bilineares filtern bei texturvergrößerung?Ich komme quasie nie dazu, dass ich bilineares Filtern zur Texturvergrößerung brauche, wenn meine Abtastrate kleiner als die Originaltextur ist. Warum soll ich z.B. eine Textur mit 1024 Zeilen verwenden, wenn ich eh nur ca. 500 Mal pro Spalte abtaste? Dann kann ich auch gleich eine 512²Texture benutzen.

Höher aufgelöste Texturen als die Abtastrate bringen nur etwas, wenn dann höchstens ein Teil der Textur auf dem Bildschirm zu sehen ist. Bei 1024² Textures darf eben höchstens ein Viertel der Originaltextur auf dem Bildschirm zu sehen sein. Bei 2048² Texturen darf höchstens ein Sechzehntel der Textur auf dem Bildschirm zu sehen sein usw.

Deswegen brauchen Konsolen z.B. auch keine 2048x2048 Texturen. Der Fernseher bietet eh nur ~700x500 Auflösung, da würde die Originaltextur (ohne Überabtasten wie AA oder AF) eh nie verwendet sondern nur verkleinerte Mip-Maps.
ACK. Texturen können nie hoch genug aufgelöst sein.Was hast du bei heutiger Auflösung und AA / AF Einstellungen von einer 1000000x1000000 Textur?

[Chris Lux]

Ich komme quasie nie dazu, dass ich bilineares Filtern zur Texturvergrößerung brauche, wenn meine Abtastrate kleiner als die Originaltextur ist. Warum soll ich z.B. eine Textur mit 1024 Zeilen verwenden, wenn ich eh nur ca. 500 Mal pro Spalte abtaste? Dann kann ich auch gleich eine 512²Texture benutzen.

hallo? man kommt gerade in games texturen so nahe, dass man auch ausschnitte sieht und da sind hochauflösende texturen ein muss, schau dir doch doom3 mit seinen matschtexturen an. auch bei der texturierung von terrain usw kann man das gut gebrauchen.

edit: nochn gutes beispiel die texturierung von charakteren, siehe unreal engine 3 screens, da sind alle maps 2048x2048.

[RLZ]

hallo? man kommt gerade in games texturen so nahe, dass man auch ausschnitte sieht und da sind hochauflösende texturen ein muss, schau dir doch doom3 mit seinen matschtexturen an. auch bei der texturierung von terrain usw kann man das gut gebrauchen.
Da sind die Texturen ja auch wesentlich niedriger aufgelöst.
Die meisten Texturen in dem Spiel waren ausserdem voll ok.
Ein paar Ausnahmen gabs natürlich, die einem dann auch in der Erinnerung hängen bleiben...
Wenn man für eine Landschaft mal eine 2048^2 Textur zur Verfügung hat ists eigentlich schon ok. In der Nähe brauch man eh Detailtexturen, die dynamisch zusammengemischt werden müssen. Falls man die Landschaft noch grösser haben will, muss man halt kacheln und kann dadurch auch noch gleich in der Entfernung noch niedriger aufgelöste Texturen verwenden...

edit: nochn gutes beispiel die texturierung von charakteren, siehe unreal engine 3 screens, da sind alle maps 2048x2048.
Fragt sich nur was da in einer Textur alles drin ist.
Wahrscheinlich die komplette Texturierung des Models. Und da laufen keine 20 verschiedene gleichzeitig durch die Gegend.

[Spasstiger]

Texturen, die Geometriedaten speichern, z.B. Normal-Maps profitieren meiner Meinung nach immer von einer hohen Auflösung. Natürlich ist es sinnvoll, wenn dann die Diffuse Map ebenso hoch aufgelöst ist. 2048x2048 ist sehr sinnvoll, gerade für die Texturierung von Models.
Auch schön wäre es, wenn Wandtexturen feiner aufgelöst sind und man durch die Normal-Map einen richtig plastischen Eindruck von feinen Details auf der Wand bekommt. Denn Wandtexturen sind diejenigen, die man am häufigsten aus nächster Nähe zu sehen bekommt.
Wenn man aber so hoch aufgelöste Texturen einsetzt, sollte man dies konsequent durchziehen, damit die Grafik einen in sich stimmigen Eindruck macht. Und der konsequente Einsatz wird wohl sehr die Leistung drücken. Mal sehen, wie die Unreal 3 Engine mit hochauflösenden Bumpmaps bzw.Normalmaps performen wird.

[Mr. Lolman]

Was hast du bei heutiger Auflösung und AA / AF Einstellungen von einer 1000000x1000000 Textur?

Man könnte wunderbar ne Landschaftstextur drauf speichern. Ich hab schon für die Voodoo3 Karten ne 2048² Textur zusammen gefizzelt, damit ich ne, mit Bryce gerenderte Textur, in UT einfügen konnte. Hat ganz gut zum Polygongras gepasst. :naughty:

http://img27.exs.cx/img27/3470/Untitled-265.th.jpg (http://img27.exs.cx/my.php?loc=img27&image=Untitled-265.jpg)

[Xmas]

Ich komme quasie nie dazu, dass ich bilineares Filtern zur Texturvergrößerung brauche, wenn meine Abtastrate kleiner als die Originaltextur ist. Warum soll ich z.B. eine Textur mit 1024 Zeilen verwenden, wenn ich eh nur ca. 500 Mal pro Spalte abtaste? Dann kann ich auch gleich eine 512²Texture benutzen.

Höher aufgelöste Texturen als die Abtastrate bringen nur etwas, wenn dann höchstens die Teil der Textur auf dem Bildschirm zu sehen ist. Bei 1024² Textures darf eben höchstens ein Viertel der Originaltextur auf dem Bildschirm zu sehen sein. Bei 2048² Texturen darf höchstens ein Sechzehntel der Textur auf dem Bildschirm zu sehen sein usw.
Gehen wir mal von 1024x768 als Standardauflösung aus (obwohl mittlerweile der Schnitt eher höher liegt) aus, dazu trilinearer Filter, keine anisotrope Verzerrung. Dann wird eine 2048²-Textur bereits verwendet, sobald die Darstellung nicht mehr in ganzer Breite auf den Bildschirm passt. Aber genauso wichtig wie die Auflösung ist die Fläche die bedeckt werden soll sowie wie nahe man herankommt. Für ein "realistisches" Bild in First-Person-Darstellung reicht 1 Texel/cm² nicht, weil man zu nahe an Objekte herankommt. Weil der Speicherplatz häufig nicht ausreicht, muss man sich durch sich wiederholende Strukturen behelfen, aber diese sind leider sehr einfach zu erkennen. Hochauflösende Texturen sind als Lösung für diese Probleme in Zukunft genauso wichtig wie ausgefeilte Algorithmen, die Wiederholungen vermeiden.

Was hast du bei heutiger Auflösung und AA / AF Einstellungen von einer 1000000x1000000 Textur?
Sicher sind 1 Mio² overkill (außer vielleicht für eine Erd-Darstellung ;)), aber Supersampling und AF verstärken die Notwendigkeit von hochaufgelösten Texturen noch weiter.



Bei so hohen Auflösungen ists fast schon wieder praktisch 4 gekachelte 2048² Texturen zu verwenden, anstatt eine 4096². (*hint* Speicherverbrauch, der Textur samt Mipmaps <> gleichzeitig sichtbare Teile einer so hoch aufgelösten Textur)

Die dafür zusätzlich anfallende Polygonlast sollte auch kein Problem sein.
Dieses Problem wird ja glücklicherweise mit der nächsten, spätestens der übernächsten Generation verschwunden sein.

[GloomY]

Ich möchte nocheinmal betonen, dass ich nicht behauptet habe, dass z.B. 2048² Texturen unnötig seien. Ich habe gesagt, dass diese dann unnötig sind, solange die Abtastrate deutlich niedriger liegt. Ich bitte dies zu berücksichtigen. Ein Vergleich mit meinem ersten Posting bringt dies auch klar zum Ausdruck.

2048² Textures sind für moderne Spiele mit hohen Auflösungen und Überabtastungsverfahren wie AA und AF durchaus sinnvoll =)
hallo? man kommt gerade in games texturen so nahe, dass man auch ausschnitte sieht und da sind hochauflösende texturen ein muss, schau dir doch doom3 mit seinen matschtexturen an. auch bei der texturierung von terrain usw kann man das gut gebrauchen.

edit: nochn gutes beispiel die texturierung von charakteren, siehe unreal engine 3 screens, da sind alle maps 2048x2048.Alles richtig :) Ich sagte ja auch nur, dass man bei entsprechend niedriger Abtastrate keine Verwendung findet. Bei entsprechend hoher Abtastrate ergibt das eben durchaus Sinn.

Die effektive Abtastrate ist aber ein Parameter, den man umbedingt beachten muss. Per se ergeben hoch aufgelöste Textures weit überhalb der Abtastrate keinen Sinn. Die Notwendigkeit für hohe Texturen wird durch deren Nutzen und damit in der Abtastrate limitiert.
Man könnte wunderbar ne Landschaftstextur drauf speichern. Ich hab schon für die Voodoo3 Karten ne 2048² Textur zusammen gefizzelt, damit ich ne, mit Bryce gerenderte Textur, in UT einfügen konnte. Hat ganz gut zum Polygongras gepasst. :naughty:

http://img27.exs.cx/img27/3470/Untitled-265.th.jpg (http://img27.exs.cx/my.php?loc=img27&image=Untitled-265.jpg)Und? Kannst du all diese Information aus der Textur / den Texturteilen auf dem Bildschirm darstellen? Nein.
Gehen wir mal von 1024x768 als Standardauflösung aus (obwohl mittlerweile der Schnitt eher höher liegt) aus, dazu trilinearer Filter, keine anisotrope Verzerrung. Dann wird eine 2048²-Textur bereits verwendet, sobald die Darstellung nicht mehr in ganzer Breite auf den Bildschirm passt. Aber genauso wichtig wie die Auflösung ist die Fläche die bedeckt werden soll sowie wie nahe man herankommt. Für ein "realistisches" Bild in First-Person-Darstellung reicht 1 Texel/cm² nicht, weil man zu nahe an Objekte herankommt.Hmm, meinst du 1 Texel / Pixel? Oder was hat die reale auf dem Bildschirm dargestellte Fläche mit den Texeln zu tun?
Sicher sind 1 Mio² overkill (außer vielleicht für eine Erd-Darstellung ;)), aber Supersampling und AF verstärken die Notwendigkeit von hochaufgelösten Texturen noch weiter.Full Ack. Bei entsprechender Wahl von Auflösung, AA und AF ergibt sich eine Notwendigkeit :)
Dieses Problem wird ja glücklicherweise mit der nächsten, spätestens der übernächsten Generation verschwunden sein.Öhm? Bitte mehr input ;)

[Xmas]

Hmm, meinst du 1 Texel / Pixel? Oder was hat die reale auf dem Bildschirm dargestellte Fläche mit den Texeln zu tun?
Ich meine 1 cm² auf der simulierten Wand. Schau dich einfach um, du siehst mit Sicherheit Details, die kleiner als 1 cm² sind. Nun stell dir eine simulierte Umgebung in "Mensch-Maßstab" vor. Wenn da ein Texel für 1 cm² einer simulierten Wand steht, ist das bei näherer Betrachtung immer noch recht grob. Als wäre deine echte Wand mit 1 cm²-Kacheln bedeckt. Insofern braucht z.B. die wirklich gute Darstellung eines 5m*3m Wandgemäldes in einer simulierten Welt auch weit jenseits 500x300 Texel.

Öhm? Bitte mehr input ;)
Speichervirtualisierung. Spätestens mit WGF Pflicht, bei 3DLabs schon Realität.

[GloomY]

Ich meine 1 cm² auf der simulierten Wand. Schau dich einfach um, du siehst mit Sicherheit Details, die kleiner als 1 cm² sind. Nun stell dir eine simulierte Umgebung in "Mensch-Maßstab" vor. Wenn da ein Texel für 1 cm² einer simulierten Wand steht, ist das bei näherer Betrachtung immer noch recht grob. Als wäre deine echte Wand mit 1 cm²-Kacheln bedeckt. Insofern braucht z.B. die wirklich gute Darstellung eines 5m*3m Wandgemäldes in einer simulierten Welt auch weit jenseits 500x300 Texel.Korrekt. Aber dazu musst du natürlich erstmal höher als 500x300 (ich sprach eigentlich von 700x500, aber egal ;)) abtasten. Das ist quasie das aller erste, was man ändern muss, ansonsten ergibt eine höher aufgelöste Textur kaum (keinen) Sinn.

Können wir uns vielleicht darauf einigen, dass man für realitätsgetreue Abbildung sowohl hoch aufgelöste Texturen als auch eine hohe Abtastrate (Auflösung, AA, AF) benötigt? =)
Speichervirtualisierung. Spätestens mit WGF Pflicht, bei 3DLabs schon Realität.Das bedeutet, dass sich nicht alle Inhalte einer Textur gleichzeitig im Graka-Speicher befinden müssen sondern nach extern ausgelagert werden können? So eine Art Paging wie man es von CPUs bereits kennt?

[Mr. Lolman]

Und? Kannst du all diese Information aus der Textur / den Texturteilen auf dem Bildschirm darstellen? Nein.

Das war ja der Trick, im Fall der Voodoo3. Ich hab auch noch die ganze Textur auch. Für GraKas, die die Rendern können... :naughty:


(mittlerweile eh schon alle)

[Xmas]

Können wir uns vielleicht darauf einigen, dass man für realitätsgetreue Abbildung sowohl hoch aufgelöste Texturen als auch eine hohe Abtastrate (Auflösung, AA, AF) benötigt? =)
Zur hohen Abtastrate trägt aber eine geringe Entfernung zum Objekt sehr viel bei. Es braucht keine "hohe" Auflösung (800x600 ist absolut ausreichend), um "hochaufgelöste" Texturen (2048² und höher) sinnvoll einzusetzen, wenn man sich Objekten in realistischer Art und Weise nähern kann.


Das bedeutet, dass sich nicht alle Inhalte einer Textur gleichzeitig im Graka-Speicher befinden müssen sondern nach extern ausgelagert werden können? So eine Art Paging wie man es von CPUs bereits kennt?
Genau das.

[Aquaschaf]

Nehmen wir an ich habe bei einem RTS-Spiel ein Set von Terrain-Texturen das aus 256 Tiles á 128x128 Pixel. Es ist schneller (und beim Erstellen der Texturen etwas praktikabler) diese Tiles in eine einzige 2048x2048er Textur zu packen als in 256 einzelne Texturen.

Abgesehen davon ist es doch unsinnig von der Bildschirmauflösung auf eine maximal sinnvolle Größe von Texturen zu schließen. Wenn man ein ganz einfaches Beispiel nimmt; man will eine Kiste texturieren die nur aus einem simplen Quader besteht. Eine 2048²-Textur wird verwendet und jede Seite der Kiste soll anders aussehen. Die Kiste hat 8 Seiten. Bleibt für jede Seite ein Bereich von 512² Pixel auf der Textur. Da zieht man schon den "vollen Nutzen" aus der 2048²-Textur wenn die Kiste bei einer Bildschirmauflösung von 1024x768 etwa 1/4 der Bildfläche bedeckt.
Der Fall, dass alle Informationen die eine Textur enthält auf einmal auf dem Bildschirm sichtbar sind ist in der Praxis eher unwahrscheinlich.

[GloomY]

Zur hohen Abtastrate trägt aber eine geringe Entfernung zum Objekt sehr viel bei. Es braucht keine "hohe" Auflösung (800x600 ist absolut ausreichend), um "hochaufgelöste" Texturen (2048² und höher) sinnvoll einzusetzen, wenn man sich Objekten in realistischer Art und Weise nähern kann.Ist es realistisch anzunehmen, dass sich eine so große Textur (2048²) nur zu etwa einem Achtel auf dem Bildschirm befindet? Andernfalls ist der Nutzen wie oben erläutert eben nicht wirklich vorhanden.

Natürlich ist das auch vom Einsatzzweck (also der Software) abhängig, daher meine fragenden Anmerkungen...

Und dass die Hardware mit ihren Fähigkeiten lieber ein Stückchen voraus sein sollte anstatt hinterher zu hinken, ist natürlich auch klar :)
Genau das.OT: Wäre es sinnvoll, einen Artikel zum Thema virtuelle Speicherverwaltung zu schreiben? Ich hatte das eigentlich schon relativ lange im Hinterkopf (u.a. wegen den nicht endenden Diskussionen bzgl. 64 Bit CPUs und OS). Wenn das "demnächst" eh bei den Grakas ansteht, dann würde sich sowas doch anbieten, oder? Soll ich dazu mal Leo fragen?

Und ja, ich habe vor mir mehr Mühe bei der Struktur, Schreibweise usw. zu geben als beim letzten Artikel...

Nehmen wir an ich habe bei einem RTS-Spiel ein Set von Terrain-Texturen das aus 256 Tiles á 128x128 Pixel. Es ist schneller (und beim Erstellen der Texturen etwas praktikabler) diese Tiles in eine einzige 2048x2048er Textur zu packen als in 256 einzelne Texturen.Okay, wenn es der Organisation hilft, warum nicht!? Das wäre ein Argument.
Abgesehen davon ist es doch unsinnig von der Bildschirmauflösung auf eine maximal sinnvolle Größe von Texturen zu schließen.Wie weiter oben ausgeführt, ist es das eben nicht. Bei zu niedriger Abtastrate werden eh nur die Mip-Maps, d.h. die verkleinerte Textur verwendet. Dann kann man auch gleich von Anfang an eine kleinere Textur verwenden und sich den Platz im Graka-RAM sparen.
Wenn man ein ganz einfaches Beispiel nimmt; man will eine Kiste texturieren die nur aus einem simplen Quader besteht. Eine 2048²-Textur wird verwendet und jede Seite der Kiste soll anders aussehen. Die Kiste hat 8 Seiten. Bleibt für jede Seite ein Bereich von 512² Pixel auf der Textur.
Da zieht man schon den "vollen Nutzen" aus der 2048²-Textur wenn die Kiste bei einer Bildschirmauflösung von 1024x768 etwa 1/4 der Bildfläche bedeckt.
Moment, für jede Fläche der Kiste kann man eine eigene Textur verwenden. Das ist nichts Neues, das kann jede Hardware seit den aller ersten 3D-Beschleunigern. Man braucht keine großen Texturen, nur um für unterschiedliche Flächen / Poligone usw. unterschiedliche Texturen zu verwenden.
Der Fall, dass alle Informationen die eine Textur enthält auf einmal auf dem Bildschirm sichtbar sind ist in der Praxis eher unwahrscheinlich.Und wozu brauche ich dann die viele Information aus der hoch aufgelösten Textur?

[RLZ]

Und wozu brauche ich dann die viele Information aus der hoch aufgelösten Textur?
Textur und Shaderwechsel sind böse. ;)
Deswegen lieber etwas mehr in eine Textur als weniger aus vielen kleinen Texturen.
Am Beispiel Würfel: Lieber eine grosse Textur um den ganzen Würfel, als 6 Texturwechsel.
Oder am Beispiel Model: Lieber die ganze Texturierung aus einer Textur (deswegen auch so gross) als anzufangen 30-40 kleine Fitzeltexturen draufzupappen.
Egal wieviel man davon jetzt sieht oder nicht.
Normalerweise verwendet man bei so grossen Texturen eh sinnvollerweise Kompression und dann wird die Textur eh angenehm klein.

[Mr. Lolman]

Textur und Shaderwechsel sind böse. ;)
Deswegen lieber etwas mehr in eine Textur als weniger aus vielen kleinen Texturen.


Aber ob man das so verallgemeinern kann? Eine 2048er Textur braucht ~2MB.
Eine 4096er schon ~10MB. Was spräche dagegen 4 2048er Texturen zu nehmen, wo es dann höchstwahrscheinlich sogar den Fall gäbe, dass von den 4 Tiles für das Darstellen der Szene oft nur 2-3 auf einmal benötigt werden => Gesparter GraKaspeicher bei geringfügigst höherem Geometrycount..


/edit: Auch die Voodoo5 mochte (fps mässig betrachtet) 64x256² Texturen mehr als eine 2048²... :eek:


Und? Kannst du all diese Information aus der Textur / den Texturteilen auf dem Bildschirm darstellen? Nein.


...eben deswegen, da vgl zu der "Tiletechnik" die ganze 2048² Textur im Speicher gehalten werden muss. Auch die Teile, die gerade nicht benötigt werden.

[Demirug]

Aber ob man das so verallgemeinern kann? Eine 2048er Textur braucht ~2MB.
Eine 4096er schon ~10MB. Was spräche dagegen 4 2048er Texturen zu nehmen, wo es dann höchstwahrscheinlich sogar den Fall gäbe, dass von den 4 Tiles für das Darstellen der Szene oft nur 2-3 auf einmal benötigt werden => Gesparter GraKaspeicher bei geringfügigst höherem Geometrycount..


/edit: Auch die Voodoo5 mochte (fps mässig betrachtet) 64x256² Texturen mehr als eine 2048²... :eek:




...eben deswegen, da vgl zu der "Tiletechnik" die ganze 2048² Textur im Speicher gehalten werden muss. Auch die Teile, die gerade nicht benötigt werden.

Ja, man kann das heute verallgemeinern. Jeder Texturewechsel bricht den Batch auf. Allerdings sind Textureatlase (so nennt man diese Technik) nicht immer ganz unproblematisch. Ich sage nur AA ohne Centroid.

[RLZ]

Aber ob man das so verallgemeinern kann? Eine 2048er Textur braucht ~2MB.
Eine 4096er schon ~10MB. Was spräche dagegen 4 2048er Texturen zu nehmen, wo es dann höchstwahrscheinlich sogar den Fall gäbe, dass von den 4 Tiles für das Darstellen der Szene oft nur 2-3 auf einmal benötigt werden => Gesparter GraKaspeicher bei geringfügigst höherem Geometrycount..
Verallgemeinern kann man garnichts.
Überhalb von 2048 machts keinen Sinn mehr, bei der aktuellen Speichergrösse.
Da wird der Overhead zu gross.
Deswegen hat ATI wohl auch die Grenze bei 2048 gesetzt. Spart ihnen Arbeit und schützt die Entwickler vor sich selbst. ;)
Selbst komplette Models sind damit gut genug texturiert.

Das Problem was und wieviel zusammengefasst wird, müssen die Designer unter sich ausmachen. Jeder Statechange produziert CPU-Last. Wenn noch Grafikkartenspeicher übrig ist, aber man schon CPU-limitiert ist, wäre es ein Fehler Texturen nicht zusammenzufassen. Falls einem andererseits der Grakaspeicher ausgeht und die CPU langweilt sich noch, kann man mit kleinen Texturen anrücken (dieser Fall kommt normal nicht vor...).
Allgemein sollte man aber soviele Texturwechsel sparen wie nur möglich. Deswegen sollte auch jede gute Engine vorm Rendern nach Shader+Texturen sortieren.

[aths]

Verallgemeinern kann man garnichts.
Überhalb von 2048 machts keinen Sinn mehr, bei der aktuellen Speichergrösse.
Da wird der Overhead zu gross.
Deswegen hat ATI wohl auch die Grenze bei 2048 gesetzt. Spart ihnen Arbeit und schützt die Entwickler vor sich selbst. ;)
Selbst komplette Models sind damit gut genug texturiert.Was ist jedoch, wenn man in 1600x1200 spielt und Supersampling aktiviert, und das Spiel Render2Texture nutzt? Ok, da die Radeons treiberseitig kein Supersampling anbieten kommt man dort nicht zu diesem Problem, als solches besteht es aber imo, wenn man sich auf maximal 2048 festlegt.

[RLZ]

Was ist jedoch, wenn man in 1600x1200 spielt und Supersampling aktiviert, und das Spiel Render2Texture nutzt? Ok, da die Radeons treiberseitig kein Supersampling anbieten kommt man dort nicht zu diesem Problem, als solches besteht es aber imo, wenn man sich auf maximal 2048 festlegt.

Ich glaub das hast du dir schon selbst beantwortet.
Atm besteht dieses Problem noch nicht. Schon garnicht mit 128 MB als Standard.
Die nächste Generation wird es wohl, wenn ein Entwickler denn Bedarf anmeldet, schon können.

[Xmas]

Ist es realistisch anzunehmen, dass sich eine so große Textur (2048²) nur zu etwa einem Achtel auf dem Bildschirm befindet? Andernfalls ist der Nutzen wie oben erläutert eben nicht wirklich vorhanden.
Wie oben erläutert, reicht es bei der üblichen Auflösung 1024x768 mit üblichem trilinearem Filter schon aus, dass die Textur gerade nicht mehr in voller Breite auf den Bildschirm passt. Und ja, diese Situation ist ziemlich realistisch, insbesondere wenn man berücksichtigt dass auch einige gerne in 1600x1200 spielen.


Aquaschaf,
Kiste mit 8 Seiten? ;)

[Gast]

http://img45.exs.cx/img45/4116/2515.gif

[BlackArchon]

Äh bitte? :confused:

[Aquaschaf]

Aquaschaf,
Kiste mit 8 Seiten? ;)

Ich meine natürlich eine Kiste im ..äh vierdimensionalem Raum ;)

Aber egal, was ich meine sollte klar sein. Mit weniger - dafür höher aufgelösten - Texturen zu arbeiten ist meistens praktikabler, und meiner persönlichen Erfahrung nach auch performanter.

[Aquaschaf]

Äh bitte? :confused:

Ich nehme an ein Würfel mit 8 Seiten :D

[Ailuros]

http://l2.espacenet.com/espacenet/viewer?PN=GB2400778&CY=de&LG=de&DB=EPD

[mapel110]

http://l2.espacenet.com/espacenet/viewer?PN=GB2400778&CY=de&LG=de&DB=EPD

bisschen Text dabei bitte. =)

[pajofego]

Für numerische Berechnungen sind sogar 2048^2 zu wenig, dann lieber nvidias 4096^2 :biggrin:

Mir ist durchaus bewusst, dass es sich hierbei um eine Randanwendung handelt.

Gruss

pajofego

[Xmas]

bisschen Text dabei bitte. =)
Kurzbeschreibung:
Das Patent beschreibt eine Methode, aus einer Height Map "on-the-fly" Normalen zu berechnen. Das ist ganz interessant als Kompressionsmethode (man hat nur einen Höhenwert gegenüber mindestens 2 Werten bei Normalen, außerdem braucht Offset Mapping die Höhenwerte sowieso).
Das kann man natürlich im Shader machen, aber Hardware, die dies automatisch macht, ist auch recht praktisch.

[Coda]

Aber ob man das so verallgemeinern kann? Eine 2048er Textur braucht ~2MB. Eine 4096er schon ~10MB. Was spräche dagegen 4 2048er Texturen zu nehmen, wo es dann höchstwahrscheinlich sogar den Fall gäbe, dass von den 4 Tiles für das Darstellen der Szene oft nur 2-3 auf einmal benötigt werden => Gesparter GraKaspeicher bei geringfügigst höherem Geometrycount..
Ich weiß nicht wie du rechnest aber 2048x2048x4 und 4096x4096 ist genau das gleiche vom Speicherbedarf.

[aths]

Kurzbeschreibung:
Das Patent beschreibt eine Methode, aus einer Height Map "on-the-fly" Normalen zu berechnen. Das ist ganz interessant als Kompressionsmethode (man hat nur einen Höhenwert gegenüber mindestens 2 Werten bei Normalen, außerdem braucht Offset Mapping die Höhenwerte sowieso).
Das kann man natürlich im Shader machen, aber Hardware, die dies automatisch macht, ist auch recht praktisch.Gar keine dumme Idee. NV40 hat heute schon NRM_PP, vielleicht setzt sich eine TMU durch, die einen Normalenvektor aus einer Heightmap sampeln kann. FP16 sollte dort vorerst genügend, in FP16 erscheint mir das auch ohne zu großen Aufwand machbar.

[Ailuros]

Kurzbeschreibung:
Das Patent beschreibt eine Methode, aus einer Height Map "on-the-fly" Normalen zu berechnen. Das ist ganz interessant als Kompressionsmethode (man hat nur einen Höhenwert gegenüber mindestens 2 Werten bei Normalen, außerdem braucht Offset Mapping die Höhenwerte sowieso).
Das kann man natürlich im Shader machen, aber Hardware, die dies automatisch macht, ist auch recht praktisch.

Auf das was ich mit dem Link zielte ist dass IHVs (egal mit welchen Architekturen sie sich beschaeftigen) sich auch weiterhin kluge Sparmassnahmen ausdenken werden um staendig steigende Werte zu ermoeglichen bzw. effizienter zu behandeln.

IMHO behandelt das Patent eines der Felder die mehr an Wichtigkeit in der absehbaren Zukunft gewinnen werden, als so mancher synthetischer Benchmark der letzten Zeit mit verrueckt hohem VS load zu vorhersagen wagt.

[GloomY]

Wie oben erläutert, reicht es bei der üblichen Auflösung 1024x768 mit üblichem trilinearem Filter schon aus, dass die Textur gerade nicht mehr in voller Breite auf den Bildschirm passt. Und ja, diese Situation ist ziemlich realistisch, insbesondere wenn man berücksichtigt dass auch einige gerne in 1600x1200 spielen.Bist du so freundlich und erklärst mir nocheinmal, warum eine 2048² Textur bereits bereits bei 1024x768 vollkommen auf dem Bildschirm dargestellt wird?

Was hat das mit dem erwähnten trilinearen Filter zu tun?

[Xmas]

Bist du so freundlich und erklärst mir nocheinmal, warum eine 2048² Textur bereits bereits bei 1024x768 vollkommen auf dem Bildschirm dargestellt wird?

Was hat das mit dem erwähnten trilinearen Filter zu tun?
Der trilineare Filter mischt zwei Mipmap-Stufen, die eine mit einem Texel : Pixel-Verhältnis größer 1, bei der anderen ist es kleiner 1.
Bei einer Textur, die gerade nicht mehr so in der Breite auf 1024x768 passt, würde man also zwischen den Stufen 1024² und 2048² filtern, sofern vorhanden.

[GloomY]

Der trilineare Filter mischt zwei Mipmap-Stufen, die eine mit einem Texel : Pixel-Verhältnis größer 1, bei der anderen ist es kleiner 1.Ah :) Dieses Detail war mir nicht in diesem Umfang bekannt / bewusst. Danke für die Erklärung. =)
Bei einer Textur, die gerade nicht mehr so in der Breite auf 1024x768 passt, würde man also zwischen den Stufen 1024² und 2048² filtern, sofern vorhanden.Dann ist dies natürlich klar. :)

Okay, dann her mit den 2048² oder sogar 4096² Textures ;)

[Gast]

Ich weiß nicht wie du rechnest aber 2048x2048x4 und 4096x4096 ist genau das gleiche vom Speicherbedarf.

Ich meinte eigentlich auch 2.5MB. Tatsächlich sinds aber 2.66MB bei den 2048² Texturen und 10.64MB bei den 4096² Texturen...