Original Post
Hey, for some time now I've been heading for a solution to my VertexBuffer Problem. Right now, I'm trying to program an engine, which is graphics-api independent, nevertheless I focus on DirectX for now. My problem is as follows: How to use Vertexbuffers efficiently when Rendering a dynamic View-Dependent scene? The first approach would be to create a RenderQueue, which enqueues all Vertices/Indices with priority to their texture (texture sorting for less state changes). Then, the renderQueue flushes all its content to one big vertex-/indexbuffer, which is dynamic, of course. Since dynamic Vertexbuffers are less efficient than static ones, the question is wether this approach can result in good performance. (The same problem I once had with my roam-based terrain algorithm, which in fact lead to framerates on my laptop of only 40-80) The second approach would be to create static Vertex/Indexbuffers for all objects in the scene. Those objects are then enqueued to the renderqueue, which then traverses for rendering. This approach is impractical because of e.g. instancing. What if I want to draw some thousands of grass billboards? I would then need to set the worldmatrix too often (since coordinates are not pretransformed as in approach one) to reach a performant result. The third approach I thought of was to create static Vertex/Indexbuffers for all sections in the scene. This would require a quad/octree or such, but I want my renderer to work independent from those algorithms, since they do not belong to it. Also, this approach would mean to generate my geometry once and leave it static, so the player cannot change anything. Does anyone know which of these (or others, of course) approaches are most practical and effient? Thanks in advance, Mattes337
