auch Architektur-Visualisierungen finden zunehmend in Echtzeitgrafik-Engines statt. Ich habe bereits 8K-Texturen in Quest3D und 4K-Texturen in der CryEngine2 verwendet. Hardware-komprimiert ist das kein Problem.
Eine ideale Auflösung scheint mir: 1px = 1mm >> 8x8 Meter für Wand- und Bodenflächen stellen für die meisten begehbaren Außen- und Innenbereiche eine ausreichend abwechslungsreiche und detaillierte Grundtextur dar.
Das kommende Direct3D 11 unterstützt 16x16K (0.5mm/px : ~8m !). Die kommende id Tech 5 Engine streamt komprimierte Megatexturen und verschlingt dank 'Full Surface Unique Texturing' mit 20+ GB das Vielfache des Grafikspeichers in einer Szene. Andere Engines bald ebenso, spätestens in 3..5 Jahren sind 2K-Grundtexturen veraltet, wogegen mir 8K..16K-Texturen ein für heutige Bildschirme stabiles Maß verheißen.
Zwei Punkte erscheinen mir wichtig vorgeschlagen zu werden, um bei hochauflösenden Texturen in Echtzeit-Engines in Zukunft unnötige Abstriche in der Qualität zu verhindern:
1. Größe 8192px statt 8000px ...weil die Texturen für die Grafik-Engines sonst leicht hochgerechnet werden müssen ...was einen leichten Qualitätsverlust bedeutet, zudem in der Summe zusätzliche technische Arbeitsschritte im Entwurfsprozess und doppelt belegten Speicherplatz
2. ein quadratisches Seitenverhältnis 8:8 statt bspw. 8:6 oder 8:4 ...weil bei länglichen Texturen bspw. eine einfache Cube-Projektion (z.B. 8x4x4m) auf ein komplexes Modell immer in Textur-Verzerrungen in einer Ebene resultiert (horizontal/vertikal), was nur aufwändig zu umgehen ist (durch: a. mehrfache UV-Sets, was manche Echtzeit-Engines (noch) nicht beherrschen (Grafikfehler: alle Flächen werden gemäß UV-Set-1 verzerrt), oder b. Aufspalten komplexer Modelle in horizontale/vertikale Elemente für jeweilige breite/hohe Map-Projektion (Haken: Kollisionsabfrage/Physik-Engine braucht in der Regel wasserdicht geschlossene Modelle, d.h. also extra Modelle, Speicherverschwendung und zusätzliche zähflüssige Arbeitsschritte für jede Geometrieänderung), oder c. aufwändig angepasste UV-Koordinaten, welche bei ständigen Änderungen unterworfenenen, komplexen (Architektur-)Modellen vergleichsweise unpraktisch sind).
Im Visualisierung- und Spielesektor gewinnt Echtzeit-Rendering gegenüber Pre-Rendering mit jeder Grafikchip-Generation an Boden. Ich denke, die Ansprüche an eine realtime-engine taugliche Textur sind von der Zielgröße und Auflösung her heute schon identisch denen einer pre-rendering Textur (8k = 8m). Schön wäre, wenn die Textur außerdem:
a. eine Zweierpotenz misst sowie
b. gleichseitig proportioniert ist.
In froher Erwartung auf weitere erstklassige Releases und Danke für das Gehör!
Raphael
Vielen Dank für die detailierten Informationen, Raphael! Zugegeben, das ganze Feld der Echtzeit-Visualisierung ist uns noch etwas fremd, daher schätzen wir solchen Input sehr. Wir werden definitiv in Zukunft stärker an diesen Anwendungsbereich denken und unsere Produkte entsprechend optimieren; evtl.als separate Produktlinie.
You guys should look into the potentials offered by the texture market for Second Life users. There is a great demand for quality textures for Second Life. Have a look at this site and do a search for texture to get an idea: www.xstreet.com
However, there are some requisites to appeal to Second Life builders:
- textures must be low cost
- textures size must be "power of 2" (that is: 256 x 256, 512 x 512, 512 x 256, 1024 x 1024, etc). The most diffused size is 512 x 512, with textures of 1024 x 1024 or 1024 x 512 to be used only when it can't be avoided. In an online virtual environment the size of textures makes a big difference as it may cause lots of lag.
A word of warning: Second Life is not a game, it's a virtual platform which can be used for many purposes, including gaming and serious projects. Architects use it to explore its possibilities, universities and organizations use it for remote education and different projects. Many folks use it to run their businesses.
Hi,
auch Architektur-Visualisierungen finden zunehmend in Echtzeitgrafik-Engines statt. Ich habe bereits 8K-Texturen in Quest3D und 4K-Texturen in der CryEngine2 verwendet. Hardware-komprimiert ist das kein Problem.
Eine ideale Auflösung scheint mir: 1px = 1mm >> 8x8 Meter für Wand- und Bodenflächen stellen für die meisten begehbaren Außen- und Innenbereiche eine ausreichend abwechslungsreiche und detaillierte Grundtextur dar.
Das kommende Direct3D 11 unterstützt 16x16K (0.5mm/px : ~8m !). Die kommende id Tech 5 Engine streamt komprimierte Megatexturen und verschlingt dank 'Full Surface Unique Texturing' mit 20+ GB das Vielfache des Grafikspeichers in einer Szene. Andere Engines bald ebenso, spätestens in 3..5 Jahren sind 2K-Grundtexturen veraltet, wogegen mir 8K..16K-Texturen ein für heutige Bildschirme stabiles Maß verheißen.
Zwei Punkte erscheinen mir wichtig vorgeschlagen zu werden, um bei hochauflösenden Texturen in Echtzeit-Engines in Zukunft unnötige Abstriche in der Qualität zu verhindern:
1. Größe 8192px statt 8000px ...weil die Texturen für die Grafik-Engines sonst leicht hochgerechnet werden müssen ...was einen leichten Qualitätsverlust bedeutet, zudem in der Summe zusätzliche technische Arbeitsschritte im Entwurfsprozess und doppelt belegten Speicherplatz
2. ein quadratisches Seitenverhältnis 8:8 statt bspw. 8:6 oder 8:4 ...weil bei länglichen Texturen bspw. eine einfache Cube-Projektion (z.B. 8x4x4m) auf ein komplexes Modell immer in Textur-Verzerrungen in einer Ebene resultiert (horizontal/vertikal), was nur aufwändig zu umgehen ist (durch: a. mehrfache UV-Sets, was manche Echtzeit-Engines (noch) nicht beherrschen (Grafikfehler: alle Flächen werden gemäß UV-Set-1 verzerrt), oder b. Aufspalten komplexer Modelle in horizontale/vertikale Elemente für jeweilige breite/hohe Map-Projektion (Haken: Kollisionsabfrage/Physik-Engine braucht in der Regel wasserdicht geschlossene Modelle, d.h. also extra Modelle, Speicherverschwendung und zusätzliche zähflüssige Arbeitsschritte für jede Geometrieänderung), oder c. aufwändig angepasste UV-Koordinaten, welche bei ständigen Änderungen unterworfenenen, komplexen (Architektur-)Modellen vergleichsweise unpraktisch sind).
Im Visualisierung- und Spielesektor gewinnt Echtzeit-Rendering gegenüber Pre-Rendering mit jeder Grafikchip-Generation an Boden. Ich denke, die Ansprüche an eine realtime-engine taugliche Textur sind von der Zielgröße und Auflösung her heute schon identisch denen einer pre-rendering Textur (8k = 8m). Schön wäre, wenn die Textur außerdem:
a. eine Zweierpotenz misst sowie
b. gleichseitig proportioniert ist.
In froher Erwartung auf weitere erstklassige Releases und Danke für das Gehör!
Raphael
Vielen Dank für die detailierten Informationen, Raphael! Zugegeben, das ganze Feld der Echtzeit-Visualisierung ist uns noch etwas fremd, daher schätzen wir solchen Input sehr. Wir werden definitiv in Zukunft stärker an diesen Anwendungsbereich denken und unsere Produkte entsprechend optimieren; evtl.als separate Produktlinie.
You guys should look into the potentials offered by the texture market for Second Life users. There is a great demand for quality textures for Second Life. Have a look at this site and do a search for texture to get an idea: www.xstreet.com
However, there are some requisites to appeal to Second Life builders:
- textures must be low cost
- textures size must be "power of 2" (that is: 256 x 256, 512 x 512, 512 x 256, 1024 x 1024, etc). The most diffused size is 512 x 512, with textures of 1024 x 1024 or 1024 x 512 to be used only when it can't be avoided. In an online virtual environment the size of textures makes a big difference as it may cause lots of lag.
A word of warning: Second Life is not a game, it's a virtual platform which can be used for many purposes, including gaming and serious projects. Architects use it to explore its possibilities, universities and organizations use it for remote education and different projects. Many folks use it to run their businesses.