#1 13.11.2005 16:52:05

artzuk
GodlikeMember
Ort: Leipzig
Registriert: 24.01.2005
Beiträge: 1164

ShaderSystem - Planung

Ich plane immer noch am ShaderSystem. Wir hatten da zwar schon mal kleine Pläne, aber es muss nun ins Detail gehen und neue Aspekte sollen da jetzt auch noch rein.

Blos ich verzweifel gerade an ein paar Fragen - vor allem daran, wie ich die Shaderkonstanten ordentlich setzen kann.

Kleine Erläuterung zum System:
1) Es gibt eine Klasse (ShaderManager) welche alle Shader beinhaltet.
Sie hat ne Funktion wie "AddShader( Shader: TShaderKlasse )" wo man einen fertigen Shader hinzufügen kann. Als Rückgabewert bekommt man den Index in der Liste. Will dann ein Objekt beim Rendern einen Shader benutzen ruft es nur "ActivateShader( Indes: Integer );" auf und alles wird fertig gesetzt.

2) Die TShaderKlasse
    1. Es gibt eine, die den normalen ID3DXEffect beinhaltet, welcher aus einer fx-file geladen werden kann.
    2. Es gibt dann noch eine, die normale VertexShader und PixelShader hat. Dazu noch eine ConstantTable. Diese normalen Shader werden durch einen FragmentLinker zusammengesetzt und daraus dann diese spezielle TShaderKlasse erstellt.

=> So hier ist jetzt mein Problem. Ich weiß nicht wie ich die Konstanten richtig setzen soll.
Die Konstanten haben die normalen Namen, so wie sie im fx-File deklariert sind. Bei beiden Varianten setzt man die Konstanten via SetValue (vom Effect bzw. ConstantTable - haben den identischen overloaded Befehl)
Bei den normalen StandartVariablen (z.B. WorldViewProjectionMatrix) sollte es relativ gut gehen. Die ShaderKlasse kennt sie einfach alle und hat zu jeder eine entsprechende Boolean-Variable. Beim Laden des Shaders schaut sie nach, welche Konstanten benötigt werden und setzt die dazugehörige Boolean-Variable auf TRUE. Wenn der Shader dann aktiviert wird, setzt sie diese Variablen.

Aber einige Shader werden wohl ganz spezifische Konstanten haben.
Würde man nur die TShaderKlasse Nr.1 nehmen, dann könnte man für jede einfach eine Funktion schreiben, die die Konstanten setzt.
Aber bei den Shadern, die durch Fragmente erstellt wurden, geht es wohl nicht so einfach. Man kann ja xbeliebige Fragmente zusammensetzen und ich kann nicht für jede mögliche Kombination von Fragmenten eine seperate Funktion schreiben.


Kann mir jemand helfen - oder ist mein Ansatz einfach Müll?
Gibt es vielleicht papers, welche die Struktur eines guten ShaderSystems erklären, welches mit den FragmentLinker arbeiten?

Ich wäre echt für absolut jeden Post sehr dankbar!  :thx2:


Mein kleiner .NET Blog: http://artzuk-interactive.de/

Offline

 

#2 14.11.2005 08:20:24

MexDelphi
ProMember
Ort: Göppingen
Registriert: 24.01.2005
Beiträge: 235
Web-Seite

Re: ShaderSystem - Planung

Hi,

Zitat:


Aber einige Shader werden wohl ganz spezifische Konstanten haben.
Würde man nur die TShaderKlasse Nr.1 nehmen, dann könnte man für jede einfach eine Funktion schreiben, die die Konstanten setzt.
Aber bei den Shadern, die durch Fragmente erstellt wurden, geht es wohl nicht so einfach. Man kann ja xbeliebige Fragmente zusammensetzen und ich kann nicht für jede mögliche Kombination von Fragmenten eine seperate Funktion schreiben.

das Problem hatte/habe ich auch smile .. meine Variante ist folgende:
Die Shaderfragmente beinhalten einen Block in dem die Konstanten angelegt werden. Das laden übernimmt eine eigene Funktion die diese Konstanten ausliest, dem TShader hinzufügt und den "Rest" über die normale DX Fragmentlinker abwickelt. Alternativ hatte ich auch mal ein separates File angedacht, das den gleichen Namen aber eine andere Endung hat. Leider bin ich über einen Grobentwurf nie hinausgekommen (Zeitmangel). Eine Bibliothek mit unterschiedlichen Fragmenten für jeden Zweck und jede (wenn möglich) Schaderversion, ein Tool (Fragmentbuilder) um alles "on the fly" zusammen zu setzen und zu testen und anschliessend als fertige Fragmentliste zu speichern und der Shadermanager läd dann alle verwendeten Fragmente und baut die Shader daraus - natürlich noch ein tool um ein "UsedFragments" File zu erstellen, um beim fertigen Spiel nicht immer alle Biblios mitgeben zu müssen.


goto: http://mexdelphi.cybton.com

Offline

 

#3 14.11.2005 16:16:29

artzuk
GodlikeMember
Ort: Leipzig
Registriert: 24.01.2005
Beiträge: 1164

Re: ShaderSystem - Planung

Und was ist, wenn manche ShaderFragmente irgendwie die gleichen KonstantenNamen haben aber jede einen anderen Wert haben muss. Geht ja, wenn man mehrere Files nutzt.

Noch ne Frage: Wo setze ich am Besten die Konstanten? Weiß nun das Objekt an sich, was gesetzt werden muss, oder weiß das nur der Shader selber und ich schreibe für jeden (geilen) Effekt ne seperate ShaderKlasse, die von der obersten agbeleitet wird?

Hast du ein UML-Diagramm deines ShaderSystems?
Ich selber könnte ja auch mal eins für meine Ideen erstellen - mal sehen, wann ich dazu komme.


Mein kleiner .NET Blog: http://artzuk-interactive.de/

Offline

 

#4 18.11.2005 10:39:01

MexDelphi
ProMember
Ort: Göppingen
Registriert: 24.01.2005
Beiträge: 235
Web-Seite

Re: ShaderSystem - Planung

Zitat:


Hast du ein UML-Diagramm deines ShaderSystems?

ähm .. irgendwo auf papier ... wenn ich am Wochenende Zeit habe und umbrello auf meinem Linux wieder drauf ist .. werd ichs mal in die "moderne Form" bringen und hochladen smile


goto: http://mexdelphi.cybton.com

Offline

 

#5 18.11.2005 12:55:45

JorEl
ExtremeMember
Registriert: 29.01.2005
Beiträge: 894

Re: ShaderSystem - Planung

Zitat:

Wo setze ich am Besten die Konstanten? Weiß nun das Objekt an sich, was gesetzt werden muss, oder weiß das nur der Shader selber und ich schreibe für jeden (geilen) Effekt ne seperate ShaderKlasse, die von der obersten agbeleitet wird?

So einfach ist es nicht wirklich wenn es sehr flexibel sein soll... die Dokumentation von meinem material system hat beispielsweise über 150 Seiten  big_smile
Aber zum Thema - die Konstanten können nicht nur eine Angelegenheit des shaders selbst sein, sie sind sehr häufig objektspezifisch (im simpelste Fall zumindest die worldmatrix). Ich habe lange darüber nachgedacht und bin dann zum Schluss gekommen, dass es verschiedene Arten von Konstanten gibt die dann entsprechend gesetzt werden müssen - zu diesem Zweck habe ich eine eigene TMaterialParameter Klasse implementiert in der man über Konstanten den Typ und Inhalt festlegen kann. Zb. könnte ein Parameter sein "epNearestLightDirection" oder auch "epNearestLightDiffuseColour" - das sind die Parameter die ich als pass-dependent klassifiziert habe, d.h. die sind im Prinzip Platzhalter und je nach aktuellem pass (und vor allem auch abhängig von der Position) wird dann der korrekte Wert gesetzt. Andere mögliche Parameter wären jene, die explizit on-the-fly berechnet werden müssen, wie zb. epWorldViewMatrix oder epWorldViewProjMatrix und dann gibt es natürlich noch "echte" Konstanten wie epFloat, epVector4, etc.
Ah ja, ausserdem ist es auch noch erlaubt beliebige published properties von Klasseninstanzen als Shaderparameter anzugeben... ich weiss, klingt alles furchtbar verwirrend - aber ich hab wirklich einige Monate in die material featuers investiert und erstmals bin ich mit dem Ergebnis vollkommen zufrieden.

Ok, kurz gesagt - es ist besser eine zusätzliche Abstraktionsebene für Shaderkonstanten einzuführen, die dann je nach Typ entscheidet was zu tun ist um den richtigen Wert zu setzen.

JorEl


Jesus hat gesagt - selig sind die, die da Leid erfahren, denn sie sollen getröstet werden... Ford Prefect hat gesagt - es ist unheimlich wichtig, dass wir miteinander reden und einen trinken.

Offline

 

#6 21.11.2005 13:07:31

MexDelphi
ProMember
Ort: Göppingen
Registriert: 24.01.2005
Beiträge: 235
Web-Seite

Re: ShaderSystem - Planung

Hier ein Klassendiagramm und zwei Sequenzdiagramme die ich vor einiger Zeit mal zu papier gebracht habe.
Es wird davon ausgegangen, dass die Engine als dll programmiert ist bzw. als COM server.
Um unnötige Uses-verrenkungen zu umgehen, sind alle klassen von virtuellen / abstrakten klassen abgeleitet (hier Interfaces) die entweder in der Unit Internals oder Externals angelegt sind. Externals fungiert bei einer dll als Unit die vom nutzer der dll eingebunden werden muss, bei einem COM Server sind die Interfaces natürlich in einer Unit und Extern würde die Com klassen und den initialization-Abschnitt beinhalten, der Nutzer des Servers muss dann eben die TLB einbinden/importieren. Die verwendung der im Shaderfragment genutzten Constanten wird durch CONST_SH_USEDF geregelt (bei mir ist das eine TOleEnum Constante) und bei jedem Renderdurchlauf vom zu rendernden Objekt durch setzen des benötigten Shaders "geliefert". Alle anderen für einen Rendervorgang notwendigen Variablen .. Strukturen ..(renderstates..Texturen..Material..) werden ebenfalls vom Objekt verwaltet und wenn gerendert wird gesetzt (zB. durch einen VertexCacheManager)

Die im Klassendiagramm enthaltenen Records L_Vertex etc. repräsentieren die über den Stream an den Shader gelieferten Werte (v Register im VertexShader) und werden durch T_FragmentList beim "zusammensetzen" eines Shaders mit den Anforderungen durch die Fragmente abgeglichen .. wobei ich mir im Moment nicht sicher bin wie ein durch den Stream gelieferter Wert aber im Shader nicht verwendet durch HLSL gehandlt wird.

Als EngineConstanten werden alle von der Engine lieferbaren Werte bereitgestellt und sind im Fragment verwendbar (CONST_ENGINE_VARS) - beim laden eines Fragments wird dann halt geschaut, welche Constanten die Engine in jedem Renderduchlauf bei diesem Shader  setzen muss.

UF_RESULT und UF_SHARED_RESULT bezeichnen einmal ob dieses Fragment ein Ergebniss liefert, also POSITION[n] zB. im Vertexshader das jeder VShader einmal haben muss und zum zweiten die im Fragment mit r_ markierten "internen" Ergebnisse die für andere Fragmente zur verfügung stehen.

So .. das wars was ich auf die schnelle nach einer Suse Linux 10 Update und dann doch wieder lösch und Neuinstallationsorgie noch hingebracht habe. Man möge mir die "vergewaltigung" von UML und Umbrello verzeihen aber mangels Delphi bzw. Pascal unterstützung  sowie Zeit ist das alles nur eben zusammengeschustert. Ich hoffe mit D2006 und Together (Developer werd ich mir wohl gönnen) wird das alles etwas besser - zumindest auf der Roadshow in Stuttgart fand ich das sehr interessant vor allem das "reverse engineering" also bestehende Projekte in UML umwandeln hat es mir angetan smile

aha .. das Klassendiagramm war wohl zu gross .. also als .rar smile

[/img]


Attachments:
Attachment Icon ActivateShader.jpeg, Größe: 81,464 bytes, Downloads: 433
Attachment Icon CreateShader.jpeg, Größe: 103,939 bytes, Downloads: 445
Attachment Icon Klassendiagramm.rar, Größe: 393,464 bytes, Downloads: 452

goto: http://mexdelphi.cybton.com

Offline

 

Brett Fußzeile

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson