Das Prozedurale Material und Licht Dilema [Archiv]

Demirug

2003-06-27, 19:19:28

Dies alles liegt natürlich alles erst noch vor uns in der Zukunft. Wir haben ja gerade erst den breiten Sprung in die Welt der DX7 Effekte vor uns welche uns schon vor Jahren mit dem erscheinen der GeForce 256 (1999) angegündigt wurde. Sollte diese Tempo beibehalten werden wird das ganze erst in den Jahre 2006/2007 akkut. Noch viel Zeit bis dorthin trotzdem möchte ich hier ein grosses Problem aufzeigen.

Fragt man die Entwickler welche neuen Effekte durch Pixel-Shader 2.0 möglich werden so hört man oft Prozedurale Texturen (Materialien) als Antwort. Für alle die mit diesem Begriff nichts anfangen können hier eine kurze Erläuterung:

Bei Einsatz von Prozeduralen Texture wird die Pixelfarbe nicht einfach aus einer Texture ausgelesen sondern mit einer mathematischen Formel (bzw einem Algorithmus
) bestimmt. Der Vorteil dieser Methode ist das man sich beliebig an ein Objekt annähern kann ohne das die Oberfläche dabei Pixelig wird und man braucht dafür noch nicht einmal viel Texturespeicher und Bandbreite.

Zu schön um wahr zu sein? Ja man erkauft sich die eingesparte Bandbreite und Speicherverbrauch leider mit einem viel höheren Bedarf an reiner Rechenleistung. Aber wir haben ja schon bei den CPUs gelernt das Recheleistung schneller als die Bandbreite gesteigert werden kann.

Neben prozeduralen Texturen kann man auch prozedurale Lichtquellen entwickeln. Das heist zum Beispiel besseres Feuer.

"Aber wo ist nun das Dilema?" mag man sich fragen da sich das ja alles sehr schön anhört.

Das Problem liegt in der Art und Weise wie heute Effekte programmiert werden. Grafik-APIs (D3D, OpenGL) erlauben nur die Verwendung von jeweils einem Vertex- und einem Pixelshader zur gleichen Zeit. Das bedeutet das alles was pro Vertex und pro Pixel zum erreichen des gewünschten Effekts getan werden muss in einem Paar zusammengehöriger Vertex und Pixelshaderprogramme hinterlegt werden muss.

Wenn wir also 10 prozedurale Materialen und 5 prozedurale Lichtquellen haben ergibt das 50 mögliche (10*5) Effekte und für jeden muss ein Paar VS und PS Programme zur verfügung stehen. Shaderhochsprachen machen es zwar einfacher einen Shader zu erstellen aber die Aussicht unzählige Shaderprogramme schreiben zu müssen um in den Genuss prozedurale Lichtquellen und Materialen zu kommen dürfte die Motivation diese Dinge auch wirklich in Spielen nicht unbedingt steigern.

Da der Wettbewerb aber irgendwann den Zwang dazu erzeugen wird befürchte ich das der zeitliche Aufwand pro Spielminute noch weiter steigt mit der folge das die Spiele zwar besser ausssehen aber leider auch viel schneller durchgespielt werden können. Wenn die Entwicklung einer Spielminute bei unverändertem Buget immer teurer wird ist das ja einfachste Mathematik.

Das Offline rendering stand in der Vergangenheit vor dem gleichen Problem und fand eine Lösung. Dort schreibt man nicht länger Vertex und Pixelshader sondern bechreibt die Lichtquellen und Materialen getrennt. Der Renderer bestimmt dann für jedes Objekt welche Lichtquellen und Materialen zum Einsatz kommen und baut den entsprechenden Effekt dynamisch aus den Beschreibungen zusammen. Um auf unser Beispiel von oben zurückzukommen müssten hier nur 15 "Shader" programmiert werden. 10 für die Materialen und 5 für die Lichtquellen.

Soviel als Grundlage für eine Diskussion.

PS: Einigen dürfte das Thema bekannt vorkommen da ich es schon öfter angeschnitten habe. Aber es liegt mir nun mal wirklich am Herzen.

Xmas

2003-06-27, 20:47:27

Original geschrieben von Demirug
Neben prozeduralen Texturen kann man auch prozedurale Lichtquellen entwickeln. Das heist zum Beispiel besseres Feuer.
Ich habe irgendwie ein Problem, mir sowas vorzustellen. Im Prinzip kann man hier doch nichts anderes tun als wie mit einem Partikelsystem mehrere Punktlichtquellen (oder Flächenlichtquellen, also Kreise oder Rechtecke, die aber ungleich schwerer zu berechnen sind) zu erzeugen.
Oder aber die Abstrahlung der Lichtquelle in eine Cubemap rendern. Beides braucht aber nicht unbedingt eine Kombination der Shader.

Demirug

2003-06-27, 21:31:44

Original geschrieben von Xmas
Ich habe irgendwie ein Problem, mir sowas vorzustellen. Im Prinzip kann man hier doch nichts anderes tun als wie mit einem Partikelsystem mehrere Punktlichtquellen (oder Flächenlichtquellen, also Kreise oder Rechtecke, die aber ungleich schwerer zu berechnen sind) zu erzeugen.
Oder aber die Abstrahlung der Lichtquelle in eine Cubemap rendern. Beides braucht aber nicht unbedingt eine Kombination der Shader.

Man kombinert ja schon heute beim Bumpmapping einen Licht und Material Anteil zusammen.

Der Lichanteil liefert den Vektor mit dem das Licht auf den zu renderen Punkt trift und die Lichtmenge als RGB Wert.

Der Materialanteil steuert nun ebenfalls eine Farbe und einen Vektor bei.

Das ganze wird dann nach der bekannten Dot3-PerPixel light Formel verrechnet.

Alle 4 benötigen Werte können nun durch Formeln bestimmt werden. Werden die beiden Werte für das Material berechnet spricht man von einem prozeduralen Material. Werden die beiden Werte für das Licht berechnet spricht man von einer prozeduralen Lichtquelle. Da Lichtquellen im Prinzip immer irgendwie berechnet sind (normalisieren von Vektoren, entfernungsabhängie Beleuchtungsstärke, ...) spricht man oft erst ab einer bestimmten Komplexität von einer prozeduralen Lichtquelle. Diese Grenze ist aber durchaus fliesend.

Ein einfaches Beispiel für eine prozedurale Lichtquelle welches im Prinzip auch schon mit einer DX8 Karte realisierbar ist wäre ein rotierender Feuerball. Der Lichtvektor wird dabei noch ganz normal berechnet (Mittelpunkt der Lichtquelle zum Renderpunkt). Die Farbe wird aber nun etwas aufwendiger bestimmt. Der Lichtvektor wird mit einer vorher bestimmnten Rotationsmatrix Transformiert und dient dann als Texturekoordinate für eine Cubemap (diese enthält eine Feuertexture) und über die enfernung wird noch ein Skalierungfaktor bestimmt und das ganze verrechnet. Ändert man nun bei jedem Frame die Rotationsmatrix entsteht der Eindruck als würde sich der Feuerball drehen. Damit das alles funktioniert sind sowohl Berechnungen im Vertexshader wie auch im Pixelshader erforderlich. Hat man jetzt noch ein prozedurales Material kommt da auch noch ein Vertex und Pixelshadercodeanteil dazu.

Derzeit versucht man solche Probleme mit zusammengestückelten Codefragmenten zu lösen aber da gibt es so viele Einschräkungen (z.B. bestimmte Werte müssen immer auf bestimmten Registern liegen) die sich auch noch schnell negativ auf die Performance auswirken das dies keine dauerhafte Lösung sein kann. Mit Shaderhochsprachen geht es wie gesagt etwas besser.

Fragman

2003-06-28, 13:41:18

vielleicht wird es dann zeit, nach dx10 die api, wie sie heute arbeitet, zu aendern? vielleicht sollte man die rendertechnologien von anderen renderern uebernehmen, ati und nv koennten sich ja in dieser hinsicht zusammentun...

Demirug

2003-06-28, 14:16:14

Original geschrieben von Fragman
vielleicht wird es dann zeit, nach dx10 die api, wie sie heute arbeitet, zu aendern? vielleicht sollte man die rendertechnologien von anderen renderern uebernehmen, ati und nv koennten sich ja in dieser hinsicht zusammentun...

Eine generelle Lösung des Problem auf API Ebene wäre IMHO sehr wünschenswert. Nur müsste sich die API davon weiter von Hardware entfernen und eine höherer Abstraktionebene einehmen was einigen Wiederstand verursachen würde.

Börk

2003-06-28, 15:30:44

Wie sieht´s den beim PS 3.0 aus?
Gibts da schon Verbesserungen bezüglich der Berechnung?
Werden Materialien und Lichtquellen vielleicht sogar schon getrennt beschrieben? Falls dies beim normalen Renderen überhaupt möglich ist...

ScottManDeath

2003-06-28, 16:01:12

Hi

vs_3_0 und ps_3_0 unterstützen ja branching. d.h. man könnte theoretisch einen mammut shader bauen und dann dynamisch code für entsprechende licht / material kombinationen ausführen

im nvidia cg whitepaper von der siggraph steht ein abschnitt drinne wie man mittels "pseudo virtuellen" funktionen verschiedene lichtquellen typen über einen kamm scheren kann.

man könnte auch ähnlich renderman funktions signaturen für licht und material funktionen vereinbaren.
zB.B

float4 light_func(float4 target_position)
{
liefert farbe für target_position zurück
ist egal ob punkt oder flächenlicht, wenn z.B. prozedurales feuer
benötigt wird müssen dann eben mehrere variablen einfliessen
}
float4 material_func(float4 target_position)
{
liefert farbe für aktuelles fragment, entweder textur lookup oder prozedural
}

im hauptshader

light_func* lights[4];
material_func* materials[4];

lights[0] = light_default;
lights[1] = light_fire;
lights[2] = light_area;
...

materials[0] = material_texture_2D;
materials[1] = material_wood;
...

int cur_light; // wird über die api festgelegt von aussen
int cur_material; // --""--

float4 pixel_color = lights[cur_light](pos) * materials[cur_material](pos);

ist recht oberflächlich ich hoffe aber man sieht was ich will

Bye
ScottManDeath

Demirug

2003-06-28, 16:02:08

Original geschrieben von burk23
Wie sieht´s den beim PS 3.0 aus?
Gibts da schon Verbesserungen bezüglich der Berechnung?
Werden Materialien und Lichtquellen vielleicht sogar schon getrennt beschrieben? Falls dies beim normalen Renderen überhaupt möglich ist...

Nein VS/PS 3.0 bringen in dieser Richtung keinen wirklichen Fortschritt sonst hätte ich das Thema hier gar nicht aufgebracht.

Hätte man bei den 3.0 Shader in dieser Beziehung etwas geändert würde man ja auch nicht mehr von Vertex (VS) und Pixelshader (PS) sprechen sondern von Light (LS) und Materialshader (MS).

Auch OpenGL 2.0 arbeitet immer noch auf der Basis von Vertex und Pixelshader.

Nur im Offlinerendering benutzt man bereits Funktionsorientierte Shader für Lichtquellen, Oberflächen, Volumen, Geometrie, ... Dort ist es aber auch einfacher weil man eine CPU zum Rendern hat. Bei einer GPU kommt bei der Benutzung von funktionorientierten Shadern das grosse Problem des aufteilens der Arbeit auf die CPU, die Vertexshader, die Pixelshader und die anderen Einheiten des Chips (Alphablend, Stnecilbuffer, ...) auf.

Zu diesem Themenkomplex gibt es Forschungenhttp://graphics.stanford.edu/projects/shading/ die bisher aber noch keinen Eingang in das Realtimerendering gefunden haben.

Ich hoffe da auf Exluna aber da gibt es leider noch nicht mal Gerüchte das man dort an so etwas arbeitet.

Demirug

2003-06-28, 16:12:22

Original geschrieben von ScottmanDeath
Hi

vs_3_0 und ps_3_0 unterstützen ja branching. d.h. man könnte theoretisch einen mammut shader bauen und dann dynamisch code für entsprechende licht / material kombinationen ausführen

im nvidia cg whitepaper von der siggraph steht ein abschnitt drinne wie man mittels "pseudo virtuellen" funktionen verschiedene lichtquellen typen über einen kamm scheren kann.

man könnte auch ähnlich renderman funktions signaturen für licht und material funktionen vereinbaren.
zB.B

<snip>

ist recht oberflächlich ich hoffe aber man sieht was ich will

Bye
ScottManDeath

Ja man erkennt das Prinzip.

Denn Abschnitt kenne ich aber wirklich zufrieden bin ich mit dieser Lösung eigentlich nicht. Es bleibt nach wie vor das Problem das man zwischen den Vertex und den Pixelshader nur eine begrenzte Anzahl (10) von Werten austauschen kann. Die sind schnell erschöpft. Zudem kosten die Branchs natürlich auch etwas Leistung.

Renderman sehe ich hier als gutes Beispiel wie man das Problem lösen sollte. Der API einfach die Lichtquellen und Materialshader übergeben und der Rest (Shaderauswahl/generierung und Konfiguration) sollte dann automatisch erfolgen.

loewe

2003-06-28, 19:35:15

Ich hoffe mal ich verstehe dein Problem, sehe es aber noch nicht als so ganz wichtig an.
Sicher wird in Spielen der Zukunft, 2006/07 oder später ist für mich Zukunft, die Frage der Prozedurale Texturen sehr wichtig werden. Da dann die Texturen nicht mehr über "einfache" Texturlayer erzeugt werden werden, sondern wie du schreibst über Formeln innerhalb der Shader berechnet werden, wird doch aber die Leistungsfähigkeit der Shader wesentlich die Fähigkeit der Grafikkarte bestimmen. Hier bei ist es besonders wichtig wieviele Befehle auf Texturen und/oder mathematische Operationen je Takt durchgeführt werden können. Ob dort die Leistung der heutigen Chips ausreicht möchte ich bezweifeln.

Was wir brauchen ist sowohl eine neue API als auch Hardware die mit so etwas umgehen kann.
Du verweist zu Beginn auf die versprochenen Fähigkeiten der GF256 die wir heute in den Spielen sehen, besser beginnen zu sehen. Aber nimm doch einmal für diess Spiele die GF256, sie hätte es doch auch gar nicht geschafft!

Ich denke mal die nächste Chipgeneration wird hier erste Ansätze liefern, nicht nur bei Stanford beschäftigt man sich mit solchen Problemen.

Demirug

2003-06-28, 20:41:13

loewe, ist es bis 2006/2007 noch wirklich so lange hin. Für Spiele die 2006 erscheinen müssen mehr als 24 Monate früher die wichtigen technologischen Entscheidungen getroffen werden. Und die benutzte API ist eine der ersten Entscheidungen die dabei anfällt. Ziehen wir von 2006/2007 2 Jahre ab sind wird schon bei 2004/2005. Nicht mehr viel Zeit um eine neue API aus dem Boden zu stampfen.

Zudem wird diese Problem auch schon schneller akut da es schon bei DX8 Karten (wenn auch nur im begrenzten Umfang) möglich ist einfache Licht und Material Modele zu benutzten. Der von mit oben erwähnte Feuerball welcher eine Oberfläche mit Bumpmap beleutet ist ein solches Beispiel. (Sieht übrigens ganz nett aus wenn man den Ball nicht zu schnell rotieren läst ;) ) Für solche eher einfachen Effekte wären die aktuellen Karten mächtig genug weil dabei noch viel mit Texturen gearbeitet wird.

Was die nächste Chipgeneration angeht so sehe ich da primär erst mal VS/PS 3.0. Aber was meine Wünsche angeht so reichen dafür ja wie gesagt primär sogar DX8 VS und PS aus. Das ganze ist eher eine Frage der API als der Technischen Möglichkeiten der Hardware.

Das man sich nicht nur in Stanford mit diesem Problem beschäftigt weiss ich aus eigener Erfahrung.

Xmas

2003-06-28, 22:02:03

Also wenn ich die OpenGL 2.0 Specs richtig verstehe, dann existiert das Problem dort nicht mehr, weil man mehrere Shaderfragmente einfach zusammenlinken kann.

loewe

2003-06-28, 22:05:12

Original geschrieben von Demirug
loewe, ist es bis 2006/2007 noch wirklich so lange hin. Für Spiele die 2006 erscheinen müssen mehr als 24 Monate früher die wichtigen technologischen Entscheidungen getroffen werden. Und die benutzte API ist eine der ersten Entscheidungen die dabei anfällt. Ziehen wir von 2006/2007 2 Jahre ab sind wird schon bei 2004/2005. Nicht mehr viel Zeit um eine neue API aus dem Boden zu stampfen.
Nein natürlich ist es nicht so lange!
Sowohl ihr als Spieleentwickler als auch die Hardwareentwickler müssen und machen sich da natürlich gedanken. Gegenwärtig ist es aber doch so, die Hardware ist der Software Jahre voraus. Das soll nichts bezüglich der Probleme aussagen, ob und wenn wie die Hardware dann die Games die die Feature wirklich nutzen betreiben kann.
Du hast natürlich recht mit den Entscheidungen bezüglich der API, aber bisher ist es doch so, es wird immer der kleinste gemeinsame Nenner gesucht. Das ist jetzt wohl in der Entwicklung DX8 Niveau und mag 2005/06 DX9 Niveau sein, ist damit heute aber noch weitgehend irrelevant.

Zudem wird diese Problem auch schon schneller akut da es schon bei DX8 Karten (wenn auch nur im begrenzten Umfang) möglich ist einfache Licht und Material Modele zu benutzten. Der von mit oben erwähnte Feuerball welcher eine Oberfläche mit Bumpmap beleutet ist ein solches Beispiel. (Sieht übrigens ganz nett aus wenn man den Ball nicht zu schnell rotieren läst ;) ) Für solche eher einfachen Effekte wären die aktuellen Karten mächtig genug weil dabei noch viel mit Texturen gearbeitet wird.
Da werdet ihr dann wohl, die Entscheidung ist ja auch schon vor geraumer Zeit gefallen :) , mit DX8 leben müssen und natürlich auch mit der entsprechenden Hardware.
BTW, ich hoffe ich erkenne dann den von dir angesprochenen Feuerball wieder, dann weiß ich endlich wo du arbeitest! =)

Was die nächste Chipgeneration angeht so sehe ich da primär erst mal VS/PS 3.0. Aber was meine Wünsche angeht so reichen dafür ja wie gesagt primär sogar DX8 VS und PS aus. Das ganze ist eher eine Frage der API als der Technischen Möglichkeiten der Hardware.

Das man sich nicht nur in Stanford mit diesem Problem beschäftigt weiss ich aus eigener Erfahrung.
:D

Demirug

2003-06-28, 22:55:18

Original geschrieben von Xmas
Also wenn ich die OpenGL 2.0 Specs richtig verstehe, dann existiert das Problem dort nicht mehr, weil man mehrere Shaderfragmente einfach zusammenlinken kann.

Ja das Code Fragmente linken kann man bei DX9 auch. Nur fehlt mir da in beiden Spec ein klarer Hinweiss bezüglich der Verbindungspunkte innerhalb einer Funktionseinheit. Also wie man zum Beispiel mehrer Pixelshaderteile verbindet. Es wird lediglich das Linken zwischen dem Vertex und dem Pixelanteil beschrieben.

Mit externen Tools kann man sich den Code auch zusammenstückeln lassen aber die muss man sich eben erst mal schreiben. Das dürfte aber auf lange sich der bessere Weg sein als alle notwendigen Kombinaten selbst zu schreiben und für irgendwas muss eine Engine (+Toolset) ja auch noch gut sein sonst wären sie ja ihr Geld nicht Wert.

Was mich aber immer noch stört ist das man dabei nach wie vor explizit Code für den Vertex und den Pixelanteil schreiben muss. Aber das soll ja nicht mein Problem sein da ich die Lösung dafür kenne.

Demirug

2003-06-28, 23:06:11

Original geschrieben von loewe
Nein natürlich ist es nicht so lange!
Sowohl ihr als Spieleentwickler als auch die Hardwareentwickler müssen und machen sich da natürlich gedanken. Gegenwärtig ist es aber doch so, die Hardware ist der Software Jahre voraus. Das soll nichts bezüglich der Probleme aussagen, ob und wenn wie die Hardware dann die Games die die Feature wirklich nutzen betreiben kann.
Du hast natürlich recht mit den Entscheidungen bezüglich der API, aber bisher ist es doch so, es wird immer der kleinste gemeinsame Nenner gesucht. Das ist jetzt wohl in der Entwicklung DX8 Niveau und mag 2005/06 DX9 Niveau sein, ist damit heute aber noch weitgehend irrelevant.

Der KGN hat schon starken einfluss weil man für jeden Effekt den man einbauen möchten eine Fallback auf diesen Technischen Level braucht. Zur Peformancesteigerung werden wir DX9 Shader schon früher sehen. Aber das ist bei DX8 ja auch nicht anders.

Da werdet ihr dann wohl, die Entscheidung ist ja auch schon vor geraumer Zeit gefallen :) , mit DX8 leben müssen und natürlich auch mit der entsprechenden Hardware.

Wir hatten schon eine DX9 Beta zur verfügung als wir diese Entscheidung getroffen haben. Zudem sind wir inzwischen soweit von der API abstrahiert das wir leicht wechseln können. Das "Leicht" ist natürlich relative. Je stärker die neue Ziel-API von DX9 abweicht desto mehr arbeit haben wir mit dem Toolset. Ein wechsel auf eine Cg bassierende OpenGL Lösung wäre dabei noch relative einfach. Ein umschreiben auf die Playstation 2 schon viel aufwendiger.

BTW, ich hoffe ich erkenne dann den von dir angesprochenen Feuerball wieder, dann weiß ich endlich wo du arbeitest! =)

Das glaube ich nicht. Den Ball benutzte ich eigentlich nur füt interne Tests ob der Toolchain noch funktioniert.

Xmas

2003-06-28, 23:40:42

Original geschrieben von Demirug
Ja das Code Fragmente linken kann man bei DX9 auch. Nur fehlt mir da in beiden Spec ein klarer Hinweiss bezüglich der Verbindungspunkte innerhalb einer Funktionseinheit. Also wie man zum Beispiel mehrer Pixelshaderteile verbindet. Es wird lediglich das Linken zwischen dem Vertex und dem Pixelanteil beschrieben.
Also bei OpenGL2.0 ist es so dass ein "Shader" ein Codefragment ist, entweder vom Typ VERTEX_SHADER oder FRAGMENT_SHADER. Diese werden compiliert und an ein "Program"-Objekt gehängt. Linkt man dieses Program-Objekt, werden alle angehängten Fragment-"Shader" zu einem Fragment-Program und alle angehängten Vertex-"Shader" zu einem Vertex-Program gelinkt.

Leider ist es so nicht direkt möglich dasselbe Shader-Fragment für Vertex und Fragment zu verwenden, dafür muss man zwei Shader-Objekte mit demselben Code erzeugen.

Mir wäre es im Prinzip am liebsten wenn es eine VertexMain und eine FragmentMain gäbe, und der restliche Code frei in beiden Teilen verwendbar wäre (solange darin kein Vertex- oder Fragment-Attribut verwendet wird)

Demirug

2003-06-29, 00:02:37

Original geschrieben von Xmas
Also bei OpenGL2.0 ist es so dass ein "Shader" ein Codefragment ist, entweder vom Typ VERTEX_SHADER oder FRAGMENT_SHADER. Diese werden compiliert und an ein "Program"-Objekt gehängt. Linkt man dieses Program-Objekt, werden alle angehängten Fragment-"Shader" zu einem Fragment-Program und alle angehängten Vertex-"Shader" zu einem Vertex-Program gelinkt.

Ja soweit ist das ja alles klar. Die Frage ist aber nun folgeden.

Ich habe ein Fragmentprogramm welches einen Lichtvektor und eine Lichtfarbe liefert. Nun habe ich ein zweite Programm welches diese beiden Werte weiter verrechnen soll. Was mir nun fehlt ist eine Information wie ich Werte von einem Programm zu einem anderen übertragen kann wenn diese beide im gleichen Shaderteil ablaufen. Möglicherweise habe ich das aber auch übersehen.

Zudem ist mir auch nicht ganz klar geworden was passiert wenn ich mehrer Fragmentprogramme zusammen linken möchte und die alle einen Wert zurück geben.

Leider ist es so nicht direkt möglich dasselbe Shader-Fragment für Vertex und Fragment zu verwenden, dafür muss man zwei Shader-Objekte mit demselben Code erzeugen.

Damit könnte ich zur not leben.

Mir wäre es im Prinzip am liebsten wenn es eine VertexMain und eine FragmentMain gäbe, und der restliche Code frei in beiden Teilen verwendbar wäre (solange darin kein Vertex- oder Fragment-Attribut verwendet wird)

So läuft das im Prinzip bei HLSL und Cg ab.

Was ich möchte ist aber eher sowas.

Eine Materialklasse

public class BumpTexMat : Material
{
public override ColorRGBA GetColor ()
{
MatTextur.Filter = TextureFilter.Trilinear;

ColorRGB Result = new ColorRGB();

Matrix3x3 worldtotangent = new Matrix3x3 ();

worldtotangent.Columns[0] = geometrie.GetTangent (Space.Object);
worldtotangent.Columns[1] = geometrie.GetBiNormal (Space.Object);
worldtotangent.Columns[2] = geometrie.GetNormal (Space.Object);

foreach (Light light in Lights)
{
Vector3 lightvector = light.GetLightVector(Space.Object);

lightvector *= worldtotangent;

lightvector = (Fragment.Vector3)((lightvector+new Vector3(1.0f, 1.0f, 1.0f)) / 2);

Result += light.GetDiffuse () *
Vector3.Dot ((lightvector-new Vector3(0.5f, 0.5f, 0.5f))*2,
(BumpTextur[Texcoordidate]-new Vector3(0.5f, 0.5f, 0.5f))*2);
}

return CurrentColor + new ColorRGBA(Result * MatTextur[Texcoordidate]);
}

public Vertex.Vector2 Texcoordidate;
public Fragment.RGBTexture MatTextur;
public Fragment.Vec3Texture BumpTextur;
}

Und eine Lichtklasse

public class FireBall : Light
{
public override ColorRGB GetDiffuse ()
{
Vector3 LightVector = LightPos - new Vector3(geometrie.GetPos(Space.World));

float Length = LightVector.Length;

Matrix Ballrotation = Matrix.RotationX (BallRotationX) *
Matrix.RotationY (BallRotationY) *
Matrix.RotationY (BallRotationZ);

LightVector.Normalize ();
Vector3 TexLightVector = LightVector * Ballrotation;
TexLightVector.Normalize ();

float Attenuation = 1 / (A0 + A1 * Length + A2 * Length * Length);

return FireTexture[TexLightVector] * Attenuation;
}

public override Vector3 GetLightVector (Space space)
{
Vector3 LightVector = null;

switch (space)
{
case Space.World:
LightVector = LightPos - new Vector3(geometrie.GetPos(Space.World));
break;

case Space.Object:
Matrix World = geometrie.GetWorld();
World.Transpose ();

Vector3 ObjectLight = LightPos*World;

LightVector = ObjectLight - new Vector3(geometrie.GetPos(Space.Object));
break;
}

LightVector.Normalize ();

return LightVector;
}

public Fragment.RGBTexture FireTexture;
public Shader.Vector3 LightPos;
public float Radius;
public Shader.Float A0;
public Shader.Float A1;
public Shader.Float A2;
public Shader.Float BallRotationX;
public Shader.Float BallRotationY;
public Shader.Float BallRotationZ;
}

Das beides (+ eine Geometrieklasse) dem System übergeben die Werte parametrien und der Rest soll nicht mehr mein Problem sein.

Xmas

2003-06-29, 01:13:55

Original geschrieben von Demirug
Ja soweit ist das ja alles klar. Die Frage ist aber nun folgeden.

Ich habe ein Fragmentprogramm welches einen Lichtvektor und eine Lichtfarbe liefert. Nun habe ich ein zweite Programm welches diese beiden Werte weiter verrechnen soll. Was mir nun fehlt ist eine Information wie ich Werte von einem Programm zu einem anderen übertragen kann wenn diese beide im gleichen Shaderteil ablaufen. Möglicherweise habe ich das aber auch übersehen.

Zudem ist mir auch nicht ganz klar geworden was passiert wenn ich mehrer Fragmentprogramme zusammen linken möchte und die alle einen Wert zurück geben.
Ich habe das eigentlich so verstanden, dass jeder Teil(Fragment/Vertex) nur eine main() haben kann, also dass das ganze so wie beim Linken mit C passiert. Man hat also eine main() die verschiedene Funktionen aufruft und tauscht dann die Implementation dieser Funktionen flexibel aus.

Ich gehe mal stark davon aus dass du den Beispielcode nicht gerade eben erst geschrieben hast ;)

Demirug

2003-06-29, 08:46:23

Original geschrieben von Xmas
Ich habe das eigentlich so verstanden, dass jeder Teil(Fragment/Vertex) nur eine main() haben kann, also dass das ganze so wie beim Linken mit C passiert. Man hat also eine main() die verschiedene Funktionen aufruft und tauscht dann die Implementation dieser Funktionen flexibel aus.

Ja stimmt, so kann man das auch interpretieren. Hört sich auch irgendwie passend an.

Ich gehe mal stark davon aus dass du den Beispielcode nicht gerade eben erst geschrieben hast ;)

Ach sieht man das? Ja das ganze ist schon älter. Die beiden Klassen sind zu testen ob der DX8 Generator noch funktioniert. Wobei ich gesehen habe das ich die alte Version ohne Renormalisierung des Lichtvektors erwischt habe.

ScottManDeath

2003-06-29, 14:22:11

Hi

ist das dein MSIL -> CG/HLSL/VS/PS compiler den du irgenwo mal erwähnt hast ??

Bye
ScottManDeath

Demirug

2003-06-29, 14:58:40

Original geschrieben von ScottmanDeath
Hi

ist das dein MSIL -> CG/HLSL/VS/PS compiler den du irgenwo mal erwähnt hast ??

Bye
ScottManDeath

Ja der gehört da auch dazu. Ist aber nur ein Teil (wenn auch ein wichtiger) des gesamten Systems.

Der Namenlose

2003-06-29, 15:24:58

Ich denke, mann kann den Material/Geometrie-Teil sehr gut vom Lichtteil separieren. Zumindest für alles was nicht transparent ist.
Da man ja ab DX9 mehrere Renderbuffer im Float-Genauigkeit zur Verfügung hat, kann man dort im ersten Schritt Position, Normalen, Farbe und Spekularverhalten rein rendern. Die Beleuchtung findet dann im nächsten Schritt statt. Das hat mehrere Vorteile.
1. Man kann beliebig kombinieren
2. Man beleuchtet nur die sichtbaren Pixel. Der jetzige Early-Z-Check ist zwar ein Fortschritt, aber bei Alpha-Reject und komplizierten Shadern bringt es nichts. Fell oder Gras ist so ein Beispiel.
3. Beleuchtung braucht kaum noch Vertexleistung, da nur ein Quad über die relevanten Berecih gerendert wird. Die eigentliche Beleuchtung findet im Pixelshader statt.

Demirug

2003-06-29, 15:45:33

Original geschrieben von Der Namenlose
Ich denke, mann kann den Material/Geometrie-Teil sehr gut vom Lichtteil separieren. Zumindest für alles was nicht transparent ist.
Da man ja ab DX9 mehrere Renderbuffer im Float-Genauigkeit zur Verfügung hat, kann man dort im ersten Schritt Position, Normalen, Farbe und Spekularverhalten rein rendern. Die Beleuchtung findet dann im nächsten Schritt statt. Das hat mehrere Vorteile.
1. Man kann beliebig kombinieren
2. Man beleuchtet nur die sichtbaren Pixel. Der jetzige Early-Z-Check ist zwar ein Fortschritt, aber bei Alpha-Reject und komplizierten Shadern bringt es nichts. Fell oder Gras ist so ein Beispiel.
3. Beleuchtung braucht kaum noch Vertexleistung, da nur ein Quad über die relevanten Berecih gerendert wird. Die eigentliche Beleuchtung findet im Pixelshader statt.

Das Funktioniert aus mehrern Gründen nicht wirklich gut.

1. Float-Buffer sind Bandbreitenfresser.
2. Float-Buffer sind Speicherfresser.
3. Multirender Targets werden nicht allgemein unterstützt was dazu führt das man zum füllen der 4 Floatbuffer 4 mal die geometrie durchjagen müsste.
4. AA würde nicht mehr funktionieren.
5 Für jede Lichtquelle müsste für jeden Pixel die gesammte beleuchtung berechnet werden. Dabei vieles im Pixelshader was man normalerweise auch im Vertexshader tun könnte.

Zum Thema HSR. Die Berechung der Material-Pixelfarbe muss trotzdem noch durchgeführt werden. Das beste bei komplexen shader ist immer noch ein Z-Only-Pass einzuschieben.

Der Namenlose

2003-06-29, 16:10:21

Original geschrieben von Demirug
Das Funktioniert aus mehrern Gründen nicht wirklich gut.

1. Float-Buffer sind Bandbreitenfresser.

Das war TrueColor auch mal.
Original geschrieben von Demirug
2. Float-Buffer sind Speicherfresser.

Speicher sollten die Karten eigentlich genug haben. Zumindest in den Zeiträumen und Mindestvoraussetzungen, von denen wir sprechen.
Original geschrieben von Demirug
3. Multirender Targets werden nicht allgemein unterstützt was dazu führt das man zum füllen der 4 Floatbuffer 4 mal die geometrie durchjagen müsste.

Die dann vorhandenen Karten werden es unterstützen.
Original geschrieben von Demirug
4. AA würde nicht mehr funktionieren.

Dann macht dir doch ein eigenes Supersampling :-) Damit fallen gleich noch ein paar Probleme des heutigen AA weg. (OK, die Antwort ist vielleicht nicht sonderlich werthaltig.)
Original geschrieben von Demirug
5 Für jede Lichtquelle müsste für jeden Pixel die gesammte beleuchtung berechnet werden. Dabei vieles im Pixelshader was man normalerweise auch im Vertexshader tun könnte.

Es muß nur da berechnet werden, wo die Lichtquelle auf dem Bidlschirm potentiellen Einfluß hat. Richtige Pixelgenaue Beleuchtung kann sowieso kaum Rechnungen im Vertexshader ausführen, da es zu Ungenauigkeiten kommt. Und wenn die Flächen so klein sind, dass die Ungenauigkeiten nicht stören, dann kan man in der Regel sehr kleine Flächen. Und dort wäre der Aufwand insgesamt im Pixelshader nicht höher als das was sonst im Vertexshader an Last anfällt, zumal der komplettte Overdraw/Backfaces durch die Vertexpipline fließt, nicht aber durch die Pixelpipe.

Demirug

2003-06-29, 16:38:57

Original geschrieben von Der Namenlose
Das war TrueColor auch mal.

Ist es immer noch. Aber von 16Bit Farbe auf 32 Bit Farbe war es der Faktor 2. Von 32 Bit Frabe auf FP32 wäre es schon Faktor 4. Und wenn wir 4 Buffer benutzten kommen wir auf den faktor 16.

Speicher sollten die Karten eigentlich genug haben. Zumindest in den Zeiträumen und Mindestvoraussetzungen, von denen wir sprechen.

relative. Ohne AA wären bei 1280*1024 schon 80 MB weg. eine

Die dann vorhandenen Karten werden es unterstützen.

Ich kann nur Technicken einsetzten welche dann auch wenn den Lowendkarten unterstützt werden. Und das sehe ich für den relevanten Zeitraum nicht.

Dann macht dir doch ein eigenes Supersampling :-) Damit fallen gleich noch ein paar Probleme des heutigen AA weg. (OK, die Antwort ist vielleicht nicht sonderlich werthaltig.)

Da Spare ich mir mal einen Komentar.

Es muß nur da berechnet werden, wo die Lichtquelle auf dem Bidlschirm potentiellen Einfluß hat. Richtige Pixelgenaue Beleuchtung kann sowieso kaum Rechnungen im Vertexshader ausführen, da es zu Ungenauigkeiten kommt. Und wenn die Flächen so klein sind, dass die Ungenauigkeiten nicht stören, dann kan man in der Regel sehr kleine Flächen. Und dort wäre der Aufwand insgesamt im Pixelshader nicht höher als das was sonst im Vertexshader an Last anfällt, zumal der komplettte Overdraw/Backfaces durch die Vertexpipline fließt, nicht aber durch die Pixelpipe.

Ach man kann schon einiges im VS berechnen und dann die Interpolation nutzen. Den Bereich etwas einzugrenzen ist natürlich möglich.

Deine Überlegung bezüglich des Overdraw und Backfaces ist korrekt aber es gibt viel mehr Pixel als Verticen. Dadurch wird jede Berechnung die man vom Vertexhsader in den Pixelshader verschiebt richtig teuer.

zeckensack

2003-06-29, 17:15:33

Bzgl GL2 (http://www.3dlabs.com/support/developer/ogl2/specs/index.htm):
Man kann beliebige Vertex- und Fragmentshader mischen. Der Datenaustausch erfolgt über als 'varying' (=interpoliert) deklarierte Variablen (Skalare oder Vektoren), die anhand ihres Namens zugeordnet werden. Diese Namen darf man sich frei aussuchen.

Es ist in GLslang legal, im vertex shader outputs zu deklarieren und zu beschreiben, die im fragment shader überhaupt nicht benutzt werden. Diese Fälle sollen beim 'linken' aufgelöst werden, dh daß theoretisch an diesem Punkt überflüssiger Code entfernt werden kann. Hier erfolgt auch der Check, ob alle Teile zusammenpassen.

Das Kombinatorik-Problem zu lösen liegt also beim Treiber, was ich persönlich ganz gut finde. Applikationen können das idR nicht so effizient, schon garnicht bei so starker Abstraktion.

Demirug

2003-06-29, 17:33:05

Original geschrieben von zeckensack
Bzgl GL2 (http://www.3dlabs.com/support/developer/ogl2/specs/index.htm):
Man kann beliebige Vertex- und Fragmentshader mischen. Der Datenaustausch erfolgt über als 'varying' (=interpoliert) deklarierte Variablen (Skalare oder Vektoren), die anhand ihres Namens zugeordnet werden. Diese Namen darf man sich frei aussuchen.

Das mit varying ist klar.

Mir ging es um den Datenaustauch innerhalb des Fragmentshaders. Das hat sich wohl aber geklärt wenn die Sichtweise von Xmas richtig ist. Das man aus einer Funktion in einem Shader einfach Funktionen in einem anderen aufrufen darf.

Es ist in GLslang legal, im vertex shader outputs zu deklarieren und zu beschreiben, die im fragment shader überhaupt nicht benutzt werden. Diese Fälle sollen beim 'linken' aufgelöst werden, dh daß theoretisch an diesem Punkt überflüssiger Code entfernt werden kann. Hier erfolgt auch der Check, ob alle Teile zusammenpassen.

Ja das geht bei HSLS und Cg auch. Wobei hierbei bis zu den PS 3.0 die Bindung etwas statischer ist. Die Option unbenutzte teile zu entfernen bleibt aber auch dort erhalten. Womit wir aber wieder mal beim Thema Shaderbäume sind den genau diese braucht man für solche Operationen.

Das Kombinatorik-Problem zu lösen liegt also beim Treiber, was ich persönlich ganz gut finde. Applikationen können das idR nicht so effizient, schon garnicht bei so starker Abstraktion.

Welche Problem löst der Treiber?

Das einzige was er tut ist die Interpolatoren zuzuweisen. Dies ist ein relativ einfacher Job wenn die Summe der benötigten Interpolatoren bekannt ist.

Den einzigen Vorteil den ich sehe ist das die einzelnen Codeteile vom Treiber in einer vorverarbeiteten Form gespeichert werden kann was das linken beschleunigen sollte.

Aber wie gesagt geht mir die Abstraktion da einfach nicht weit genug. Ich bevorzuge die Renderman Sicht auf dieses Problem.

zeckensack

2003-06-29, 18:07:46

Original geschrieben von Demirug
Welche Problem löst der Treiber?

Das einzige was er tut ist die Interpolatoren zuzuweisen. Dies ist ein relativ einfacher Job wenn die Summe der benötigten Interpolatoren bekannt ist.

Den einzigen Vorteil den ich sehe ist das die einzelnen Codeteile vom Treiber in einer vorverarbeiteten Form gespeichert werden kann was das linken beschleunigen sollte.Exakt das nehme ich schonmal ;)
Außerdem die unterschiedlichen Kombinationen von Shadern (VS A/B/C * FS X/Y/Z), wobei ja jeweils unterschiedlicher VS-Code herauskommen kann, je nachdem welcher FS hintendran hängt. Deswegen habe ich den Begriff 'Kombinatorik' benutzt :)

Durch das Zusammenstückeln von Shadern aus mehreren Code-Fragmenten (die in Objekte gekapselt sind), ist es möglicherweise sogar sinnvoll, die Codeschnipsel bei Übergabe an die API erstmal nur in ein internes Zwischenformat zu parsen (plus Syntax-Check), und das eigentliche Kompilieren erst beim Linken auszuführen, je nach angestrebter Optimierungsstärke.

Zurück zur Kombinatorik, dieses interne Zwischenformat ist voraussichtlich wesentlich kompakter als der Quellcode, und auch schneller kompilierbar. Das ist IMO ressourcenschonender, als wenn die unterschiedlichen 'Mischungen' explizit als eigener Quellcode in der Applikation rumfliegen würden.

PS: war nur ergänzend gemeint, was XMas geschrieben hat habe ich schon gesehen :)

Demirug

2003-06-29, 18:46:38

Original geschrieben von zeckensack
Exakt das nehme ich schonmal ;)
Außerdem die unterschiedlichen Kombinationen von Shadern (VS A/B/C * FS X/Y/Z), wobei ja jeweils unterschiedlicher VS-Code herauskommen kann, je nachdem welcher FS hintendran hängt. Deswegen habe ich den Begriff 'Kombinatorik' benutzt :)

Ja, Äste(Berechnungen) die bei bestimmten Kombinationen nicht gebraucht werden kann/sollte man entfernen. Diese Fähigkeit wird eine Sache sein die einen guten von einem weniger guten Treiber unterscheidet.

Durch das Zusammenstückeln von Shadern aus mehreren Code-Fragmenten (die in Objekte gekapselt sind), ist es möglicherweise sogar sinnvoll, die Codeschnipsel bei Übergabe an die API erstmal nur in ein internes Zwischenformat zu parsen (plus Syntax-Check), und das eigentliche Kompilieren erst beim Linken auszuführen, je nach angestrebter Optimierungsstärke.

Das ist auf jeden Fall sinnvoll. Beim Wechsel von Hochsprache auf MSIL bin ich schon ein ganzen Stück schneller geworden. Lexer und Parser sind nun mal leider nicht so schnell. MSIL ist aber auch noch nicht perfekt deswegen gehe ich gerade dazu über die Methoden als Astteile zu speichern welche dann einfach in den Baum einkopiert werden können.

Zurück zur Kombinatorik, dieses interne Zwischenformat ist voraussichtlich wesentlich kompakter als der Quellcode, und auch schneller kompilierbar. Das ist IMO ressourcenschonender, als wenn die unterschiedlichen 'Mischungen' explizit als eigener Quellcode in der Applikation rumfliegen würden.

PS: war nur ergänzend gemeint, was XMas geschrieben hat habe ich schon gesehen :)

Naja auf die paar KB würde es nicht ankommen wenn man an die MB von Daten für Geometrie und Texturen denkt.

Nur wenn man zum Optimieren des Shaders sowieso sowohl den Vertex und Fragmentanteil zusammen berücksichtigen muss frage ich mich warum man beides nicht gleich zusammenwirft. Was mir ebenfalls noch ganz klar fehlt (sowohl bei DX wie auch bei OpenGL 2.0) ist die möglichkeit Shader auf Shader und Objekt ebene zu schreiben. Was ich damit meine ist folgendes:

Ein Shaderprogramm auf Shader ebene soll jedes mal ausgeführt werden bevor der erste Drawcall für diesen Shader gerendert wird. Ein Programm auf Objectebene soll für jeden Drawcall einmal ausgeführt werden. Der Sinn und Zweg des ganzen ist folgender. Möchte man auf dieser Ebene Berechnungen ausführen muss man diese entweder mit einer eigenen Scriptsprache ausführen oder fest einprogrammieren. In beiden Fällen ist das System zur Shadererstellung nicht mehr einheitlich.

Was mir auch noch fehlt ist die Möglichkeit den Rest der Pipeline zu kontrollieren.

Sowas

if (geometrie.GetPos(Space.Display) > ZBuffer)
{
if (backface)
++stencil;
else
--stencil;
}

fände ich extrem nett.

Pitchfork

2003-06-29, 19:32:48

Bist du sicher, daß du nicht in eine völlig falsche Richtung denkst?

1. Die nächsten Engines sind alle Multipass, daran wird sich nix ändern, bzw. es wird nur noch stärker. Ein Pixel setzt sich aus verschiedenen völlig unterschiedlichen Infos zusammen, die man nicht ohne weiteres in einen Pass pressen kann. Da wären: Illumination (viele verschiedene Lichtquellen wie Sonne, Fackel, Feuer, Taschenlampe und ihre Schatten), Material (Holz, Metall, Stoff, Gras) und globale Effekte (Nebel, Motion Blur, Depth of Field, Light Adaption).

Selbst wenn ich organisatorisch in der Lage wäre, alles in einem Pass zu vereinigen (also die Verwaltung von 20000 Shadern), komme ich an viele technische Limitationen, die es mir unmöglich machen.

2. Ich sehe Dein Problem mit der Kombinatorik nicht (aber ich habe den Thread auch nicht komplett gelesen).

Mein Ansatz dazu (noch nicht implementiert!): ich habe eine Datenstruktur, die mir einen Shader beschreibt und in der alle Daten drin stehen, die ich zur Auswahl eines Shaders brauche (Anzahl und Typen der Lichtquellen, Material, Materialparameter, etc.pp.). Nun habe ich eine große Bibliothek von HLSL Funktionen, die mir die Bausteine liefern. Nun erzeuge ich dynamisch eine passende main Funktion dazu und compiliere den Shader. Der Shader wird nun für den Rest des Programmablaufs gecachet.
Wo ist da das große Problem? Wozu brauche ich dynamic branching?

Pitchfork

PS: So langsam interessiert es mich ja schon, wo du arbeitest, Demirug.

Demirug

2003-06-29, 20:01:34

Original geschrieben von Pitchfork
Bist du sicher, daß du nicht in eine völlig falsche Richtung denkst?

1. Die nächsten Engines sind alle Multipass, daran wird sich nix ändern, bzw. es wird nur noch stärker. Ein Pixel setzt sich aus verschiedenen völlig unterschiedlichen Infos zusammen, die man nicht ohne weiteres in einen Pass pressen kann. Da wären: Illumination (viele verschiedene Lichtquellen wie Sonne, Fackel, Feuer, Taschenlampe und ihre Schatten), Material (Holz, Metall, Stoff, Gras) und globale Effekte (Nebel, Motion Blur, Depth of Field, Light Adaption).

Selbst wenn ich organisatorisch in der Lage wäre, alles in einem Pass zu vereinigen (also die Verwaltung von 20000 Shadern), komme ich an viele technische Limitationen, die es mir unmöglich machen.

Genau darum geht es ja. Aus den ganzen Dinge die auf ein Object wirken sollen soll das System die entsprechenden Shader erzeugen aus den Informationen wie sich die einzelnen Teile auswirken.

Ach in so ca 500 Instruktionen und und mit 16 Texturen kann man schon eine Menge in einen Pass pressen. Zudem ist es ja auch das erklärte Ziel das Aufteilen auf mehrer Passes bei Bedarf das System machen zu lassen.

2. Ich sehe Dein Problem mit der Kombinatorik nicht (aber ich habe den Thread auch nicht komplett gelesen).

Mein Ansatz dazu (noch nicht implementiert!): ich habe eine Datenstruktur, die mir einen Shader beschreibt und in der alle Daten drin stehen, die ich zur Auswahl eines Shaders brauche (Anzahl und Typen der Lichtquellen, Material, Materialparameter, etc.pp.). Nun habe ich eine große Bibliothek von HLSL Funktionen, die mir die Bausteine liefern. Nun erzeuge ich dynamisch eine passende main Funktion dazu und compiliere den Shader. Der Shader wird nun für den Rest des Programmablaufs gecachet.
Wo ist da das große Problem? Wozu brauche ich dynamic branching?

Pitchfork

Ja diesen Ansatz habe wir auch verfolgt habe dabei aber leider zu viele Probleme festgestellt.

-Bei komplexen Zusammenstellungen gehen einem auf DX8 Karten zu schnell die Resourcen aus und man muss spliten. Auf der Ebene der Sourcecodefragmente ist das fast unmöglich.

-HLSL und Cg sehen leider keine möglichkeit vor teile des Shaders auf der CPU ablaufen zu lassen. Wir haben aber fälle wo man bestimmte Berechnungen nur einmal beim benutzen des Shaders durchführen muss. Die Rotationsmatrix meines Feuerballs ist so ein Beispiel. Die Matrix muss aus 3 Winkeln berechnet werden aber eben nur einmal für alle Verticens die von diesem Feuerball beleuchtet werden und nicht für jeden Vertex einzeln. Wir wollen aber beim besten willen dafür nicht auch noch eine eigene Shadersprache haben.

-Entfernen von unötigen Codeteilen ist auf Codefragment Ebene nicht ganz einfach mal will ja nicht zuviel heraustrennen aber die Shader auch nicht unnötige Daten berechnen lassen. Da bei DX die Vertex und Pixelshader ja erst zur laufzeit gebunden werden haben wir keine Hoffnung das dabei der Treiber unbenutzte Codeteile automatisch entfernt.

-Umverteilen von Code auf unterschiedliche Einheiten ist ebenfalls nicht ganz einfach.

-Einheiten welche durch die API nicht für die verwendung von Shaderhochsprachen vorgesehen sind bleiben mir versperrt und müssen auf andere Art und Weise konfiguiert werden.

Deswegen haben wir das bleiben lassen und bauen Shaderbäume auf welche dann auf die einzelen Einheiten (Vertexshader, Pixelshader, TMUs, Alphablending, usw) des Chips entsprechend verteilt werden.

Ich brauche kein dynamic branching. Werde es aber trotzdem begrüssen weil man damit eben gut per Pixel LOD-Shader bauen kann.

PS: So langsam interessiert es mich ja schon, wo du arbeitest, Demirug.

Namen sind wie Schall und Rauch. Es würde niemanden nützen wenn ich Namen nennen würde weil uns niemand kennt. Also kurz gesagt ich arbeite für keinen der grossen bekannten deutschen Läden. Dort würde ich auch gar nicht den Forschungeta bekommen denn ich schon verbraten habe.