Grösse von VertexBuffern
-
Hmm, aber wenn ich mich umsehe, sind doch schliesslich ganz andere Dreiecke sichtbar? Ich will ja bspw. nicht das Terrain hinter mir zeichnen?
-
Ishildur schrieb:
Hmm, aber wenn ich mich umsehe, sind doch schliesslich ganz andere Dreiecke sichtbar? Ich will ja bspw. nicht das Terrain hinter mir zeichnen?
es besteht keine pflicht alles zu nutzen was existiert, genausowenig wie alles zu loeschen was nicht genutzt wird.
deswegen kannst du dir die vertexbuffer von objekten die hinter dir sind weiterhin halten. falls der speicher knapp wird, bzw deine selbst gesetzen budget uebeerschritten werden wuerden, kannst du immer noch alte dinge freigeben.
-
Nein aber das Terrain befindet sich ja in einem VertexBuffer. Und ich kann ja nicht wahlfrei Dreiecke aus einem VertexBuffer zeichnen und andere nicht oder irre ich mich da?
-
Ishildur schrieb:
Nein aber das Terrain befindet sich ja in einem VertexBuffer. Und ich kann ja nicht wahlfrei Dreiecke aus einem VertexBuffer zeichnen und andere nicht oder irre ich mich da?
deswegen hast du auch mehrere
-
Irgendwie reden wir aneinander vorbei
Stell dir vor du hast ein absolut flaches Terrain (eine Plane mit 2048x2048 Vertizen). Du stehst in der Mitte dieser Plane und drehst die Kamera langsam im Urzeigersinn bis du einmal rundum bist. Nun macht man in einer solchen Situation doch ein Occlusion Culling mit Hilfe eines QuadTrees, sprich VertexBuffer Locken, diejenigen Vertizen reinschreiben, welche den Occlusion Culling Test bestanden haben, VertexBuffer unlocken, rendern. Wieso genau brauche ich da mehrere VertexBuffers?
-
Ishildur schrieb:
Irgendwie reden wir aneinander vorbei
ich glaube du hoerst eher an uns beiden vorbei, denn wir sagen dir beide das selbe.
Stell dir vor du hast ein absolut flaches Terrain (eine Plane mit 2048x2048 Vertizen).
also organisiert in 64 vertexbuffern zu je 256x256, ok.
Du stehst in der Mitte dieser Plane und drehst die Kamera langsam im Urzeigersinn bis du einmal rundum bist. Nun macht man in einer solchen Situation doch ein Occlusion Culling mit Hilfe eines QuadTrees, sprich VertexBuffer Locken, diejenigen Vertizen reinschreiben, welche den Occlusion Culling Test bestanden haben, VertexBuffer unlocken, rendern. Wieso genau brauche ich da mehrere VertexBuffers?
denkst du nicht dass es viel laenger dauert jeden vertex auf occlusion zu testen als ihn einfach zu zeichnen? waere es nicht schlauer gruppen von verticen zu testen, z.b. gleich 256x256 davon am stueck anhand deren bounding box?
-
denkst du nicht dass es viel laenger dauert jeden vertex auf occlusion zu testen als ihn einfach zu zeichnen?
Ich teste ja nicht jeden Vertex auf Occlusion, wenn ich einen QuadTree verwende. Aber ich kann dir diese Frage nicht beantworten, ich habs nicht ausprobiert
Ich lese gerade ein Buch über Terrainrendering und dort machte er es so, wie ich eben beschrieben habe aber das muss natürlich auch nicht die einzige / beste Lösung sein Ich kann dir allerdings eine Gegenfrage stellen: Wieso benutzen dann viele Outdoor Engines einen Quad- resp. Octree fürs Terrainrendering?
Und spätestens fürs Collision Detecting benötige ich die Vertexdaten (zumindest die Positionen, manchmal noch die Normalen) und die will ich ja auch nicht in jedem Frame im VertexBuffer nachschauen gehen?
-
Ishildur schrieb:
denkst du nicht dass es viel laenger dauert jeden vertex auf occlusion zu testen als ihn einfach zu zeichnen?
Ich teste ja nicht jeden Vertex auf Occlusion, wenn ich einen QuadTree verwende. Aber ich kann dir diese Frage nicht beantworten, ich habs nicht ausprobiert
Ich lese gerade ein Buch über Terrainrendering und dort machte er es so, wie ich eben beschrieben habe aber das muss natürlich auch nicht die einzige / beste Lösung sein gibt sehr sehr viele paper dazu. Oft kommt es nicht auf die theorie an, sondern auf die implementierung. was bei einer ein "no no" ist, ist bei der anderen dann wieder absicht.
Ich kann dir allerdings eine Gegenfrage stellen: Wieso benutzen dann viele Outdoor Engines einen Quad- resp. Octree fürs Terrainrendering?
weil es die perfekte art ist die 8x8 vertexbuffer (je 256x256) zu organisieren, oder nicht?
Und spätestens fürs Collision Detecting benötige ich die Vertexdaten (zumindest die Positionen, manchmal noch die Normalen) und die will ich ja auch nicht in jedem Frame im VertexBuffer nachschauen gehen?
Ich sehe nicht was das mit einem VB vs viele kleinere VB zu tun hat, ausser dass ein grosser VB vermutlich um einiges langsammer waere beim rauslesen von daten.
aber nein, das willst du nicht, du willst die nur die heightmap aus der du das terrain gemacht hast. wozu komplexe collision detecion wenn du simpel ueber das indizieren in der heightmap das delta von jedem vertex vs terrain errechnen kannst? das ist O(1). was will man mehr?Aber da bist du wieder dort wo du beim scenegraphen bist. du versuchst in ein objekt alles reinzulegen was du kannst. dabei ist trennen so simpel und effektiv.
um es umzudrehen, wenn du nicht wuestest dass es texturen gibt, wuerdest du sagen dass du das mesch super hoch unterteilen musst damit man genug vertices hat um pro cm einen farbwert zu haben.
aber die daten sind unterteilt, geometrie und tapestry.
so darf das auch fuer fuer collision vs rendering sein.natuerlich sind die dinge nicht voll entkoppelt und es ist gut daten nicht doppelt abzulegen. aber vertexbuffer sind nunmal auf der graka, heightmaps im system memory.
-
Du gehts davon aus, dass das Terrain mit einer HeightMap generiert wurde, was ich immer sehr schade finde (Keine Überhänge, keine Höhlen...)
Kennst du die Gothic Serie (Risen)? Ich liebe diese Serie, eben weil si IMHO KEINE Heightmaps fürs Terrain benutzt! (Tiefe Schluchten, überhängende Felsen, Höhlen usw...)
-
Diese Liste habe im Direct3D9 Programming Tips der SDK Doku gefunden:
Da steht man solle lieber wenige grosse anstatt viele kleine Vertexbuffer benutzen.Clear only when you must.
Minimize state changes and group the remaining state changes.
Use smaller textures, if you can do so.
Draw objects in your scene from front to back.
Use triangle strips instead of lists and fans. For optimal vertex cache performance, arrange strips to reuse triangle vertices sooner, rather than later.
Gracefully degrade special effects that require a disproportionate share of system resources.
Constantly test your application's performance.
Minimize vertex buffer switches.
Use static vertex buffers where possible.
### Use one large static vertex buffer per FVF for static objects, rather than one per object.
If your application needs random access into the vertex buffer in AGP memory, choose a vertex format size that is a multiple of 32 bytes. Otherwise, select the smallest appropriate format.
Draw using indexed primitives. This can allow for more efficient vertex caching within hardware.
If the depth buffer format contains a stencil channel, always clear the depth and stencil channels at the same time.
Combine the shader instruction and the data output where possible. For example: