Hallo zusammen,

zur Zeit plagt mich ein Problem bezüglich proceduralen Texturen. Ich schaffe es zwar halbwegs gut aussehende Texturen dieser Art herzustellen, aber da ist ein gewaltiges Problem, das sich doch öfters stellt als ich befürchtet hatte: Immer wieder braucht man eine Textur, die nahtlos kachelbar sein muss. Das Ganze wäre mit Bildbearbeitungssoftware kein Problem, wenn es nunmal nicht das Programm selbst procedural erledigen sollte.

Von daher suche ich grade nach einem Algorithmus oder einer zündenden Idee, wie man sowas am besten umsetzt. Im Netz hab ich auf Anhieb nicht viel Material gefunden; irgendwie fehlt mir hier noch der passende Fachbegriff.
Also wenn jemand etwas Ahnung hat, ich wäre für Tipps in diese Richtung dankbar.

MfG

Hier gibs 2 Möglichkeiten, bei der 1. Möglichkeit wird das Kacheln schon direkt bei der generierung beachtet und bei der 2. machst du das nachträglich.
Es ist natürlich klar, dass die 2. Version die schlechtere Wahl ist, da man sich damit grafisch ins Kniee schießt.
Wenn du z.B. auf Noise zurück greifst, dann müssen die Stützpunkte auf der Linken und Oberen Seite in den rechten und unteren Rand kopierst.
Damit läuft die Interpolation zwischen den Stützpunkten dann nahtlos.
Einfach gesagt, erstellst du eine Noisestufe, dann kopierst du zum Schluss die erste Reihe und Spalte in letzte Reihe und Spalte und arbeitest dann normal weiter.
Alle anderen Operationen bekommen ein clamping, also werden über modulo immer in einen Wertebereich zurück geworfen.
Wenn du 512x512 tex hast und ein Motionblur mit 10 pixel stärke verwendest, dann würde er ja 5 Pixel oben und rechts und 5 pixel unten und links brauchen.
also wenn du bei Pixel 512,512 bist und das 5 pixel in positive richtung liest, dann müsstest du 517 mod 512 machen, damit er korrekt tileable texturen generiert.
Die richtig ekelige und auch langsamere Variante(oft schneller implementiert) ist einfach die randpixel mit einer bestimmten breite auf zu addieren und zu blenden aber dabei kommt nur müll raus, da man beim tiling auf größeren flächen dies sofort sieht.

Ich schreibe aktuell eine Bachelorarbeit zum Thema Virtual Texture, Prozedurale Texturen, Textursynthese und Kompression und da gerade noch recht gut im Stoff. Nur sind meine Prozeduralen Texturen realtime und nicht precomputed, was die Optimierung und Ansätze ein bischen verändert.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Besteht die Chance, dass wir das irgendwann mal zu Gesicht bekommen? Ich zumindest finde sowas hochinteressant.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Sehr wahrscheinlich, da es bis jetzt eine Öffentliche Arbeit werden soll.
Ich habe zwar vor, noch einiges zu PlayStation3 zu machen aber das bezieht sich eher auf Cell und das ist ja nicht durch eine NDA geschützt.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Würde ich nicht zu 100 Prozent so machen.
Ich wurde die 1 Zeile und Spalte so wie du nehmen. Für die letzte Zeile und Spalte dann aber bereits durch Noise aus der Zeile und Spalte berechnete Werte. Sonst hast du nämlich an der Nahtstelle einen Bereich der 2Pixel breit identisch ist.

Theoretisch kannst du das Problem dadurch lösen, dass du beim Berechnen deiner Textur den Texturbereich um 1Pixel breiter und höher machst und in diese zusätzlichen bereiche dann die 1Zeile und 1 Spalte kopierst. Dann Berechnest du die Textur komplett, nimmst abschließend aber nur den Kernbereich.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Danke, Leute. Da hätte man draufkommen können... Ich hab mal Flashs Lösung umgesetzt und die ausgegebenen Texturen sind zugegebenermaßen jetzt absolut nahtlos kachelbar. Nur noch meine Texturkoordinaten scheinen beim Rendern nicht ganz zu passen.


Das klingt wirklich interessant. Wie funktioniert das ganze denn realtime? Wird ein Texel erst im entsprechenden Shader generiert oder wie muss man sich das grob vorstellen? Und es klingt relativ langsam, wo liegt der Anwendungsbereich davon?

MfG

Dann gehts also auch praktisch.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Prozedural erlaubt ein breites Spektrum an möglichkeiten.
So kann man wie bei Farbrausch und co einfach die ganze Textur generieren oder wie aktuellere Lösungen auf normale Samples zurück greifen und die dann verarbeiten.
Also z.B. lade Sample "Sand", lade die Map für Textursynthese und erstelle den Ausschnitt x=742,y=2341,w=4,h=4 , passe HUV nach bla an, blende Sample "blood" rein.

So kann man Prozedural halt die theoretische unendlichkeit einer Texture erreichen und durch Virtual Texturing kann man noch ne menge Speicher sparen und die Arbeitslast reduzieren. Da man so nur maximal eine Textur mit der größe der Auflösung generiert und da man nicht jedes Frame komplette änderungen hat, bleiben viele Patches(4x4 Texturblöcke) erhalten.
Im neuen ShaderX6 ist noch ein Artikel drin, wie man dann das Tiling sauber filtern kann, weil beim normalen reinkopieren der Texturblöcke würde man Colorbleeding erhalten und durch Texturarrays kann man das verhindern, bekommt Trilineares Filtering umsonnst und kann AF verwenden.
Wichtig sind auch Mechanismen, die z.B. Tasks in bestimmte Zonen aufteilen, ein Sample "Blood" wird ja nur an einigen Stellen in der Textur verwendet und nicht in jeden Patch. So kann man dann durch erkennen von der Scissorbox, auf der Virtuellen Texture, die zu machenden Tasks auf ein minimum reduzieren.
Praktisch kann ich aktuell Virtuelle Texturen, von der Größe 789221x789221 erstellen, da dann meine Noisefunktion sich wiederholt.
Lösung wäre eine erkennung der nächst höchsten Primzahl für eine gewünschte Texturgröße.
Ich habe eine Noisefunktion(legt ein rauschen auf bestehende daten), Motionblur(mit sinus/consinus oder Besenham), fill, fillnoise(klassisches noise) und blending implementiert.
Realtimetauglisch ist das komplette rendern einer 2048x1024 Textur bei weitem nicht, ich nutze aktuell nur ein Kern, keine extensions und alles ist unoptimiert aber so kommt auch nur von den aktuell 4-5sekunden auf vieleicht 1sekunde und nicht auf 33ms.
Also voll prozedural generierte Texturen sind nicht realtime Tauglich und auch garnicht gewünscht.
Die Spieleindustrie will keine klassische Prozedural generierten Texturen, da der Artist viel zu sehr eingeschränkt ist.
Wir haben hier im Studio z.B. ProFX lizensiert gehabt aber man ist sehr schnell von Weg, weil es den Artist einfach nur quält und die möglichkeiten schmällert.

Mein Ansatz geht dahin, eine Art Photoshop, wo man durch Textursynthese einmal den Hintergrund für die bereiche festlegt und dann anfängt die einzelnen Änderungen an den Texturen vor zu nehmen, indem man Pixel zeichnet, Filter anwendet und blendet und fertige Samples(Bulletholes,Blood,Scratches,Mud,...) mit reinpackt.
Zum schluss werden halt Samples und ne Bildungsvorschrift generiert.

Ich hab noch zig Ideen zur Optimierung und realisierung, in der Arbeit werde nur ein bischen das Thema beleuchten können.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Danke für diesen kleinen Einblick und auch nochmals an alle.

MfG

Eis der heuptprobleme bei prozeduralen materialien ist das filtern, da man für eine gewöhnliche bilineare filterung schon 4 samples berechnen muss. Noch schlimmer wird es mit trilinearrer oder anisotroper filterung. dann werden 8 oder mehr samples gebraucht, die zusaätzlich auch noch jeh auch noch 4x von den nachbar fragmenten brechnet werden.

Die einzige sinvolle möglichkeit ist es , diese materialien in einer textur zu cachen, ansonsten verbrennt man frame für frame wertvolle shaderleistung ohne irgend einen wirklichen nutzen davon zu haben...

_________________
Lumina plattform unabhängige GLSL IDE

Deswegen nutzt man Texturarrays, das sind 5 Texturlookups und hat trilineares filtering und das hardware AF läuft auch ohne probleme.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004