JLI Spieleprogrammierung

The Lord of Programming · Verfasst am: 26.02.2008, 19:30 Titel: Shader+Zeit=Problem(?)

Ich hab das Problem bei einer schnellen google-Suche nur einmal auftauchen sehen, allerdings mit keiner wirklichen Lösung.
(Hier ist der betreffende Thread: http://www.gamedev.net/community/forums/topic.asp?topic_id=483583&whichpage=1&#3165162)

Die Sache ist die, dass Variablen, die regelmäßig inkrementiert werden, (also für die Zeit stehen) bei größeren Werten Probleme machen. Ich weiß nicht, woran es liegt, aber vermutet wird eine Ungenauigkeit von floats, mit denen die Shader nicht zurecht kommen.
Das Ergebnis eines "sin(time)" wird also bei hohen Werten für "time" extrem verfälscht. Das ganze lässt sich nicht nur im Programm, sondern auch im FX Composer von NVidia beobachten.

Nun meine Frage an diejenigen, die schon mal mit Shadern gearbeitet haben:
Hattet ihr änhliche Probleme? Workarounds? Lösungen?
_________________
www.visualgamesentertainment.net
Current projects: RDTDC(1), JLI-Vor-Projekt, Tetris(-Tutorial), JLI-Format
(1) Realtime Developer Testing and Debugging Console

Anschlag, Anleitung zum Atombombenbau, Sprengkörper...
Hilf Schäuble! Damit er auch was findet...

Fallen · Verfasst am: 26.02.2008, 20:40 Titel:

Mach doch einfach ein:

The Lord of Programming · Verfasst am: 26.02.2008, 21:30 Titel:

Das wurde ja auch in dem Thread vorgeschlagen.
Das Problem ist, dass man das halt nicht bei jedem Algo so handhaben kann, ohne dass Sprünge auftreten.

Jonathan_Klein · Verfasst am: 26.02.2008, 23:57 Titel:

Meine These: Du hast nur begrenzten Speicher zu Verfügung. Daher wirst du die Zeit immer nur mit Einschränkungen erfassen können (maximale Dauer, Genauigkeit).
floats sind so gebaut, das ihre Genauigkeit mit ihrere Größe anwächst.

Egal was du machst, der Shader kann nur so lange laufen, wie er unter diesen Grenzen bleibt. Du kannst irgendwie versuchen, mehr Speicher zu benutzen, oder du musst den Shader sich wiederhohlen lassen. Dafür musst du eine Stelle finden, an der der Übergang möglichst sanft, bzw. nicht vorhanden ist. Notfalls musst du den Shader so anpasse, dass irgendwo innerhalb der Grenzen eine solche Stelle entsteht.

Wenn ich jetzt nicht totale Scheiße verzapft habe, sind das die 2 einzigen Möglichkeiten, die dir bleiben.

Gute Nacht.
_________________
https://jonathank.de/games/

Sören · Verfasst am: 27.02.2008, 01:16 Titel:

Ich bin mit der Problematik nicht vertraut, aber was wäre zB mit:

Jonathan_Klein · Verfasst am: 27.02.2008, 13:35 Titel:

es könnte aber auch sein, dass man mehrere Sinusfunktionen hat, vielleicht eine mit nem Faktor. Und dann wäre das halt schwer, einen guten Übergang zu finden.
_________________
https://jonathank.de/games/

The Lord of Programming · Verfasst am: 27.02.2008, 13:50 Titel:

Genau das ist das Problem.
Ich hab in einem Programm mehrere verschiedene Shader, die Trigonometriefunktionen auf unterschiedliche Weise nutzen. Manchmal ist bei sin(x) dieses x auch abhängig von den Texturkoordinaten. Ist also unmöglich, das außerhalb zu berechnen.

KI · Verfasst am: 27.02.2008, 14:29 Titel:

Die Genauigkeit von float in der Größenordnung 300 lässt schon deutlich nach, ist halt so. Ich sehe auch nur die Möglichkeit dass du deine Shader irgendwie umbiegst, das jeder mit einem vielfachen von pi arbeitet. Entsprechende offsets kannst du dann direkt in den Shadercode schreiben.
(oder vielleicht mehrere Zeitvariablen nehmen)

Mit int kannst du mal probieren, aber wenn du den Wert ins Unendliche laufen lässt, ist doch auch irgendwie schlechter Code.

The Lord of Programming · Verfasst am: 27.02.2008, 16:17 Titel: