Hallo!

Währrend ich noch immer ein wenig an dem Bumpmapping rumprobiere mache ich mir schon Gedanken, wie ich später das ganze in Mengen rendern soll.
Für reine Innenlevel ist ein BSP-Baum ja optimal, aber ich wollte das ganze möglichst flexibel aufbauen, also nicht zwangsweise geschlossene Räume, und man soll das ganze auch nach außen hin verlassen können (wofür hat man sonst nen Terrain? ). Ist da ein BSP-Baum noch immer gut geeignet, oder reicht ein Octree aus, um auch komplexe Innenlevel rendern zu können? Und lässt sich irgendetwas sonst nicht mit einer der beiden techniken realisieren?

_________________
Thunderman
Bei schwierigen Problemen entscheiden wir uns einfach für die richtige Lösung. Klar?

Ich würde überhaupt keine Struktur nehmen, bei der es auf einzelne Dreiecke mehr ankommt. Man könnte ja Dreiecke immer zu Objekten zusammenfassen. Das können Bereiche auf der Landschaft wie z.B. eine Bezierfläche sein oder detaillierte Objekte im Innenbereich sein.
Dann könne man eine Baum aus den AABB der Objekte bauen. Der Baum ist so ähnlich wie ein Octree nur kleiner. Jeder Knoten hat eine AABB und zwei Verweise auf Unterknoten oder eben ein Objekt mit Dreiecken. Dadurch daß man nicht mehr die einzelnen Dreiecke betrachtet hat man den Vorteil, daß die Tiefe des Baumes unabhängig von der Komplexität der Objekte ist. Man sollte bei gldrawelements immer mindestens einige hundert Dreiecke übergeben. Da jedes Objekt ja aus vielen Dreiecken bestehen kann, die man vorher schon nach Shader sortiert hat, kann man das Rendern vereinfachen. Für die AABB reicht es auch integer Zahlen zu nehmen, da sie genau genug, aber viel scheller als single Werte sind.
Für das Occlusion Culling kann man, wenn es sich anbietet Portale nehmen und in jedem Sektor so einen Baum aufbauen, oder so eine Art HW Occlusion Culling wie auf Delphi3D vorgestellt worden ist. Da jedes Objekt ja idealerweise aus vielen Dreicken besteht, die aber meistens alle zusammen sichtbar sind, lohnt es sich hier auch erstmal mit einer Occlusion Query zu testen, ob das Objekt sichtbar ist.

Dazu hab ich jetzt mal eine kleine Frage:
Angenommen ich habe Objekte erstellt, die meist aus ein paar hundert Dreiecken bestehen. Die Vertexdaten ansich könnte ich natürlich prima in VBO und EBO packen und dann rendern. Aber so ein Object besteht ja nicht aus einfachen festen Dreiecken, sondern bei jedem Renderdurchgang werden die Farben oder Texturekoordinaten für das Bumpmapping geändert. Außerdem hat so ein Objekt nicht nur eine Textur, sondern theoretisch jedes Dreieck doch eine andere.
Ich bin soweit, dass ich das erste Problem vermutlich so lösen würde, dass ich die Vertexdaten (Position und Normale) entweder festlasse und die Farbwerte als dynamisches Array übergebe, wenn dies geht, oder eben für jeden Renderdurchgang die Daten ändere und dann dynamische Vertex-Arrays verwende.
Das Texturenproblem macht mir aber mehr Sorgen. Ich könnte zwar wie etwa Aya momentan bei ihren Lightmaps die Texturen alle in eine packen und diese dann per Texturekoordinaten auswählen (entsprechend für Normalmap), aber bei einem Object mit über hundert Dreiecken weiß ich nicht, ob ich da alle Texturen in eine große bekomme. :unsure: Gibt es da sonst nur noch die Lösung in ein VBO nur Dreiecke zu packen die die gleiche Textur haben? Dann würde ich aber nicht oft ein zusammenhängendes Objekt erhalten, und damit die Occlusion-Tests, etc fast unnütz machen.

_________________
Thunderman
Bei schwierigen Problemen entscheiden wir uns einfach für die richtige Lösung. Klar?

Meistens haben Gruppen von Dreiecken die gleiche Texture, denn es gibt ja meistens mehr Dreiecke als verschiedene Texturen in einem Level.
Wenn man pro Objekt einen Vertexbuffer und einen Indexbuffer hat, dann kann man es so machen: Sortier die Dreiecke pro VBO einfach nach der Texture.Dann weiß man Index 0 bis Index X1 hat die Texture1 und ab X1 gehts es dann bis Index X2 mit der nächsten Texture weiter. Wenn man ein detailliertes Objekt hat, dann besteht das ja aus vielen Dreicken, aber es hat meistens weniger Texturen.
Alle Dreiecke, die die gleiche normale Texture haben, bekommen dann auch die gleiche Lightmap.
Pro VertexBuffer und IndexBuffer gibt es dann folgendes
Start Länge Texture
0 10 bild1.bmp
10 32 bild2.bmp
42 64 bild3.bmp

Oder lass die Lightmap am besten gleich ganz weg und verwende Stencil Buffer Schatten oder Shadowmaps.

Ich habe z.B. bei der Demo folgendes Vertex Format verwendet und brauchte die Daten nie zu ändern.

TDrawVertex=record
pos:TVertex;
texu,texv:smallint;
rest:array[0..3] of byte;
n:array[0..2] of Smallint;
t:array[0..2] of Smallint;
end;

Da sind die Normale,die Tangente, die Position und die Texturekoordinaten enthalten und isgesammt sind es 32 Byte.
Leider wird bei ARB_VERTEX_BUFFER_OBJECT nicht mehr verlangt, daß alle Formate wie gl_short unterstützt werden müssen, so daß ich das Vertex Format vergrößern mußte.

Wenn du Vertex Daten dynamisch berechnen möchtest, dann kannst du das beim Bumpmapping z.B. auch über die Vertex Programme machen.
Für Shadereffekte wie das Verschieben oder Drehen einer Texture kanns man eine eine 2*3 Matrix berechnen und dem Vertex Program übergeben.

Hm, werd versuchen das mal so oder so ähnlich umzusetzen.
Vertexprogramme sind natürlich eine Möglichkeit. Verändern muss ich ja nur die Farbwerte wenn ich den Lichtvektor als Farbwert für den jeweiligen Vertex speichere (sofern sich das Licht oder das Object bewegt), oder eben die Texturkoordinaten für die Cubemap (wobei das eh noch überhaupt nicht hinhaut mit der Cubemap).

Btw: ich verwende doch keine Lightmaps. Habe nur Normalmaps für's Bumpmapping, und die entsprechen doch nicht immer zwingen der normalen Textur, aber natürlich meistens, von daher sollte das eigentlich irgendwie zu sortieren gehen.

_________________
Thunderman
Bei schwierigen Problemen entscheiden wir uns einfach für die richtige Lösung. Klar?

Wenn man dem Vertex Program, die Lichtposition als Parameter übergibt, dann kann man pro Vertex diesen Lichtvektor berechnen und auch noch in den Tangent Space bringen.

OK, ARB_VERTEX_PROGRAM scheint ja auf genügend Karten unterstützt zu werden, und wenn man eh schon einiges vorraussetzt können diese Karten dann das auch. Irgendwo muss man ja anfangen.

_________________
Thunderman
Bei schwierigen Problemen entscheiden wir uns einfach für die richtige Lösung. Klar?

Ich habe früher auf der GF1 die Software Emulation von ARB_VP ohne Probleme verwendet. Das ist auf jeden Fall schnell genug für einfache Szenen, die nicht aus 10.000 von Dreiecken bestehen. Die Software Implementation von ARB_VP ist auf jeden Fall auch für spezielle Prozessoren (3DNow,SSE) optimiert und deshalb vermutlich auch schneller, als wenn du das selber in deiner Engine ausrechnest.

OK, gut zu wissen.
Dann werde ich jetzt mal anfangen das ganze mit VBO und Vertex-Program umzusetzen. Wenn Vertex-Programme so gut in Software emuliert werden können, überleg ich mir auch nochmal dann VBOs alternativ durch normale Vertex-Arrays zu ersetzen. Dann dürfte das ganze sogar auf recht einfachen Systemen laufen, solange dot3 unterstützt wird.

_________________
Thunderman
Bei schwierigen Problemen entscheiden wir uns einfach für die richtige Lösung. Klar?