Archiv verlassen und diese Seite im Standarddesign anzeigen : Detail Texturing
GPUs sind nicht gerade dafür ausgelegt, dass Detail-Texturen genutzt werden. Das wundert mich mit der Zeit immer mehr. Wenn ich z. B. NFSMW auf der PS2 spiele, ärgere ich mich oft über diese Lowres-Texturen. Gerade aus der Nähe sieht das schlecht aus.
Für Detail-Texturen reicht in der Regel ein Graustufen-Format. DXT5-Alpha bietet eine clevere Methode, 8-Bit-Graustufen auf 4 bpt zu komprimieren. Für Detailtexturen sollte das reichen.
Im gleichen Zuge müsste ein Rasterizer abhängig vom LOD ein Textursampling übergehen können, oder aus Gründen der Einfachheit abhängig vom LOD einen neutralen Wert zurückliefern (anstatt wirklich zu samplen) denn Detail-Texturen braucht man ja in der Entfernung nicht.
Lange Rede, kurzer Sinn: Eine speziell auf Detail-Texturing optimierte GPU böte entsprechend effizentes Rendering von Detail-Texturen. Und die sind ein hervorrangendes Mittel um bei knappem Texturspeicher die Vergrößerungs-Unschärfe zu überdecken.
Ich kann dazu zwar null komma nichts sagen, habe aber eine andere Frage: Wieviele Semester Informatik muss ich durchnehmen, um zu verstehen, wovon du hier redest? Bzw.: Mit 16 ist es in Ordnung, wenn ich mir jetzt ziemlich dumm vorkomme, oder? :usad:
AnarchX
2006-01-28, 23:27:58
Kann man Detail-Textures überhaupt noch vernünftig einsetzen mit Normalmaps und Derivaten, die einen Tiefeneindruck erzeugen.
Theoretisch müssten die Detailt-Textur mit verzerrt werden, sonst würde es etwas seltsam ausschauen.
Um zu verstehen wovon er redet, reicht auch ein Hauptschulabschluss. Man muss nur das Interesse, einen Internetanschluss und viel Zeit mitbringen.
Ganon
2006-01-28, 23:40:37
Es reicht auch schon das Spiel DeusEX und dann mal ein Screenshot mit und ohne Detail-Texturen. Hab bisher kein Spiel gesehen wo der Unterschied dermaßen groß ist (OK. Kenne jetzt auch nicht soooo viele Spiele). ^_^
robbitop
2006-01-28, 23:53:54
Max Payne. Wobei die Detail Texturen in diesem Spiel zu regelmäßig sind und sich zu stark wiederholen.
Problematisch ist, dass eine Detailtextur natürlich eine weitere Texturschicht bedeutet und somit wieder Füllrate kostet.
Warum sollten Detailtexturen nicht für Bumpmapping geeignet sein?
Lange Rede, kurzer Sinn: Eine speziell auf Detail-Texturing optimierte GPU böte entsprechend effizentes Rendering von Detail-Texturen. Und die sind ein hervorrangendes Mittel um bei knappem Texturspeicher die Vergrößerungs-Unschärfe zu überdecken.
Was willst du für solche Detailtexturen am einer GPU optimieren?
Ist doch in einem Shader mit einfachsten Mitteln ohne viel Rechenaufwand zu realisieren.
Imo ist dies ausserdem der falsche Weg.
Algorithmen wie Wang-Tiling oä. sind die Zukunft. Und genau dort bietet D3D10 auch endlich den Vorteil auf viele Texturen zugreifen zu können ohne sich mit Texturatlanten rumärgern zu müssen, die bei AF Ärger machen und generell zusätzliche Rechenleistung kosten.
robbitop
2006-01-29, 00:04:15
Texturfilterung mit ner ShaderALU? Schön für nen bilinear gefilterten Texel verschlingt das viel zuviele Takte. Oder wie stellst du dir das vor?
Texturfilterung mit ner ShaderALU? Schön für nen bilinear gefilterten Texel verschlingt das viel zuviele Takte. Oder wie stellst du dir das vor?
Könntest du quoten vorauf sich deine Frage bezieht?
Ich geh mal davon aus du meinst den Zugriff auf viele Texturen unter D3D10.
Das lässt sich mit einem Wort beantworten: Texturearrays
Unter DX9 wäre Filtering im Shader eine Möglichkeit gewesen, die Probleme zu umgehen. Eine andere wäre es um jede Textur einen entsprechend breiten Rand zu lassen. Das macht aber wiederum Ärger bei Mipmaps...
Edit: Noch eine Möglichkeit ist das Erstellen von "seamless" Texturatlanten. In GPU-Gems 2 ist da ein nettes Kapitel dazu.
robbitop
2006-01-29, 00:20:28
Könntest du quoten vorauf sich deine Frage bezieht?
Tut mir leid.
Ich geh mal davon aus du meinst den Zugriff auf viele Texturen unter D3D10.
Das lässt sich mit einem Wort beantworten: Texturearrays
Unter DX9 wäre Filtering im Shader eine Möglichkeit gewesen, die Probleme zu umgehen.
Kostet das nicht unheimlich viele Takte? Eine lineare Interpolation enthällt ja bereits einige mathematische Grundoperationen (MUL und ADD iirc). Und dann das ganze 2x. Da wäre ein Takt für die TMU vieleicht billiger?
oder bin ich auf dem völlig falschen Pfad?
Kostet das nicht unheimlich viele Takte?
Texturarrays unter D3D10 und XBox360-DX kosten afaik garnichts.
Eine lineare Interpolation enthällt ja bereits einige mathematische Grundoperationen (MUL und ADD iirc). Und dann das ganze 2x. Da wäre ein Takt für die TMU vieleicht billiger?
oder bin ich auf dem völlig falschen Pfad?
Filtering inkl AF im Shader ist in Spielen tötlich. Allein die Texturzugriffen kosten unheimlich viel Zeit, wobei hier Fetch4 eine Abmilderung bringen würde.
Für HQ-Rendering gibts auch Shader mit Third-Order-Filtering. Über die Geschwindigkeit redet man da aber besser nicht ;)
Ich hab damals bei Oasen viel rumprobiert um die Texturen nicht zu sehr zu "strechen" um sie nicht unscharf werden zu lassen und dabei Wiederholungen zu verstecken.
Am Ende hatte ich heftiges Blending zwischen Texturen auf Basis von Noise, Normalen, Höhe etc..
http://graphics.cs.uni-sb.de/~morfiel/oasen/gallery/038%20small%20village.jpg
Wang-Tiling wäre im Nachhinein gesehen die bessere Lösung bzw eine sinnvolle Ergänzung gewesen.
Fetch4 bringt doch da gar nichts, das ist ja nur für Einkanal-Texturen nützlich.
Fetch4 bringt doch da gar nichts, das ist ja nur für Einkanal-Texturen nützlich.
Oh. Naja ich hatte es mir nicht so genau angeschaut.
Dachte es geht auf alle Texturen.
Ich kann dazu zwar null komma nichts sagen, habe aber eine andere Frage: Wieviele Semester Informatik muss ich durchnehmen, um zu verstehen, wovon du hier redest? Bzw.: Mit 16 ist es in Ordnung, wenn ich mir jetzt ziemlich dumm vorkomme, oder? :usad:Es geht darum, bei Texturvergrößerung zu verhindern dass man nur noch unscharfen Brei sieht. Dazu kann man die normale Textur mir einer spezielle Textur verrechnen. Diese spezielle Textur, die Detailmap, ist zwar hoch aufgelöst aber in der Ausdehnung recht klein und wird entsprechend oft wiederholt. Ein primitives Beispiel gibts hier: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2895784&postcount=10
Dort wird als Detailmap Rauschen genutzt. Wenn man aber zum Beispiel für Holzkisten eine Detailmap braucht, sollten diese kein Rauschen, sondern feinste typische Holzmaserungen zeigen. Rauschen tut es allerdings oft ganz gut: Auf Mauerwerk, auf der Straße ... bei vielen Texturen ließe sich Rauschen als Detailmap ganz gut verwenden.
Da das Auge auf Helligkeiten empfindlicher als auf Farbe reagiert, reicht es in der Regel, die Detailmap als Graustufentextur vorliegen zu haben, welche also entweder abdunkelt oder aufhellt. Nun braucht man diese Detailmap nur, wenn die zu verbessernde Texturoberfläche Texturvergrößerung zeigt. Aktuelle GPUs sind darauf optimiert, für alle Pixel innerhalb eines Dreiecks dieselben Rechnungen durchzuführen und sehen nicht vor, Abhängig von der Vergrößerungsstufe einer Textur eine zweite Textur zu sampeln.
Würden sie das vorsehen und würde es breit unterstützte 1-Kanal-Texturkomprimierung geben, wäre das Detailtexturing erheblich schneller als es heute ist.
Kann man Detail-Textures überhaupt noch vernünftig einsetzen mit Normalmaps und Derivaten, die einen Tiefeneindruck erzeugen.
Theoretisch müssten die Detailt-Textur mit verzerrt werden, sonst würde es etwas seltsam ausschauen.Bumpmapping würde Detailtexturing ohnehin ersetzen. Die PS2 kann kein Bumpmapping, viele ältere 3D-Karten auch nicht. Mit Detailmapping hätte man zwar eine statische, aber trotzdem detailreich texturierte Oberfläche ohne massiv Texturspeicher zu verbrauchen.
Was willst du für solche Detailtexturen am einer GPU optimieren?
Ist doch in einem Shader mit einfachsten Mitteln ohne viel Rechenaufwand zu realisieren.
Imo ist dies ausserdem der falsche Weg.
Algorithmen wie Wang-Tiling oä. sind die Zukunft. Und genau dort bietet D3D10 auch endlich den Vorteil auf viele Texturen zugreifen zu können ohne sich mit Texturatlanten rumärgern zu müssen, die bei AF Ärger machen und generell zusätzliche Rechenleistung kosten.Das geht auch schon mit DX9 SM3 (bzw. SM2 Profil 2_A) (siehe Xmas' Diplomarbeit) (nur eben nicht so effektiv wie mit Texture-Arrays, klar.) Xmas hat glaube ich anhand der Index-Map die letzten MIP-Stufen der riesigen (virtuellen) Textur erzeugt damit man keine Probleme bekommt, wenn ein Tile kleiner 1 Pixel wird, dann wird die MIP genommen und nicht das Tiling genutzt.
Das ist die Zukunft, gleich Highres-Texturen zu nutzen, und Tiling zu nutzen um den Speicherverbrauch nicht explodieren zu lassen. Mittels Boundary Cut kann man aus gleichmäßig belichteten Fotos auch schöne kachelbare Texturen herausschneiden. Xmas hat da experimentiert, zum Beispiel Wang-kachelbare Wiesen- oder Pflasterstein-Texturen zu erzeugen, teilweise sind die Ergebnisse erstaunlich gut. In der Vergangheit war das nicht drin, eine bessere Detailmap-Unterstützung wäre aber drin gewesen. Imo wäre das ziemlich sinnvoll.
Bumpmapping würde Detailtexturing ohnehin ersetzen. Die PS2 kann kein Bumpmapping, viele ältere 3D-Karten auch nicht. Mit Detailmapping hätte man zwar eine statische, aber trotzdem detailreich texturierte Oberfläche ohne massiv Texturspeicher zu verbrauchen.
Das verstehe ich nicht.
Inwiefern hat Bumpmapping (Dot3 oder Paralax) irgendwas mit Detailtexturen zu tun? Selbst wenn man Bumpmapping für die Beleuchtung verwendet, kann man die Basistextur doch immer noch ganz normal mit der Helligkeitswert der Detailtextur multiplizieren und das Ergebnis bei der Beleuchtung verwenden.
Wieso gibts überhaupt multitexturing. man könnte doch denn ganzen kram in eine Textur mixen? Zelda oot hatte zb. einfache plastische Texturen
das ist wieder sowas logisches wie overdraw, das übersteigt das hirn eines homo sapiens.
stav0815
2006-01-29, 12:24:22
Das verstehe ich nicht.
Inwiefern hat Bumpmapping (Dot3 oder Paralax) irgendwas mit Detailtexturen zu tun? Selbst wenn man Bumpmapping für die Beleuchtung verwendet, kann man die Basistextur doch immer noch ganz normal mit der Helligkeitswert der Detailtextur multiplizieren und das Ergebnis bei der Beleuchtung verwenden.
Gilt dies nur für Bumpmapping oder auch für andere effekte?
Wieso gibts überhaupt multitexturing. man könnte doch denn ganzen kram in eine Textur mixen? Zelda oot hatte zb. einfache plastische Texturen
das ist wieder sowas logisches wie overdraw, das übersteigt das hirn eines homo sapiens.
Wie soll das bei Detailtexturen funktionieren? Wenn man die Detailtextur vorher mit der Originaltextur verrechnet, dann bräuchte man ja doch eine höhere Auflösung für die Textur um alle Details zu speichern. Genau das soll ja verhindert werden.
gut dann wäre dies EINE berechtigte ausnahme, bei bumpmapping und so nicht, müßte mich mal bei wikipedia schlaumachen. das unrealwasser gefiel mir besser wie dieser shaderkram
Legolas
2006-01-29, 14:19:04
gut dann wäre dies EINE berechtigte ausnahme, bei bumpmapping und so nicht, müßte mich mal bei wikipedia schlaumachen. das unrealwasser gefiel mir besser wie dieser shaderkram
Das tolle an Bumpmapping ist ja gerade, daß sich das Aussehen mit dem Einblickwinkel verändert. Wie du das mit vorberechneten Texturen erreichen willst, das musst du mal erklären.
zeckensack
2006-01-29, 14:30:04
Wieso gibts überhaupt multitexturing. man könnte doch denn ganzen kram in eine Textur mixen? Zelda oot hatte zb. einfache plastische Texturen
das ist wieder sowas logisches wie overdraw, das übersteigt das hirn eines homo sapiens.Zelda: OoT nutzt massiv Multitexturing. Ich habe die Logs von einem N64-Emulator hier.
ja die haben auch animierte (prozedurale?) texturen, meine eher so das die texturen durch hohen kontrast oder vorgerendert recht 3d aussehen
ja die haben auch animierte (prozedurale?) texturen, meine eher so das die texturen durch hohen kontrast oder vorgerendert recht 3d aussehen
Wie willst du das denn machen?
Beim normalen Bumpmapping (also Normalmapping) werden in der Normalmap die Normalen für jeden Texel gespeichert. Wenn du das in einer Textur machen würdest, dann wären ja nochmal mindestens 3 zusätzliche Kanäle pro Textur fällig und der Speicherverbrauch wäre wieder der gleiche.
ja die haben auch animierte (prozedurale?) texturen, meine eher so das die texturen durch hohen kontrast oder vorgerendert recht 3d aussehen
Klar kannst du die Beleuchtung gleich in die Textur packen und somit das ganze recht plastisch aussehen lassen. Nur dummerweise ist dann die Position der Lichtquelle zur Textur festgelegt, und Specular Lighting kannst du so auch nicht machen, denn das hängt vom Betrachtungswinkel ab.
Ist die Position der Lichtquelle zur Textur festgelegt, kannst du schon mal keine dynamische Beleuchtung mehr machen. Und vor allem kannst du die Texturen nur dort wiederverwenden, wo auch dieselben Beleuchtungsbedingungen herrschen.
Stell dir vor du hast eine Mauertextur mit vorberechneter Beleuchtung, bei der das Licht von einer Seite her einfällt. Dann kannst du diese Textur nicht für eine Mauer verwenden, die senkrecht zur Lichtquelle steht.
Das verstehe ich nicht.
Inwiefern hat Bumpmapping (Dot3 oder Paralax) irgendwas mit Detailtexturen zu tun? Selbst wenn man Bumpmapping für die Beleuchtung verwendet, kann man die Basistextur doch immer noch ganz normal mit der Helligkeitswert der Detailtextur multiplizieren und das Ergebnis bei der Beleuchtung verwenden.Statt Detailtexturing kann man sozusagen "Detail-Bumpmapping" verwenden.
Wieso gibts überhaupt multitexturing. man könnte doch denn ganzen kram in eine Textur mixen? Zelda oot hatte zb. einfache plastische Texturen
das ist wieder sowas logisches wie overdraw, das übersteigt das hirn eines homo sapiens.Wenn du alles in eine Textur mixen willst, müsstest du alle möglichen Kombinationen im Texturspeicher ablegen. Und das kannst du knicken. Mit Multitexturing spart man nicht nur Speicher, man ist auch flexibler.
Wie soll das bei Detailtexturen funktionieren? Wenn man die Detailtextur vorher mit der Originaltextur verrechnet, dann bräuchte man ja doch eine höhere Auflösung für die Textur um alle Details zu speichern. Genau das soll ja verhindert werden.Für die Detailmap reicht in der Regel ein Graustufen-Kanal, das ist die erste "Komprimierung". Jener Kanal ließe sich zudem auf 4 Bit pro Texel komprimieren (was leider nur wenige Grakas unterstützen), das wäre die zweite Komprimierung. Die Detailmap wird außerdem gekachelt verwendet. Sie ist zwar hoch aufgelöst, aber klein, und wird x-fach neben- und untereinandergesetzt. Das wäre die effektivste "Komprimierung". Sie soll ja nur dafür sorgen, dass die Vergrößerungsunschärfe der Basemap überdeckt wird.
Spasstiger
2006-01-29, 19:07:36
Ich kann dazu zwar null komma nichts sagen, habe aber eine andere Frage: Wieviele Semester Informatik muss ich durchnehmen, um zu verstehen, wovon du hier redest? Bzw.: Mit 16 ist es in Ordnung, wenn ich mir jetzt ziemlich dumm vorkomme, oder? :usad:
Ein Diplom-Informatiker muss das genauso wenig verstehen könnte, im Grunde lernt ein Informatiker an der Uni im Rahmen der Vorlesungen sowieso nix über Hardware und deren genauer Funktionsweise.
Tybalt
2006-01-29, 21:10:00
Was kann ich mir denn unter einer Detail Textur vorstellen?
Im Wiki steht ja nichts darüber.
Ich gehe einfach mal davon aus, daß es eine Art von Multitexturing ist um bessere Details darzustellen. Normal wäre es zB eine normale Textur und dann noch eine für die Beleuchtung. Was macht denn die Detailtextur?
Was kann ich mir denn unter einer Detail Textur vorstellen?
Im Wiki steht ja nichts darüber.
Ich gehe einfach mal davon aus, daß es eine Art von Multitexturing ist um bessere Details darzustellen. Normal wäre es zB eine normale Textur und dann noch eine für die Beleuchtung. Was macht denn die Detailtextur?Das erste mal sah ich Detailtexturing in Unreal. Aber auch Max Payne nutzt es. Ohne Detailtextur:
http://www.dudv.de/files/3dcf/__1.jpg
Recht ist die Kachelwand-Textur ziemlich unscharf.
http://www.dudv.de/files/3dcf/__2.jpg
Die Detailmap wirkt, wie es sein sollte, nur subtil: Die Kacheln zeigen kleine Unregelmäßigkeiten. Das lenkt von der Unschärfe der Basemap ab.
Rampage 2
2006-01-29, 21:57:06
Max Payne. Wobei die Detail Texturen in diesem Spiel zu regelmäßig sind und sich zu stark wiederholen.
Problematisch ist, dass eine Detailtextur natürlich eine weitere Texturschicht bedeutet und somit wieder Füllrate kostet.
Warum sollten Detailtexturen nicht für Bumpmapping geeignet sein?
Eben. Und da heutige Spiele massiv Texturschichten benutzen (D3 7 Schichten, soweit ich weiß), wäre DetailTexturing kostbare Verschwendung - denn man könnte anstatt Detailtexturing z.B. eine Bumpmap oder Shadow- bzw. Lightmap einsetzen was viel sinnvoller wäre - und die Funktion der Detail
Textures könnte man durch extrem hoch aufgelöste Texturen mit einem extrem feinen LOD-System ausgleichen - wird ja auch langsam Zeit dass, die 256MB+ Grafikspeicher auch endlich ausgenutzt werden.
Aquaschaf
2006-01-29, 22:16:13
D3 7 Schichten, soweit ich weiß
Wie kommst du da auf 7?
Eben. Und da heutige Spiele massiv Texturschichten benutzen (D3 7 Schichten, soweit ich weiß), wäre DetailTexturing kostbare Verschwendung - denn man könnte anstatt Detailtexturing z.B. eine Bumpmap oder Shadow- bzw. Lightmap einsetzen was viel sinnvoller wäreLightmaps hat man sowieso, zumindest wenn man kein Bumpmapping hat. Doom 3 hat Bumpmapping.
Sieben Schichten? Wenn man sieben Schichten hätte (was bei Doom 3 glaube ich nicht der Fall ist) wäre eine zusätzliche Schicht kaum der Rede wert.
- und die Funktion der Detail Textures könnte man durch extrem hoch aufgelöste Texturen mit einem extrem feinen LOD-System ausgleichen - wird ja auch langsam Zeit dass, die 256MB+ Grafikspeicher auch endlich ausgenutzt werden.Detailmaps sind ja gerade dazu da, dass man ohne extrem hoch aufgelöste Texturen auskommt. Die extrem hoch aufgelösten Texturen verbrauchen auch extrem viel Speicherplatz.
Bumpmapping würde Detailtexturing ohnehin ersetzen. Die PS2 kann kein Bumpmapping, viele ältere 3D-Karten auch nicht. Mit Detailmapping hätte man zwar eine statische, aber trotzdem detailreich texturierte Oberfläche ohne massiv Texturspeicher zu verbrauchen.
hatte splinter cell 3 auf der PS2 nicht eine art von bumpmapping verwendet?
Rampage 2
2006-01-29, 23:01:45
Lightmaps hat man sowieso, zumindest wenn man kein Bumpmapping hat. Doom 3 hat Bumpmapping.
Sieben Schichten? Wenn man sieben Schichten hätte (was bei Doom 3 glaube ich nicht der Fall ist) wäre eine zusätzliche Schicht kaum der Rede wert.
Detailmaps sind ja gerade dazu da, dass man ohne extrem hoch aufgelöste Texturen auskommt. Die extrem hoch aufgelösten Texturen verbrauchen auch extrem viel Speicherplatz.
Ja, aber bei DetailTexturen - wie bei UT1 und UT2004 merke ich das Banding wenn ich z.B. einer Wand näher komme, d.h. es ist das selbe wie billiniares Texturfiltering wo man die Bänder sieht (im Gegensatz zu triliniares Filtering - da sieht man kein Banding) - weil viel zu wenig Abstufungen sind - und dann vergeht der Realitätseffekt. Man musste also zig DetailMaps (20-30 Stück) haben um feine Abstufung zu erreichen (und selbst dann wird das menschliche Auge das noch merken). Doch bei sehr hoch aufgelösten Texturen mit einem sehr feinen LOD-System mit triliniarer Filterung kann man kein Banding sehen.
Deine Idee hätte erst dann Sinn, wenn man ein DT-System hätte wo man keine Abstufungen sehen kann, wenn man einer WAnd kontinuierlich näher
kommt.
Deine Idee hätte erst dann Sinn, wenn man ein DT-System hätte wo man keine Abstufungen sehen kann, wenn man einer WAnd kontinuierlich näher
kommt.
Gibts. Nennt sich trilineares Filtern.
micki
2006-01-30, 00:46:18
ich finde detailtexturen sind eine total blödsinnige verschwendung heutzutage. es gibt zwar viele spiele die das nutzen, aber 1. muss es eine textur sein, die sich zig mal wiederhollt und 2. eine bei der man kein pattern erkennt. man macht also ein dezentes rauschen. dafür verschwendet man kostbare texturbandbreite!!! und dann schreit an jeder ecke immerwieder ein fanboy "die neue graka von xyz hat soviel rechenpower im pixelshader,da kann man texturen prozedural errechnen und braucht bald keine echten" ohne zu wissen was er da labert.
wieso berechnet man da nicht das rauschen mittels gpu (im ps)? mit perlinnoiseartigen verfahren hat man automatisch das mipmapping drinne und man spart sich die bandbreite, das wäre meiner meinung nach der bessere weg.
Da hast du recht, aber noch ist der Texture-Lookup wohl günstiger.
Das wird sich auch so schnell nicht ändern.
Demirug
2006-01-30, 07:35:29
Da hast du recht, aber noch ist der Texture-Lookup wohl günstiger.
Vorallem weil alle Noise Verfahren derzeit ja selbst mehrer Lookups brauchen.
micki
2006-01-30, 09:29:29
eine 8x8 texture für perlin noise (graustufen) bekommt man locker in 16 const-register rein.
eXistence
2006-01-30, 10:18:20
(bin mir nicht sicher, obs zum Thema passt, falls nicht, bitte in einen extra Thread auslagern :) )
John Carmack ließ kürzlich durchblicken, woran er gerade arbeitet und da gehts wohl auch um "unique texturing", also die Abschaffung von gekachelten Texturen:
Are you working on a new rendering engine?
Yeah. For the last year I’ve been working on new rendering technologies. It comes in fits and starts. Our internal project is not publicly announced on there. We’re doing simultaneous development on Xbox 360, PC, and we intend to release on PS3 simultaneously as well, but it’s not a mature enough platform right now for us to be doing much work on.
Game engines have their own certain look to them. Quake 3 era games all have a similar lighting and texture model, so do Doom 3 era games, from the high-poly bump maps. Can you predict what the engine is going to look like from the start?
Usually when I set out making the technical decisions I don’t know how it’s going to turn out. A lot of it is working out what works, and what ideas come to you. It is worthwhile mentioning, as you said, that there’s a characteristic look to the new engine, and it’s going to be centred around Unique Texturing.
This is an argument I get into with people year after year. Every generation, someone comes up and says something like “procedural and synthetic textures and geometry are going to be the hot new thing. I’ve heard it for the last three console generations – it’s not been true and it’s never going to be true this generation too. It’s because management of massive data-sets is always the better thing to do. That’s what a lot of the technologies we are working on centre around – both the management for the real time use of it, and the management of the efficient content creation side of it. I think that’s going to give a dramatically better look than what we’re seeing in this generation.
Can you describe how it will look, in a layperson term.
When you start seeing screenshots of games designed like this, it’ll be obvious that they’re of a new generation. I’m not sure how much it comes through, but Quake Wars: Enemy Territory, the game Splash Damage are working on, that uses an intermediate half-way technique, the Megatexture stuff I did originally. They’ve really gone and run with that. Some of their screenshots are really starting to show the promise of unique texturing on everything. We’ve got an interesting combination of techniques on that – they did a procedural offline synthetic synthesis to generate the basis of the terrain, and I built some technology to let artists dynamically stamp things into all the channels in game. We’re starting to see some really, really spectacular results out of this, as everyone climbs up the skill curve of using these new tools. The technology we’re working on here at id takes that a step further with a terrain texturing system is applied throughout for everything.
das ganze Interview gibts hier: http://www.rage3d.com/board/showthread.php?t=33841622
Was er da andeutet ist ja noch recht wage, aber hat einer der Gurus vielleicht schon ne ungefähre Vorstellung was das genau sein soll und wie das funktionieren soll?
Klar kannst du die Beleuchtung gleich in die Textur packen und somit das ganze recht plastisch aussehen lassen. Nur dummerweise ist dann die Position der Lichtquelle zur Textur festgelegt, und Specular Lighting kannst du so auch nicht machen, denn das hängt vom Betrachtungswinkel ab.
das ergebnis steht steht in keiner relation zum aufwand. dann hat man wie bei f.e.a.r einen leeren raum und ruckelt trotzdem rum und wundert sich, das tomb raider mal mit großer weitsicht, wo sich der ganze level um den spieler dreht, mal in software lief
Was er da andeutet ist ja noch recht wage, aber hat einer der Gurus vielleicht schon ne ungefähre Vorstellung was das genau sein soll und wie das funktionieren soll?
Um etwas genaues zu sagen ist das wirklich zu wage.
Meine Ideen wären:
- Wang-Tiling oä. auf allen Objekten
- Kombination von Texturen anhand von Indexmaps (wird bei Terrain schon länger gemacht)
- etwas aufwendigere Textursynthese zur Laufzeit mit Caching
Interessant dazu ist noch diese (http://research.microsoft.com/projects/ParaTexSyn/) Idee.
Imo kann man viel mit Caching machen.
Für diese Engine (http://www.fl-tw.com/Infinity/infinity_media.php) werden zB aufwendig zur Laufzeit Texturtiles berechnet und können dann durch "einen" Texturzugriff gesampelt werden. Man blendet nur noch einmal und nicht jedes Frame. Wenn man die Textur nicht mehr braucht wird sie wieder gelöscht. Problem dabei ist nur der starke Speicherverbrauch.
das ergebnis steht steht in keiner relation zum aufwand. dann hat man wie bei f.e.a.r einen leeren raum und ruckelt trotzdem rum und wundert sich, das tomb raider mal mit großer weitsicht, wo sich der ganze level um den spieler dreht, mal in software lief
FEAR tut ja auch noch viel mehr. Moderne Grafikkarten haben kein allzu großes Problem damit, alle Oberflächen mit einer handvoll Texturschichten zu rendern.
Und es ist nun mal so, dass die Schritte Richtung Photorealismus immer kleiner werden. Mit anderen Worten: um von schlechter Grafik zu guter Grafik zu kommen braucht es weit weniger Aufwand als von guter Grafik zu sehr guter Grafik zu kommen.
micki
2006-01-30, 14:58:09
ein proof of concept, mal in meiner mittagspause zusammengehackt, also ohne jegliche optimierung.
einfach in den fxcomposer stecken
static int STEPS = 4;
#define SOFTSAMPLE
float4x4 WvpXf : WorldViewProjection;
float NoiseIntesity : NoiseIntensity
<
string UIWidget = "slider";
float UIMin = 0.01;
float UIMax = 1.0;
float UIStep = 0.01;
string UIName = "Noise Intensity";
> = 1.0;
float Repead : NoiseIntensity
<
string UIWidget = "slider";
float UIMin = 0.0;
float UIMax = 16.0;
float UIStep = 1.;
string UIName = "UV Repead";
> = 1.0;
struct VertexInput {
float3 Position : POSITION;
float4 UV : TEXCOORD0;
};
struct VertexOutput {
float4 HPosition : POSITION;
float2 UV : TEXCOORD0;
};
/*********************************************************/
/*********** vertex shader *******************************/
/*********************************************************/
VertexOutput VS_PerlinNoise(VertexInput IN) {
VertexOutput Out;
Out.HPosition = mul(float4(IN.Position,1.f),WvpXf);
Out.UV = IN.UV.xy;
return Out;
}
/*********************************************************/
/*********** pixel shader ********************************/
/*********************************************************/
float NoiseSampleAt(float2 UV)
{
const float4 Mask[4] = { {1.f, 0.f, 0.f,0.f},
{0.f, 1.f, 0.f,0.f},
{0.f, 0.f, 1.f,0.f},
{0.f, 0.f, 0.f,1.f}};
const float4 Data[16] = { {0.9f, 0.3f, 0.25f,0.3f},
{0.3f, 0.1f, 0.35f,0.2f},
{0.8f, 0.3f, 0.85f,0.7f},
{0.1f, 0.8f, 0.75f,0.8f},
{0.8f, 0.3f, 0.65f,0.4f},
{0.7f, 0.7f, 0.85f,0.5f},
{0.5f, 0.2f, 0.95f,0.3f},
{0.8f, 0.7f, 0.85f,0.0f},
{0.3f, 0.3f, 0.95f,0.1f},
{0.3f, 0.8f, 0.75f,0.9f},
{0.1f, 0.5f, 0.85f,0.5f},
{0.7f, 0.5f, 0.35f,0.7f},
{0.1f, 0.3f, 0.15f,0.8f},
{0.5f, 0.4f, 0.05f,0.3f},
{0.1f, 0.3f, 0.05f,0.4f},
{0.8f, 0.5f, 0.55f,0.8f}};
return dot(Data[int(UV.y*8.f)*2+int(UV.x*2)],Mask[int(frac(UV.x*2)*4.f)]);
}
float NoiseSoftSampleAt(float2 UV)
{
float s00 = NoiseSampleAt(frac(UV));
float s10 = NoiseSampleAt(frac(UV+float2(1.f/8.f,0.f)));
float s01 = NoiseSampleAt(frac(UV+float2(0.f,1.f/8.f)));
float s11 = NoiseSampleAt(frac(UV+float2(1.f/8.f,1.f/8.f)));
float dx = frac(UV.x*8.f);
float dy = frac(UV.y*8.f);
return lerp(lerp(s00,s01,dy),lerp(s10,s11,dy),dx);
}
float NoiseSample(float2 UV)
{
float Intensity=0.5f;
float c=0.f;
for(int a=0;a<STEPS;a++)
{
#ifdef SOFTSAMPLE
c+=NoiseSoftSampleAt(UV)*Intensity;
#else
c+=NoiseSampleAt(frac(UV))*Intensity;
#endif
Intensity*=0.5f;
UV*=2.f;
}
return c;
}
float4 PS_PerlinNoise(VertexOutput IN) : COLOR {
return NoiseSample(IN.UV*Repead)*NoiseIntesity;
}
technique OnePass
{
pass p0
{
VertexShader = compile vs_3_0 VS_PerlinNoise();
PixelShader = compile ps_3_0 PS_PerlinNoise();
}
}
MfG
micki
Und wieviele Instruktionen sind das? ;)
Expandable
2006-01-30, 23:39:23
Zum Thema Detail-Texturen: Die könnt Ihr in der Timeshift-Demo bewundern - mit Bump Mapping und allem, was sonst so dazugehört ;) Dadurch sehen die Texturen echt klasse aus!
micki
2006-01-31, 00:00:39
Und wieviele Instruktionen sind das? ;)
je nach einstellung 80-500auf einer gffxII laut fxcomposer ohne jegliche optimierung.
das ganze natürlich noch viel besser, was aber krass ist, ist dass die 5950 dabei extrem langsam wäre laut fxcomposer.
micki
2006-01-31, 11:50:52
wie wäre es mit programmierbaren sampleshadern, sodass man sie für prozedurale dinge missbrauchen kann :)
ich finde detailtexturen sind eine total blödsinnige verschwendung heutzutage. es gibt zwar viele spiele die das nutzen, aber 1. muss es eine textur sein, die sich zig mal wiederhollt und 2. eine bei der man kein pattern erkennt. man macht also ein dezentes rauschen. dafür verschwendet man kostbare texturbandbreite!!! 4 Bit pro Texel? Das ist wenig.
und dann schreit an jeder ecke immerwieder ein fanboy "die neue graka von xyz hat soviel rechenpower im pixelshader,da kann man texturen prozedural errechnen und braucht bald keine echten" ohne zu wissen was er da labert.
wieso berechnet man da nicht das rauschen mittels gpu (im ps)? mit perlinnoiseartigen verfahren hat man automatisch das mipmapping drinne und man spart sich die bandbreite, das wäre meiner meinung nach der bessere weg.Das Rauschen muss deterministisch sein. Eine Textur zu sampeln geht schneller, als Rauschen zu erzeugen.
micki
2006-02-01, 01:01:25
4 Bit pro Texel? Das ist wenig.
sie ist vermutlich größer als der texturecache und deswegen senkt sie die leistung.
Das Rauschen muss deterministisch sein. Eine Textur zu sampeln geht schneller, als Rauschen zu erzeugen.
wenn man eine dedizierte einheit dafür hätte (so wie du das extra für detailtexturen machen möchtet) wäre es nicht langsammer, vermutlich eher schneller.
sie ist vermutlich größer als der texturecache und deswegen senkt sie die leistung.4 Bit pro Texel ist sehr wenig. Da ohnehin mehrere Texturen im Spiel sind, machen die 4 Bits auch nichts mehr aus. Klar sinkt die fps-Rate, aber die Grafikqualität steigt. Selbst wenn man unkomprimierte 1-Kanal-8-Bit-Texturen trilinear und 2x anisotrop sampelt, sind das nur 4 Takte. Wie lange würde die arithmetische Generierung von deterministischem Rauschen dauern? Man wäre dann auch eingeschränkt und könnte z. B. keine Holzmaser-Details haben, es sei denn auch hierfür schreibt man einen Shader. Der ist aber kaum für weniger als 4 Takte zu bekommen.
wenn man eine dedizierte einheit dafür hätte (so wie du das extra für detailtexturen machen möchtet) wäre es nicht langsammer, vermutlich eher schneller.Ich hätte gerne Einheiten gehabt, die LOD-abhängig das Sampling einsparen könnten und eine 1-Kanal-Texturkomprimierung.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.