Prozedurale Texturen aktueller Stand?

[Gast]

Durch die News über Raytracing auf Computerabse (http://www.computerbase.de/news/allgemein/forschung/2007/september/idf_quake_4_raytraced_hd_90_fps/) bin ich auf das Thema Procedural Textures (http://www.projectlan.de/artikel/Revolution_der_virtuellen_Welten__Procedural_Textures-special-1-32.htm) gestoßen. Die Auflösung und Qualität der Texturen ist beeindruckend. Nachteil soll der hohe Bedarf an RAM sein. Wie weit ist man denn inzwischen mit dieser Technologie? Wird das schon irgendwo (Applikationen, Spiele) produktiv eingesetzt?

[rotalever]

Die Frage ist auch immer, ob diese on-the-fly auf der Grafikkarte genutzt werden sollen oder pre-gerendert werden um dann wie herkömmliche Texturen genutzt zu werden. Für ersteres habe ich letztens das hier gesehen:
http://research.microsoft.com/~hoppe/ravg_tr.pdf

[Der Gast von eben]

Oh danke für die prompte Antwort. Ich steck noch nicht so tief drin in dem Stoffgebiet und von daher danke für das Infomaterial. Schau ich mir gleich an. Ich hatte schon befürchtet, dass das Thema wieder vom Tisch ist.

[tokugawa]

Bei der letzten GDC wurde irgendeine Middleware vorgestellt, mit der man Texturen prozedural generieren kann, wobei ich nicht mehr weiß ob das on-the-fly in Realtime oder halt beim normalen Modellierprozess geschieht (ich glaub aber letzteres). Hab leider auch schon den Namen des Produkts vergessen...

[rotalever]

Da gibt es doch dieses zeugs von Allegorithmic, oder wie das heißt.

[Gast]

zu prozeduralen texturen sollte man sich das hier mal ansehen:
http://www.theprodukkt.com/
und vorallem kkrieger:
http://www.theprodukkt.com/kkrieger

ein shooter mit recht guter grafik - und das alles in nur 96kB.
in der exe findet sich keine einzige fertige textur.
diese werden prozedural erzeugt.
bzw. wurden die schritte zur erzeugung der texturen hinterlegt.
beim starten werden alle texturen also erstmal errechnet.
das selbe wird auch mit der geometrie und auch mit dem sound gemacht.
deswegen dauerts immer etwas länger bis das teil startet...

einen blick ists allemal wert.

[Gast]

ach ja...
fast vergessen...
deren tool zum erzeugen der texturen:
http://www.werkkzeug.com/

[Gast]

Dankö, werd gleich mal bisschen rumbasteln damit. :)

[Roi Danton]

Demos benutzen im allg prozedurale Texturen, such z.B. mal nach Farbrausch.

Infinity (Weltraumsim) benutzt IMHO auch on-the-fly Prozeduraltexturen für die Planetendarstellung (mehrere Milliarden Sternensystem geplant): http://www.fl-tw.com/Infinity/

[Spasstiger]

Infinity (Weltraumsim) benutzt IMHO auch on-the-fly Prozeduraltexturen für die Planetendarstellung (mehrere Milliarden Sternensystem geplant): http://www.fl-tw.com/Infinity/
Anders wäre das auch gar nicht vernünftig zu speichern. Ist halt eine Form von besonders effizienter Kompression, die sich aber eben nicht auf alle Texturen anwenden lässt.

Ich bin mal gespannt, ob zukünftige Grafikkarte spezielle Einheiten für prozedurale Texturen parallel zu den TMUs haben, die eventuell genauso schnell oder sogar schneller arbeiten.

[Aquaschaf]

Ich bin mal gespannt, ob zukünftige Grafikkarte spezielle Einheiten für prozedurale Texturen parallel zu den TMUs haben, die eventuell genauso schnell oder sogar schneller arbeiten.

Wie soll man dafür spezielle Einheiten bauen?

[Spasstiger]

Wie soll man dafür spezielle Einheiten bauen?
Shadereinheiten parallel zu den TMUs oder an die TMUs angekoppelt, so dass man prozedurale Texturen auch im Singlepass rendern kann. Oder geht das auch so?

[Xmas]

"im Singlepass rendern"? Wenn du damit meinst die Textur on-the-fly zu berechnen, warum sollte man das nicht mit allgemein verwendbaren Shadereinheiten tun?

[rotalever]

Mal ne Frage zu prozeduralen Texturen on-the-fly:
Wie verhindert man da eigentlich das Flimmern, da ja keine Mipmaps erzeugt werden? Bzw. wie kann der Shader eine niedriger aufgelöste Textur vernünftig berechnen?

[_DrillSarge]I[]

Mal ne Frage zu prozeduralen Texturen on-the-fly:
Wie verhindert man da eigentlich das Flimmern, da ja keine Mipmaps erzeugt werden? Bzw. wie kann der Shader eine niedriger aufgelöste Textur vernünftig berechnen?
super-sampling?

[R300]

Seit DirectX9 also schon seit der Radeon 9700 können doch alle Grakas selbstständig Mip-Maps generieren. Oder habe ich da etwas falsch in Erinnerung?

[_DrillSarge]I[]

Seit DirectX9 also schon seit der Radeon 9700 können doch alle Grakas selbstständig Mip-Maps generieren. Oder habe ich da etwas falsch in Erinnerung?
aber bei on-the-fly texturen und dazu noch mipmaps? keine ahnung. sowas ist bei den spezifikationen bestimmt nicht vorgesehen

[Xmas]

Mal ne Frage zu prozeduralen Texturen on-the-fly:
Wie verhindert man da eigentlich das Flimmern, da ja keine Mipmaps erzeugt werden? Bzw. wie kann der Shader eine niedriger aufgelöste Textur vernünftig berechnen?
Das kommt auf die Berechnungsmethode an. Je nach Zusammensetzung der prozeduralen Textur ist es ja durchaus möglich, gleich einen gefilterten Wert statt ein Point Sample zu berechnen.

[rotalever]

Das kommt auf die Berechnungsmethode an. Je nach Zusammensetzung der prozeduralen Textur ist es ja durchaus möglich, gleich einen gefilterten Wert statt ein Point Sample zu berechnen.
Teilweise dürften dann die Berechnungsmethoden doch sehr eingeschränkt sein, oder?
Mipmaps zu generieren wäre natürlich quatsch, weil das ja jeden Frame geschehen müsste..

[_DrillSarge]I[]

ein weiteres problem dürften die extremen ladezeiten sein. hat man schon bei kkrieger gesehen.
allerdings wären prozedurale texuren ein ganz guter ansatz um den größenwahn aktueller spiele einzudämmen. soviel platz hab ich zum teil gar nicht mehr frei und solange blue-ray und hd-dvd nicht ausm arsch kommen wirds irgendwann ziemlich böse, ala 6 dvd's oder so.

[rotalever]

I[;5889182']ein weiteres problem dürften die extremen ladezeiten sein.
Aber nicht, wenn, die Texturen on-the-fly gerendered werden. Das spart nicht nur viel Platz auf der Festplatte.

[_DrillSarge]I[]

Aber nicht, wenn, die Texturen on-the-fly gerendered werden. Das spart nicht nur viel Platz auf der Festplatte.
dann ja. kostet dann aber massivst bandbreite und shaderpower, sowie intelligente portalierung der entwickler.

[Coda]

Bandbreite braucht eine prozedurale Textur überhaupt keine.

[_DrillSarge]I[]

Bandbreite braucht eine prozedurale Textur überhaupt keine.
wieso? erzeugung in der graka, danach in den speicher schreiben (und solch texturen sind relativ groß, als "normale textur"), es sei denn man will jedes mal wenn diese textur im level vorkommt, diese erneut berechnen lassen (= mMn sinnlos).

[rotalever]

I[;5890980']wieso? erzeugung in der graka, danach in den speicher schreiben (und solch texturen sind relativ groß, als "normale textur"), es sei denn man will jedes mal wenn diese textur im level vorkommt, diese erneut berechnen lassen (= mMn sinnlos).
Exakt, das will man. Eben "on-the-fly" => jedes Mal, wenn ein Texel benötigt wird, wird er berechnet.

[_DrillSarge]I[]

Exakt, das will man. Eben "on-the-fly" => jedes Mal, wenn ein Texel benötigt wird, wird er berechnet.
das problem wird eben die sichtbarkeitskalkulierung und die berechnung eben solcher "texturen" in annehmbarer geschwindigkeit sein (wie immer halt).
trotzdem kostets bandbreite

[rotalever]

I[;5891173']trotzdem kostets bandbreite
Bitte erklären... Das "warum" interessiert mich hier doch :rolleyes:

[_DrillSarge]I[]

solche "texturen" werden ja über einen algorhythmus erzeugt. Meines wissens muss dann trotzdem die fertige textur/ texel vor dem rendern als komplettes objekt in den vram geschrieben werden. und da diese textur nur an einer stelle verwendet wird (onthefly, sobald man sie nicht mehr sieht wird sie verworfen und bei erneuter sichtbarkeit erneut berechnet und in den vram geschrieben) summiert sich das ganze.

[Xmas]

"on-the-fly" bedeutet dass die "Texel" immer wenn benötigt berechnet werden. Da wird nichts in den Speicher geschrieben.

[Coda]

I[;5891756']solche "texturen" werden ja über einen algorhythmus erzeugt.
Algorithmus

Und du hast eine falsche Vorstellung von der Funktionsweise einer Grafikkarte, evtl. solltest du dich da bissel durchfragen ;)

[_DrillSarge]I[]

Algorithmus

Und du hast eine falsche Vorstellung von der Funktionsweise einer Grafikkarte, evtl. solltest du dich da bissel durchfragen ;)
ich durchschau das schon;). ich dachte jedoch, dass pei prozeduralen texturen quasi die gesamte berechnete textur, nachdem diese texel für texel berechnet wurde halt als "stinknormale" textur in den speicher geschrieben wird.

[Gast]

I[;5891897']ich durchschau das schon;). ich dachte jedoch, dass pei prozeduralen texturen quasi die gesamte berechnete textur, nachdem diese texel für texel berechnet wurde halt als "stinknormale" textur in den speicher geschrieben wird.

wird sie auch.
deswegen steht auch am anfang 5min precalc und der ram wird mit den generierten files vollgeschaufelt

[_DrillSarge]I[]

wird sie auch.
deswegen steht auch am anfang 5min precalc und der ram wird mit den generierten files vollgeschaufelt
das ist klar. es geht hier (so wie ichs verstanden habe) um texturgenerierung on-the-fly, also direkt im level und nicht wenn die map geladen wird

[Xmas]

I[;5892057']das ist klar. es geht hier (so wie ichs verstanden habe) um texturgenerierung on-the-fly, also direkt im level und nicht wenn die map geladen wird
Nicht "direkt im Level" sondern "direkt im Shader".

[_DrillSarge]I[]

Nicht "direkt im Level" sondern "direkt im Shader".
ok ;): direkt im shader während des spielens, ohne zwischenspeicherung im vram.

[micki@work]

I[;5892107']ok ;): direkt im shader während des spielens, ohne zwischenspeicherung im vram.was eine optimierung in die falsche richtung ist. am besten ist ne gute balance zwischen prozeduralen materialien, den inputdaten und caching der erzeugten texturen.
ist wie beim der sache mit raytracing vs rasterisatoin, die kombination von beiden welten ist das beste.

nur weil man es vielleicht mal zur laufzeit schafft alle materialien zu erzeugen, hat es trotzdem 0 sinn dafuer nen krampf zu haben diese materialien zu erstellen/programmieren, nur weil man komplett auf texturen verzichten will.
data driven, also mit vielen kleinen parametern, ist am besten. laufzeit caching, sodass man selektiv die zeit in prozedurale materialien steckt die in besserer aufloesung benoetigt werden, und den rest mit einem sample aus dem texture-cache lesen, statt pro pixel tausende instruktions zu verschwenden und dafuer nur durchschnittstexturen zu haben.

[_DrillSarge]I[]

was eine optimierung in die falsche richtung ist. am besten ist ne gute balance zwischen prozeduralen materialien, den inputdaten und caching der erzeugten texturen.
ist wie beim der sache mit raytracing vs rasterisatoin, die kombination von beiden welten ist das beste.
seh ich auch so. was ich gehört habe, wieviel platz zB stranglehold braucht (mir egal, da ps3) ist der weg alles mit immer größeren texturen (inklusive extra bump/specular maps) zuzupflastern irgendwo am ende.

[Spasstiger]

I[;5891897']ich dachte jedoch, dass pei prozeduralen texturen quasi die gesamte berechnete textur, nachdem diese texel für texel berechnet wurde halt als "stinknormale" textur in den speicher geschrieben wird.
Prozedurale Texturen in Echtzeit macht aus, dass nicht Texturen aus dem Speicher gelesen werden, sondern Shader in Echtzeit die Texturen errechnen (und zwar pixelweise, unter Umständen gleich gefiltert).

[_DrillSarge]I[]

Prozedurale Texturen in Echtzeit macht aus, dass nicht Texturen aus dem Speicher gelesen werden, sondern Shader in Echtzeit die Texturen errechnen (und zwar pixelweise, unter Umständen gleich gefiltert).
und diese kann man dann nur einmal verwenden, wenn man diese abspeichert, ist eine mehrfachverwendung möglich.

[rotalever]

was eine optimierung in die falsche richtung ist. am besten ist ne gute balance zwischen prozeduralen materialien, den inputdaten und caching der erzeugten texturen.
ist wie beim der sache mit raytracing vs rasterisatoin, die kombination von beiden welten ist das beste.
.
Die Frage ist, ob caching wirklich so gut ist. Wie schnell steigen Speicherbrandbreiten im Gegensatz zu GPU-Leistung? Möglicherweise ist es schneller immer alles direkt zu berechnen, als es aufwendig wieder in den VRAM zu tun. Zumal dass ja sowie etwas komplizierter wird.

[_DrillSarge]I[]

somit könnte (kann) man theoretisch auch teile der geometrie halbwegs "on-the-fly" erstellen über n-patches oder ähnliches.

[Gast]

I[;5892346']und diese kann man dann nur einmal verwenden, wenn man diese abspeichert, ist eine mehrfachverwendung möglich.


Sie werden normalerweise aber auch nur einmal verwendet, deshalb sind es doch prozedurale Texturen. Was du meinst sind ganz normale Texturen.

[_DrillSarge]I[]

Sie werden normalerweise aber auch nur einmal verwendet, deshalb sind es doch prozedurale Texturen. Was du meinst sind ganz normale Texturen.
nein, mein ich nicht. es geht mir dabei um die performance

[micki@work]

Die Frage ist, ob caching wirklich so gut ist.ja, caching ist gut
Wie schnell steigen Speicherbrandbreiten im Gegensatz zu GPU-Leistung?sicherlich weniger als der aufwand von materialienshadern im gegensatz zum samplen eines texture samples. denn texturbandbreite wirst du noch in weiter zukunft viel brauchen, denn posteffects etc. werden weit aus aufwendiger werden und brauchen bandbreite.
zudem verwechseln viele 'shaderleistung' mit 'shaderleistung'. die leistung die noch sehr weit gesteigert werden kann ist die mathematische leistung. die die viele vom raytracen her kennen ist logische leistung z.b. falls du einen shader haettest in dem 300materialien stecken und du sollst pro pixel entscheiden welches du benutzen wirst, stirbt dein pixelshader!


Möglicherweise ist es schneller immer alles direkt zu berechnen, als es aufwendig wieder in den VRAM zu tun.du renderst es doch schon aufwendig ins vram, nur kannst du es stattdessen in eine textur legen. statt in den framebuffer.

Zumal dass ja sowie etwas komplizierter wird.
klar, viele gute dinge sind komplex, wenn man sie nicht kann muss man sich einfachere gefielde suchen, manchen macht es ja auch spass die komplexen dinge gut hinzubekommen.

[_DrillSarge]I[]

ich frage mich: wenn nun gar nichts gespeichert wird müsste man ja ein und dieslbe textur ungefähr 30 mal in der sekunde berechnen?

[Spasstiger]

I[;5892438']ich frage mich: wenn nun gar nichts gespeichert wird müsste man ja ein und dieslbe textur ungefähr 30 mal in der sekunde berechnen?
Du rechnest nicht die Textur jedesmal neu, sondern für jedes Pixel einen Farbwert. Bei prozeduralen Echtzeit-exturen gestaltet sich der Pixelshader unter Umständen etwas länger, dafür entfällt der Speicherzugriff, weil keine Texturen geladen werden.
Prozedurale Texturen in Echtzeit sind auch nicht in der Auflösung begrenzt (im Rahmen der Rechengenauigkeit der Shadereinheiten), weil immer pixelgenau gerechnet wird und es sowas wie Texel überhaupt nicht gibt. D.h. man kann beliebig nah an eine Oberfläche ran und es gibt keinen künstlichen Matsch (außer der Shader rechnet keine zusätzlichen Details mehr).

[_DrillSarge]I[]

Du rechnest nicht die Textur jedesmal neu, sondern für jedes Pixel einen Farbwert. Bei prozeduralen Echtzeit-exturen gestaltet sich der Pixelshader unter Umständen etwas länger, dafür entfällt der Speicherzugriff, weil keine Texturen geladen werden.
mein ich ja, farbwert (!= textur). aber ich glaube kaum, dass die ps heutzutagwe in der lage sind solch eine extreme last zu stemmen.

[micki@work]

Du rechnest nicht die Textur jedesmal neu, sondern für jedes Pixel einen Farbwert. Bei prozeduralen Echtzeit-exturen gestaltet sich der Pixelshader unter Umständen etwas länger, dafür entfällt der Speicherzugriff, weil keine Texturen geladen werden.jup, statt einem sample rechnest du dann pro pixel unter umstaenden ein paar hundert instruktionen

Prozedurale Texturen in Echtzeit sind auch nicht in der Auflösung begrenzt (im Rahmen der Rechengenauigkeit der Shadereinheiten), weil immer pixelgenau gerechnet wird und es sowas wie Texel überhaupt nicht gibt. D.h. man kann beliebig nah an eine Oberfläche ran und es gibt keinen künstlichen Matsch (außer der Shader rechnet keine zusätzlichen Details mehr).
die schwierigkeit entsteht in der entfernung, stell dir vor du machst ne checkerbox mit 1mm rastergroesse und bist dann 1000m entfernt von den objekten mit diesem muster, du wirst augenkrebs von moire effekt bekommen. du musst also entweder komplexere shader schreiben die je nach entfernung anders rechnen (also algorithmen-mipmaps) oder du musst x-mal pro pixel rechnen, quasi FSAA.

[micki@work]

I[;5892631']mein ich ja, farbwert (!= textur). aber ich glaube kaum, dass die ps heutzutagwe in der lage sind solch eine extreme last zu stemmen.
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=275374&page=3&highlight=perlin+noise
da hab ich ne 'prozedurale texture' generiert. als source im shader, einfach in den FX-composer stecken ;)

[Coda]

I[;5892631']mein ich ja, farbwert (!= textur). aber ich glaube kaum, dass die ps heutzutagwe in der lage sind solch eine extreme last zu stemmen.
Oh doch.

[Gast]

I[;5892346']und diese kann man dann nur einmal verwenden, wenn man diese abspeichert, ist eine mehrfachverwendung möglich.


das ist ja ua. der sinn von prozeduralen texturen, dass man texturwiederholungen verhindern kann.

[Gast]

Die Frage ist, ob caching wirklich so gut ist. Wie schnell steigen Speicherbrandbreiten im Gegensatz zu GPU-Leistung? Möglicherweise ist es schneller immer alles direkt zu berechnen, als es aufwendig wieder in den VRAM zu tun.

wenn man prozedurale texturen in echtzeit berechnet wäre es ziemlicher nonsens diese dann auch noch im VRAM abzuspeichern.

dann könnte man genauso gut die prozedurale textur beim ladevorgang berechnen und könnte sich das berechnen in echtzeit ersparen.

[rotalever]

die schwierigkeit entsteht in der entfernung, stell dir vor du machst ne checkerbox mit 1mm rastergroesse und bist dann 1000m entfernt von den objekten mit diesem muster, du wirst augenkrebs von moire effekt bekommen. du musst also entweder komplexere shader schreiben die je nach entfernung anders rechnen (also algorithmen-mipmaps) oder du musst x-mal pro pixel rechnen, quasi FSAA.
Das wurde ja am Anfang des Threads schon mal besprochen...

[Gast]

Das Hauptproblem belibt, Grafisch gesehen sind Prozedurale Texturen ein Rückschritt,
da sie mathematisch viel zu korrekt und daher unnatürlich aussehen.



Auch dürfte die Anzahl der Spiele, die sich stark ähneln dadurch deutlich steigen, was die Individualität eines Spieles zerstört.


All diese Probleme hat man bei von Menschen erstellten Texturen nicht.
Die sind vielfältig, nie gleich, immer unterschiedlich und natürlich.
Außerdem können diese viel komplexer sein.

Daher sind mir normale Texturen auf die herkömmliche Art viel lieber.
Eine große Festplatte kostet heutzutage nicht mehr die Welt und bis man
20 GB an Texturdaten benötigt kriegt man die BluRay Laufwerke nachgeschmissen.

[_DrillSarge]I[]

Oh doch.
bei xyz vielen texturen, ohne mehrfachverwendung und das zu einer vergleichbaren performance wie der "normale" weg?
p.s.: es geht mir nicht um die machbarkeit, sonder das fett gedruckte ^^

[Gast]

Das wurde ja am Anfang des Threads schon mal besprochen...
Jup, und auf Seite 3 scheinbar schonwieder vergessen.

[Gast]

I[;5894445']bei xyz vielen texturen, ohne mehrfachverwendung und das zu einer vergleichbaren performance wie der "normale" weg?


ein vergleich ist da wohl kaum möglich, da die unterschiede zwischen herkömlichen und prozeduralen texturen zu groß sind.

es ist sicher nicht möglich jede beliebige textur sinnvoll mathematisch zu beschreiben, umgekehrt wäre es zwar möglich eine prozedurale textur vorzurechnen und im VRAM abzulegen. wenn man dann aber die vorteile der prozeduralen texturen (also beispielsweise die texturvielfalt und die möglichkeit die textur beliebig zu vergrößern (was bei einer vorgerechneten textur eh nur angenähert werden kann)) haben will wäre der VRAM-verbrauch viel zu groß.

prozedurale texturen werden herkömliche nicht ersetzen, umgekehrt werden niemals herkömliche texturen niemals die vorteile prozeduraler texturen haben. was sinnvoller ist, ist von fall zu fall unterschiedlich und vielfach ein tradeoff ob man lieber VRAM oder rechenleistung einsparen will.

[rotalever]

Auch dürfte die Anzahl der Spiele, die sich stark ähneln dadurch deutlich steigen, was die Individualität eines Spieles zerstört.
Ich denke, wir werden irgendwann einen Punkt erreicht haben, ob mit oder ohne prozedurale Texturen, wo sich die Grafik kaum noch verbessern lässt, bzw. es auch gar nicht mehr gewünscht ist. Die Engines werden dann so ausgereift sein, dass wieder mehr Wert auf Design gelegt werden und kann und somit auf das, was eigentlich ein Spiel ausmacht, nämlich nicht die Grafik sondern eine Gute Story, ein spannendes Gameplay und neuartige Features, die andere Spiele noch nicht hatten. Und hiermit sind nicht Grafikfeatures gemeint.

[aths]

Das Hauptproblem belibt, Grafisch gesehen sind Prozedurale Texturen ein Rückschritt,
da sie mathematisch viel zu korrekt und daher unnatürlich aussehen..Das hängt vom Algorithmus ab.

Auch dürfte die Anzahl der Spiele, die sich stark ähneln dadurch deutlich steigen, was die Individualität eines Spieles zerstört.Das dürfte nicht mehr der Fall sein als bei jetzigen Texturen.

All diese Probleme hat man bei von Menschen erstellten Texturen nicht.
Die sind vielfältig, nie gleich, immer unterschiedlich und natürlich.Das kann ich so nicht bestätigen.

Außerdem können diese viel komplexer sein.Je nach dem können prozedurale Texturen komplexer sein, in dem sie sich zum Beispiel fast beliebig vergrößern lassen und immer neue Details zeigen. Je nach dem. Es gibt auch etliche Beispiele wo prozedurale Texturen unsinnig sind.

Daher sind mir normale Texturen auf die herkömmliche Art viel lieber.
Eine große Festplatte kostet heutzutage nicht mehr die Welt und bis man
20 GB an Texturdaten benötigt kriegt man die BluRay Laufwerke nachgeschmissen.Es geht nicht um den Festplattenplatz, sondern um die VRAM-Bandbreite.

[Gast]

Da man in prozedurale Texturen theoretisch gesehen beliebig reinzoomen könnte, ähnlich wie bei einer Mandelbrot Grafik,
dann fragt man sich doch, ob es später nicht auch Texturen auf reiner Vektorbasis geben könnte.

Also z.b. das der Grafiker eine SVG Grafik erstellt und die 3d Engine diese läd und die zugrundeliegenden Anweisungen effizient nutzt um dann eine Textur on the Fly zu generieren.

In diese könnte man dann beliebig reinzoomen.

[aths]

Da man in prozedurale Texturen theoretisch gesehen beliebig reinzoomen könnte, ähnlich wie bei einer Mandelbrot Grafik,
dann fragt man sich doch, ob es später nicht auch Texturen auf reiner Vektorbasis geben könnte.

Also z.b. das der Grafiker eine SVG Grafik erstellt und die 3d Engine diese läd und die zugrundeliegenden Anweisungen effizient nutzt um dann eine Textur on the Fly zu generieren.

In diese könnte man dann beliebig reinzoomen.... ohne dass neue Details sichtbar werden.

[_DrillSarge]I[]

ist es mit prozeduralen texturen möglich zB in einer fläche (einzelne textur) per algorhythmus trims festzulegen, also abgrenzungen, wie zB beim übergang von wand zu decke, sowas wie stuck. ohne dafür eine neue fläche rendern zu müssen?

[Gast]

... ohne dass neue Details sichtbar werden.

Das hängt davon ab in welcher Detailstufe die Vektorgrafik erzeugt wurde.

Es gibt z.b. diese berühmte Tiger.svg Datei und da kann man noch viel entdecken, wenn man da reinzoomt.

Außerdem pixelt dann nichts mehr, im Gegensatz zu normalen Texturen.

[RavenTS]

Das hängt davon ab in welcher Detailstufe die Vektorgrafik erzeugt wurde.

Es gibt z.b. diese berühmte Tiger.svg Datei und da kann man noch viel entdecken, wenn man da reinzoomt.

Außerdem pixelt dann nichts mehr, im Gegensatz zu normalen Texturen.

Du meinst diese: http://www.croczilla.com/svg/samples/tiger ?

Da kann man doch nicht viel neues entdecken ab nem bestimmten Punkt...man sieht Details etwas besser aufgrund der Auflösungslimitation, aber verpasst auch keine wichtigen Details...

[rotalever]

Aber prozedurale Texturen können ja noch weit mehr sein als diese einfachen SVGs: Filter, Noise, etc.

[_DrillSarge]I[]

Aber prozedurale Texturen können ja noch weit mehr sein als diese einfachen SVGs: Filter, Noise, etc.
kann man amit zB ein Gemälde richtig darstellen ?

[rotalever]

I[;5912734']kann man amit zB ein Gemälde richtig darstellen ?
Was heißt "richtig" darstellen? Man kann eben eine Sache erzeugen die dem Gemälde sehr Ähnlich sieht. Ist natürlich schwieriger in der Produktion als ein einfaches Foto.

[_DrillSarge]I[]

Was heißt "richtig" darstellen? Man kann eben eine Sache erzeugen die dem Gemälde sehr Ähnlich sieht. Ist natürlich schwieriger in der Produktion als ein einfaches Foto.
das es eben wie gemalt wirkt (zB wie MonaLisa, nicht so modernes lkinien+farbklekse). dort sind glaube auch die limits von dieser technik.
ich habe weiter oben noch ne frage gestellt, kann die jemand beantworten.

[rotalever]

I[;5912780']das es eben wie gemalt wirkt (zB wie MonaLisa, nicht so modernes lkinien+farbklekse). dort sind glaube auch die limits von dieser technik.
Sowas kann man ja mit entsprechenden Filtern erreichen. Und Filter fallen ja wohl auch unter den Begriff Prozedural.

[_DrillSarge]I[]

das steht dochdann aber in keinem verhältnis zum aufwand mehr, oder?

[rotalever]

I[;5912822']das steht dochdann aber in keinem verhältnis zum aufwand mehr, oder?
Ein Gemälde ist aber nun auch wirklich ein Extrembeispiel. In der Regel hat man es mit Steinfliesen, Holzwänden und Stoffen zu tun. All dies geht wunderbar mit prozeduralen Texturen.

[_DrillSarge]I[]

Ein Gemälde ist aber nun auch wirklich ein Extrembeispiel. In der Regel hat man es mit Steinfliesen, Holzwänden und Stoffen zu tun. All dies geht wunderbar mit prozeduralen Texturen.
das ganze tileable zeugs halt. aber das macht ja eigentlich den großen speicher / bandbreitenbedarf aus.

[Fragman]

mit prozeduralen texturen kannst du alles so aussehen lassen wie auf normalen texturen. damit die aber so aussehen muss jemand vorher einen entsprechenden shader erstellen. fuer mich stellt sich da eher die frage des warums? ist der speicher so begrenzt? ich mein wenn man mehr braucht kommt einfach mehr auf die graka, so wies bisher immer lief. shader, die so aussehen wie fotographiert brauchen ne ganze menge rechenpower, weiss ehrlich gesagt nicht wo die heutezutage herkommen soll.

[tokugawa]

mit prozeduralen texturen kannst du alles so aussehen lassen wie auf normalen texturen. damit die aber so aussehen muss jemand vorher einen entsprechenden shader erstellen. fuer mich stellt sich da eher die frage des warums? ist der speicher so begrenzt? ich mein wenn man mehr braucht kommt einfach mehr auf die graka, so wies bisher immer lief. shader, die so aussehen wie fotographiert brauchen ne ganze menge rechenpower, weiss ehrlich gesagt nicht wo die heutezutage herkommen soll.

Das ist nur eine Form von Prozeduralen Texturen.

Es gibt auch offline-Tools zum generieren von Texturen, das sind dann auch prozedurale Texturen. Und genau hier setzt dieses eine Tool das auf der GDC vorgestellt wurde an, damit ist es relativ intuitiv und leicht, Texturen die wie bestimmte Stoffe oder Strukturen aussehen zu generieren, die sich kaum von "hand-gephotoshoppten" Tetxuren unterscheiden.

Der Vorteil hier ist der Zeitaufwand: Texturen zu basteln ist eine Arbeit von Stunden, wenn nicht Tagen. Mit solcher Middleware kann man das in Minuten, und mittlerweile sogar in hoher Qualität.

Ansonsten gilt wie immer: das beste Werkzeug für die richtige Aufgabe. Ob realtime-prozedural-Texturen sinnvoll sind oder nicht hängt davon ab was man konkret macht.

[Fragman]

prozedurale texturen hallte ich fuer ausserst sinnvoll. nur stellt sich mir die frage was der sinn dahinter ist sie on the fly zu rendern? mit diesen ganzen tools wie zb genetica kann man schon sehr tolle sachen machen, nur rendert man es eben doch als textur raus weil das rendern dann eh schneller geht. dieses reinzoom argument kann ich fuer spiele nicht nachvollziehn, was fuer vorteile sollte es denn haben? man geht an eine wand ran, ok, dann braucht man etwas mehr texturedetails, nur kann man eben nicht in die wandtextur reinzoomen im spiel, macht ja keinen sinn. deshalb reichen texturen da voll aus, detailtexturen, mein ich. tools zur generierung sind sehr gut fuer so standardsachen wie eben kacheln oder so, das ganze rendert man als textur und arbeitet eben weiter damit und fuegt zb schmutz hinzu.

edit: gut sind solche proc shader zur variationserstellung einer textur wenn man eine groessere flaeche fuellen will.

[Spasstiger]

Der große Vorteile von prozeduralen Texturen ist, dass die leidlichen Texturwiederholungen wegfallen, weil man durch variable Parameter jeden Quadratmeter derselben Fläche leicht anders aussehen lassen kann. Man kann auch Witterungseffekte oder Beschädigungen drüberlegen. Und natürlich kann man erreichen, dass selbst bei einer größtmöglichen Annäherung an eine Textur noch alles gestochen scharf ist. Und das alles ohne zusätzlichen Bandbreitenbedarf.
Dinge wie Gemälde sollte man natürlich weiterhin über eine klassische Textur realisieren, wobei natürlich der Rauheitseffekt der Leinwand auch prozedural gelöst werden kann.
Für Schilder und Schriften wäre dann wohl eine vektorielle Beschreibung am Besten geeignet, sollte man auch über Shader laufen lassen können, also prozedural.

[rotalever]

Für Schilder und Schriften wäre dann wohl eine vektorielle Beschreibung am Besten geeignet, sollte man auch über Shader laufen lassen können, also prozedural.
Jo für SVGs war ja das Paper von Seite 1 genannt.

[R300]

Sind die schriften auf den Bildschirmen von Doom3 Vektorgrafiken?

Sie bleiben zumindest immer gestochen scharf, egal wie nah man rangeht.

[Spasstiger]

Sind die schriften auf den Bildschirmen von Doom3 Vektorgrafiken?

Sie bleiben zumindest immer gestochen scharf, egal wie nah man rangeht.
Die Bildschirme in Doom 3 sind als sogenannte GUIs gelöst.
Dazu liefert die Doom-3-Engine einen GUI-Editor und eine Skriptsprache mit.
Und da kann man dann Bitmap-Grafiken und vektorielle Schriften nach Belieben zusammensetzen, animieren und mit Skripten versehen, um Interaktion zu ermöglichen.
Wie das Rendering dieser GUIs erfolgt, weiß ich allerdings nicht. Da sie auch auf DX7-Karten dargestellt werden müssen, brauchts auf jeden Fall keine Shader.
Vektoriell sind die Schriften aber durchaus.

[Gerd]

Ich würde mal gerne wissen, warum man prozedurale Texturen nicht bei Konsolen, wie z.B. der xbox360 zur Datenkomprimierung einsetzt?
Es wird ja immer gemeckert, daß eine DVD für heutige Spiele oft kaum noch reicht und wenn Streaming genutzt wird, dann braucht das Laufwerk hohe U/min und wird dadurch laut.

Diese beiden Probleme müsste man doch umgehen können, wenn man mit prozeduralen Texturen Datenmenge einspart und diese in normale Texturen umgewandelt direkt im RAM oder auf der HDD (falls vorhanden) abspeichert.

Dann bräuchte die xbox360 und auch die zukünftige Wii2 gar kein BluRay-LW

[Spasstiger]

Ich würde mal gerne wissen, warum man prozedurale Texturen nicht bei Konsolen, wie z.B. der xbox360 zur Datenkomprimierung einsetzt?
Weil man die Texturen, die der Designer gerne haben möchte, nicht einfach prozedural umsetzen kann. Außerdem benötigen prozedurale Texturen Rechenleistung. Und die Rechenleistung braucht mehr Transistoren als Speicher.

[Gerd]

Weil man die Texturen, die der Designer gerne haben möchte, nicht einfach prozedural umsetzen kann.
Nicht alle Texturen, das ist schon klar.

Außerdem benötigen prozedurale Texturen Rechenleistung. Und die Rechenleistung braucht mehr Transistoren als Speicher.

Selbst, wenn man sie nur zum Streaming nutzt, bzw. damit mehr auf eine DVD passt?

[Aquaschaf]

Ich würde mal gerne wissen, warum man prozedurale Texturen nicht bei Konsolen, wie z.B. der xbox360 zur Datenkomprimierung einsetzt?

Wird z.B. bei RoboBlitz eingesetzt um mit dem Speicherlimit für XBox Live Arcade zurechtzukommen.

[Gast]

Ich würde mal gerne wissen, warum man prozedurale Texturen nicht bei Konsolen, wie z.B. der xbox360 zur Datenkomprimierung einsetzt?

weil man eben nicht alle texturen prozedural beschreiben kann, bzw. nur sehr schwer und weil prozedurale texturen haufenweise takte in der renderpipeline brauchen.

[MadMax@]

Eigetnlich sind prozedurale Texturen gar keine Texturen im eigentlichen Sinn.
Wen ich im Shader ein mathematische Auswertung mache ist das eher eine ortsabhänige und in der regel richtungsunabhänige BRDF.
Berechne ich allerdings eine Textur in einem offline Prozess Prozedural dann trifft der Name schon viel eher zu.

[roidal]

Nicht "direkt im Level" sondern "direkt im Shader".

Das wäre doch totale Verschwendung der Rechenleistung?! Wäre doch viel besser wenn sie erst während des Spielens generiert werden kurz bevor man sie braucht. Am besten noch über einen zusätzlichen Thread damit man auch noch die vorhandenen CPU-Kerne besser ausnützt und dann kann man die Rechenleistung der Graka anderswo verwenden.

[Ailuros]

Das wäre doch totale Verschwendung der Rechenleistung?! Wäre doch viel besser wenn sie erst während des Spielens generiert werden kurz bevor man sie braucht. Am besten noch über einen zusätzlichen Thread damit man auch noch die vorhandenen CPU-Kerne besser ausnützt und dann kann man die Rechenleistung der Graka anderswo verwenden.

Bei einer D3D11 GPU sollte dieses kein Problem sein; den zusaetzlichen thread koennte man viel besser auf einer solchen GPU unterlegen als auf einer CPU. Im zweiten Fall waere es eher eine Verschwendung von CPU resources.

[roidal]

Bei einer D3D11 GPU sollte dieses kein Problem sein; den zusaetzlichen thread koennte man viel besser auf einer solchen GPU unterlegen als auf einer CPU. Im zweiten Fall waere es eher eine Verschwendung von CPU resources.

Wäre es das? Kaum eines der heutigen Spiele nutzt 4 Kerne, aber ne Grafikkarte dagegen wird zu 100% ausgelastet, dieser also noch mehr auf den Hals zu hetzen wäre meiner Ansicht nach falsch.

[aths]

Wäre es das? Kaum eines der heutigen Spiele nutzt 4 Kerne, aber ne Grafikkarte dagegen wird zu 100% ausgelastet, dieser also noch mehr auf den Hals zu hetzen wäre meiner Ansicht nach falsch.Die Graka kann das besser als die CPU und hat deutlich mehr Bandbreite. Die Leistung wächst mit neuen Modellen auch schneller als bei der CPU.

[Aquaschaf]

Wäre es das? Kaum eines der heutigen Spiele nutzt 4 Kerne, aber ne Grafikkarte dagegen wird zu 100% ausgelastet, dieser also noch mehr auf den Hals zu hetzen wäre meiner Ansicht nach falsch.

Zu 100% wird die Grafikkarte nicht unbedingt ausgelastet. Und für viele der Aufgaben die bei der Erzeugung von Texturen anfallen ist die GPU um Größenordnungen besser geeignet als eine CPU.

[Gast]

Das wäre doch totale Verschwendung der Rechenleistung?! Wäre doch viel besser wenn sie erst während des Spielens generiert werden kurz bevor man sie braucht. Am besten noch über einen zusätzlichen Thread damit man auch noch die vorhandenen CPU-Kerne besser ausnützt und dann kann man die Rechenleistung der Graka anderswo verwenden.
ja, das ist wohl die beste loesung, graphikkarten kann man leider nur seriel ansprechen und entsprechend wuerde man eventuell zum unguenstigsten zeitpunkt rechenleistung klauen. ein thread auf cpu kann nebenbei die ganze zeit diese aufgabe durchfuehren.

[roidal]

Zu 100% wird die Grafikkarte nicht unbedingt ausgelastet. Und für viele der Aufgaben die bei der Erzeugung von Texturen anfallen ist die GPU um Größenordnungen besser geeignet als eine CPU.

Nachdem die meisten Spiele von der Grafikhardware her limitiert werden eher schon. Und auch wenn die Grafikkarte diese Berechnung weitaus schneller könnte dürfte es mit einem gelangweilten CPU-kern besser funktionieren als mit einer GPU die eventuell schon froh is wenn sie >25FPS hinbekommt.

[DerRob]

Nachdem die meisten Spiele von der Grafikhardware her limitiert werden eher schon. Und auch wenn die Grafikkarte diese Berechnung weitaus schneller könnte dürfte es mit einem gelangweilten CPU-kern besser funktionieren als mit einer GPU die eventuell schon froh is wenn sie >25FPS hinbekommt.
nur weil die grafikkarte nicht mehr fps liefern kann, heißt das aber noch lange nicht, daß sie zu 100% ausgelastet ist. auch bei einer grafikkarte gibt es mehrere limitierende faktoren. es kann also gut sein, daß die speicherbandbreite oder die füllrate am limit ist, aber die hälfte der shadereinheiten sich langweilen.

[Ailuros]

Wäre es das? Kaum eines der heutigen Spiele nutzt 4 Kerne, aber ne Grafikkarte dagegen wird zu 100% ausgelastet, dieser also noch mehr auf den Hals zu hetzen wäre meiner Ansicht nach falsch.

Es waere erstmal schoen wenn heutige CPUs und GPUs konstant voll ausgelastet waeren, aber es ist wohl nicht der Fall.

Ich sagte mit Absicht D3D11 GPUs da ich bei diesen ein noch effizienteres Thread-management erwarte als bei heutigen. Xmas hat wohl eher als einfacher Beobachter geantwortet, aber als DevRel eines IHV deren GPU MIMD Einheiten hat, wird er wohl schon wissen wo es langgeht.

[dargo]

Kaum eines der heutigen Spiele nutzt 4 Kerne, aber ne Grafikkarte dagegen wird zu 100% ausgelastet, dieser also noch mehr auf den Hals zu hetzen wäre meiner Ansicht nach falsch.
Eine Grafikkarte wird doch nicht durchgehend zu 100% ausgelastet. Wo hast du das denn her? In vielen Games gibt es ständig einen Wechsel zwischen CPU- und GPU-Limit. Mal limitiert das eine mehr, mal das andere. Wie soll dabei die Graka zu 100% ausgelastet sein?

Nachdem die meisten Spiele von der Grafikhardware her limitiert werden eher schon. Und auch wenn die Grafikkarte diese Berechnung weitaus schneller könnte dürfte es mit einem gelangweilten CPU-kern besser funktionieren als mit einer GPU die eventuell schon froh is wenn sie >25FPS hinbekommt.
Du kannst mir gerne ein aktuelles Game zeigen bei welchem sich ein Kern eines Dualcore langweilt. Ein Quad ist bei der Masse noch nicht angekommen.

[roidal]

Eine Grafikkarte wird doch nicht durchgehend zu 100% ausgelastet. Wo hast du das denn her? In vielen Games gibt es ständig einen Wechsel zwischen CPU- und GPU-Limit. Mal limitiert das eine mehr, mal das andere. Wie soll dabei die Graka zu 100% ausgelastet sein?


Du kannst mir gerne ein aktuelles Game zeigen bei welchem sich ein Kern eines Dualcore langweilt. Ein Quad ist bei der Masse noch nicht angekommen.

Solange man nicht in der Framebegrenzung ist und man nicht CPU-limitiert wird sollte meines Wissens nach die Graka zu 100% ausgelastet werden (ob jetzt die 100% an Rechenleistung gebraucht wird oder Speicherbandbreite etc. ist wieder was anderes).

Ich selbst hab nen Quadcore und kann sagen das ich selbst bei Crysis teilweise unter 80% CPU-Auslastung bin. (Und das bei einem Spiel das zur Zeit die höchsten HW-Anforderungen hat)

PS.: Mit meiner HD4850 dürft ich dann bei Crysis doch fast ständig GPU-begrenzt sein.

[aths]

Solange man nicht in der Framebegrenzung ist und man nicht CPU-limitiert wird sollte meines Wissens nach die Graka zu 100% ausgelastet werden (ob jetzt die 100% an Rechenleistung gebraucht wird oder Speicherbandbreite etc. ist wieder was anderes).

Ich selbst hab nen Quadcore und kann sagen das ich selbst bei Crysis teilweise unter 80% CPU-Auslastung bin. (Und das bei einem Spiel das zur Zeit die höchsten HW-Anforderungen hat)Die restlichen 20% reichen aber kaum für vernünftige prozedurale Texturen, zumal es ein Bandbreitenproblem gibt was die anderen Thread stören könnte. Lieber 5% von der GPU abknapsen.

[roidal]

Da wäre dann noch ne andere Frage: Wenn das so gut geht, warum wird sowas dann kaum in heutigen Spielen verwendet?

[Aquaschaf]

Da wäre dann noch ne andere Frage: Wenn das so gut geht, warum wird sowas dann kaum in heutigen Spielen verwendet?

An sich ist es nicht trivial Lösungen für prozeduale Texturen zu erarbeiten. Brauchbare Middleware dafür kommt gerade erst auf. Ergo: es dauert noch, in ein paar Jahren gibt es vermutlich mehr.

[dargo]

PS.: Mit meiner HD4850 dürft ich dann bei Crysis doch fast ständig GPU-begrenzt sein.
Du glaubst gar nicht wie cpu-lastig Crysis ist. ;)

[aths]

Da wäre dann noch ne andere Frage: Wenn das so gut geht, warum wird sowas dann kaum in heutigen Spielen verwendet?Weil die Nachteile noch überwiegen. Bei Bild-Texturen hat der Gestalter direkte Kontrolle. Prozedurale Texturen wären zum Beispiel dort brauchbar, wo man Marmor- oder Holzmaserungen haben möchte, ohne Texturwiederholung zu bekommen. Texturwiederholung zu vermeiden ist derzeit beim Content aber nicht das dringenste Problem.

[G.A.S.T.]

Weil die Nachteile noch überwiegen.
Welche sind das? Für den Fall, dass diese in echte Texturen umgewandelt werden, müsste doch eigentlich auch heute schon genug Leistung verfügbar sein, oder?
Oder würde diese Methode nicht einmal für Konsolen was bringen?