Das, was bei anderen Engines schon seit zehn Jahren Standard ist
... nur besser.
Sowas sehe ich immer wieder gerne, besonders bei der Source Engine - das zeigt einfach, wie wandelbar ein gut durchdachter Code ist. Valve zählt nicht umsonst zu den Besten auf dem Markt.
Das ist aber vermutlich eher ein Material-Editor, denn dieser Verzerrungseffekt geht nicht allein nur mit Shadern, da braucht man "Input" von der CPU.
Wenn du dir das Teil mal herunterlädst, wirst du sehen, dass es sich dabei nicht um einen Material-Editor handelt. Der Editor erlaubt direktes Editieren von HLSL-Shadern, er erzeugt HLSL-Quellcode und kompiliert diesen anschließend. Außerdem kann man Shader ohne "CPU-Input", wie du ihn nennst, überhaupt gar nicht anwenden, der "Verzerrungseffekt" ist da keine Besonderheit oder Ausnahme, ich weiß gar nicht, wie du darauf kommst.
Wie ich darauf komme? Ich weiß es. Dafür hat man VBOs eingeführt. Wenn du nämlich jeden Vertex einzeln über den Systembus schicken würdest hättest du keine so hohen Framerates.
Das man trotzdem quasi "Steuerbefehle" braucht steht außer Frage.
Was ich meinte war, dass dieser Shader wohl eine Art Zeit-Input braucht, damit das ganze auch gleichmäßig aussieht. Und wenn der Editor eben die Möglichkeit hätte, so etwas bereitzustellen, wäre es auch sinnvoll, das speichern zu können, und damit ginge es über einen reinen Shader-Editor hinaus.
____________________________________
Traue keinem Computer, den du nicht aus dem Fenster werfen kannst -- Steve Wozniak
Wie ich darauf komme? Ich weiß es. Dafür hat man VBOs eingeführt. Wenn du nämlich jeden Vertex einzeln über den Systembus schicken würdest hättest du keine so hohen Framerates.
Das man trotzdem quasi "Steuerbefehle" braucht steht außer Frage.
Du weisst gar nichts, anscheinend ist dir nicht mal klar, dass es sich hier um Directx handelt.
Zitat: Original von darkinsanity
Was ich meinte war, dass dieser Shader wohl eine Art Zeit-Input braucht, damit das ganze auch gleichmäßig aussieht. Und wenn der Editor eben die Möglichkeit hätte, so etwas bereitzustellen, wäre es auch sinnvoll, das speichern zu können, und damit ginge es über einen reinen Shader-Editor hinaus.
Selbstverständlicherweise muss man die 'Zeit' manuell zum Shader über Registers schicken, wie stellst du dir das denn sonst vor? Das hat rein gar nichts mit einem Material Editor zu tun, so etwas gibt es schon seit Valves Ingame-Tools eingeführt wurden, sieh ihn dir an.
Der Editor kompiliert Shader und erstellt eine Runtime-Implementation, vmts werden davon nicht berührt, du liegst also falsch. Und was bitte meinst du mit 'speichern'? Etwa welches HLSL-Register die Zeitinformation erwartet etc? Das ist normalerweise hardcoded in einer Shader DLL von Source, hat auch nichts mit Materials zu tun.
-.-
Selbstverständlich ist mir klar, dass es sich bei der WIndows-Version der Source Engine um DirectX handelt. Ich habe nie etwas gegenteiliges behauptet.
Aber auch Direct3D hat ein entsprechendes Äquivalent zu Vertex Buffer Objects, da du ohne sie eben keine entsprechende Performance bekommst. Die Renderperformance durch unnötige System Bus Zugriffe zu beschränken, wäre absolut bescheuert und würde die GPU unnötig ausbremsen.
Aktuelle Spiele (Crysis usw.) schicken nämlich ganz sicher nicht alle Vertices pro frame über den System Bus. Das würde nämlich nicht nur andere Hardware ausbremsen (da der System Bus eben die Schnittstelle zwischen Hardware und CPU ist), sondern auch den VRAM unnütz machen (bzw. auf Texturdaten und Shader beschränken).
Die Zeit über "Register" "schicken"? Du erzählst Unsinn, zwischen CPU <-> System Bus <-> GraKa läuft nichts über Register. Unten mehr dazu.
Da du offenbar nicht im Geringsten verstehst, wovon ich rede, werde ich es dir nochmal erklären:
Wenn du einen Shader hast, der eine entsprechende Timing-Variable erwartet, muss er die darin erwarteten Daten auch irgendwie erhalten. Du musst also irgendwie speichern, dass er diese Daten in dieser Variable erwartet. Die Angabe, welche Dinge ein Shader erwartet (auch welche Texturen usw.), ist allgemein ein Teil einer Material-Definition.
Ob und wie die Source-Engine das ablegt weiß ich nicht - ich habe auch nie behauptet, dass eine VMT davon angetastet werden würde. Möglicherweise definiert sie vorab die Schnittstellen - ich habe mich nicht mit der Engine beschäftigt, daher kann ich das nicht beurteilen.
Noch einige Anmerkungen:
"Runtime-Implementation" - Bist du sicher, dass du weißt, was du da sagst? Shader können vorab zu Bytecode kompiliert werden, der dann vom Treiber nochmals an die GraKa angepasst wird, da die unterschiedlichen GPUs nicht die gleichen Opcodes haben. Mit "Runtime" hat das nix zu tun.
"HLSL-Register" - So bezeichnet MS in D3D das, was unter OpenGL uniforms sind. Das sind keine echten Register - der Begriff bezeichnet einfach nur eine Variable, die von "außen" mit Daten gefüllt wird. Und "über" Register "geschickt" wird schonmal gar nichts. Die Daten werden schlussendlich nur hineingelegt.
Vielleicht solltest du erst einmal die Posts anderer lesen und verstehen bevor du solche Kommentare schreibst.
"Du weisst gar nichts" - q.e.d.
____________________________________
Traue keinem Computer, den du nicht aus dem Fenster werfen kannst -- Steve Wozniak
[Beitrag wurde 5x editiert, zuletzt von darkinsanity am 04.09.2011, 20:43]