Hi

Ist es eigentlich normal das Shader für Levelgeometrie so langsam sind?

Habe verschiedene versucht anzupassen (Nvidia FX Composer, oder ATI's RenderMonkey)... mit Erfolg also das diese laufen, aber so langsam langsamer geht es schon nicht mehr. Woran liegts???

Ist mit einem nächsten Update vielleicht eine Besserung in Aussicht.

gsfan

kannst du mal einen screenshot der shader posten? und vielleicht den code? dann wäre es vielleicht einfach zu helfen! Ich selbst hatte noch nie Probleme mit Shadern auf Levelgeometrie nicht mit meiner alten 9600XT und jetzt schon gar nich mit meiner neuen Karte.

Es könnte sich um einen Fehler im Shadercode handeln.
Schon mal versucht den Shader auf Modellen zu verwenden?
Sieht es da anders aus?

Grüße
Sven

Hi

Bei Modellen ist es nicht so, ist aber logisch weil diese werden sowieso schneller grendert als die Levelblocks, am Code kann es auch nicht liegen weil es Bedarf ja nicht so eine riesige Umstellung eines Shaders der für Modelle funktioniert um den auch auf die Levelblocks anzuwenden und wie gesagt da laufen diese um einiges schneller.

Wenn Deine Shader schneller sind(aber nicht FFP) gratuliere ich Dir und freu mich auf den Code den Du gleich zeigst.

gsfan

das ist bei mir auch so. Die optik ist gut.



Aber seit ich einen Shadere eingebaut hab, ruckelt es nur noch und mit ruckeln mein ich so 1 bild pro sekund im schlimsten fall

ich kann jetzt nur kurz die ultimate shader collection anführen.
Ich würde empfehlen einen kurzen Test mit diesen etablierten und getesten Shadern zu machen, da man da am besten Vergleiche ziehen kann.

Ich selbst hatte schon öfter das Problem das ich Shader, welche "für" und mit Rendermonkey geschrieben wurden falsch übersetzt habe. Beachtet die Unterschiede in den Matrizen.

Als letztes noch ein kurzer Screen mit FPS des Ultimate Shader Demos

Bei der gleichen Demo und dem gleichen Bildausschnitt zeigt mein Rechner eine Framerate von 17 an!

3 GHzProzessor, Ati X300, 1024 GB RAM.

Das liegt wohl an der X300, die ist langsam. Der Prozessor und RAM sind zwar gut, aber bei Shadern kommt halt die GraKa zum Zug.

Zu der schlechten Geschwindigkeit; das liegt wohl daran dass - auch bei einem Indoor Level - einfach "zuviel" Shader sichtbar ist. In der Sphere Demo etwa wird dieses Problem (welches bei Models genauso auftritt) dadurch gelöst, als dass der Shader nur mit dynamischen Lichtern funktioniert, und diese bereits nach einer kurzen Distanz abgeschaltet (und der Shader somit "deaktiviert") werden. Dadurch läufts sogar auf ner X300 relativ gut, und die Performance kann angepasst werden

Naja, Martin hatte das Problem sogar in einem Lüftungsschacht, der absolut einfache Geometrie hatte (ist ja nur ein rechteckiger Gang). Er konnte Normalmaps nicht sinnvoll auf Levelgeometrie anwenden, ohne dass es nur noch ein paar FPS waren.

Am Ende nutzt er den Shader auch nur noch bei vereinzelten Modellen.

Ich denke schon, dass es da arge Probleme gibt. Es könnte die statische Shadowmap sein. Also stellt die besser ab (Blocks auf Flat stellen). Aber vielleicht liegt es auch noch an anderen internen Dingen, die ich nicht verstehe.

Bei der Torque Shader Engine kann man Shader übrigens auf Levelgeometrie mit statischen Schatten anwenden. Also muss das irgendwie gehen.

das problem ist wahrscheinlich, dass bsp-geometrie viel zu stark unterteilt ist. es gibt viel zu viele state changes für die grafikkarte (umschalten der textur, des shaders,...). moderne grafikkarten sind darauf optimiert möglichst viele polygone mit denselben einstellungen zu rendern und nicht alle 30 polygone umzuschalten. in einem bsp-tree lassen sich die polygone aber sehr schlecht nach material gruppieren.

Oh. Endlich mal ein fachmännischer Kommentar

Ich verstehe das Problem. Wie ist das mit dem Octree? Könnte man da besser sortieren oder bräuchte man eher eine neue Material-orientierte Sortierung?

Ich könnte mir für eine moderne Engine sogar ein Shader-LOD vorstellen, bei der wie bei Mipmaps z.B. die Shader ab einer bestimmten Entfernung herunter- oder ausgeschaltet werden.