7 replies to this topic

[idreamlovey]

In my first engine which is basically intent to render outdoor environment. I am using one large Dynamic Vertex and Index Buffer to make no Vertex-Index buffer switches. I am using GridBased system. Each grid has been further divided into OCTREE. At each leaf node static Polygon Lists(Dynamic Link Lists) have been created which stores info about Vertices and Indices sepearted by material types. Now at the time of culling, i am copying the polygon lists data of each leaf into another dynamic polygon Linklist. So i traverse each grid and each octree leaf that is currently in view and copy the polygons seperated by their material type. Now Doing this i can Batch the whole triangles according to thier material type thus reducing the DrawIndexPrimitive call. All i am doing like this as in two steps:-

step 1:

1.Cull Tree
2. At leaf Node
for (int i=0;i<numMaterials;i++)
Copy LeafPolygonLists(i) to MainPolygonLists(i) (i used link list here but showing as array just to make u understand what i m doing)
(memset is used here)

step 2:

start vertexCache
for (int i=0;i<numMaterials;i++)
{
SetMaterial(i)
Copy MainPolygonLists(i) to Vertex Buffer and Index Buffer;
(memcpy is used here)
Flush the vertex cache
}

Now here u see i have to do two copies. Engine can render 20000 tris at 18 frame rate at NVIDIA 5200 fx card. But i want to increase it more and i am thinking that two copies can be avoided by only one copies....
In my engine u can see 3200 tris with light mapping, 1800 with pixel based splatting, 5500 tris with environmental texturing (vertex shader used)and soft shadow(pixel shader used), 6000 with alpha blending transperent obects some with no BackfaceCull and rest are with lights on (without specular). SkyBox with sunflare. And i think my engine is not good as i see FLATOUT and NFS Carbon demo runs at 30 frame rate with more poly and shader..

I want to know what u guys do actually in scene management. Is the above one is good approach and need additional optimization in same engine....Please tell me what should i do to make a good managed engine...If u have link to any article...It will be great to me....

[.oisyn]

Store the verts (or at least those belonging to the same material) in a single vertexbuffer so you only have copy the indices. Also, instead of a linked list of poly's, just store an array of indices (per material) at each leaf, so you can easily fill the dynamic index buffer with indices.

[idreamlovey]

.oisyn said:

Store the verts (or at least those belonging to the same material) in a single vertexbuffer so you only have copy the indices. Also, instead of a linked list of poly's, just store an array of indices (per material) at each leaf, so you can easily fill the dynamic index buffer with indices.

I have huge city with 2 lacs verts so i can't store all of them in one Vertex buffer as i created device with pure hardware not software. And In each link List there is an array of vertices and indices..Actually node is created only if the new material is found otherwise the leaf's polygon data is copied to the node of same material...

[TheNut]

Quote

just store an array of indices (per material) at each leaf, so you can easily fill the dynamic index buffer with indices

Why copy/fill anything? Your octree already divided the world up into smaller chunks, so at each leaf why not just store a list of indices and at render time you just plow through the list without any copying? You may end up rendering a couple leafs (say 10) rather than doing just one big render, but I think that's much faster than doing a copy every frame. Especially with highly detailed worlds.

[.oisyn]

idreamlovey said:

I have huge city with 2 lacs verts so i can't store all of them in one Vertex buffer

Then you use several buffers, where you group the verts based on locality.

Quote

Actually node is created only if the new material is found otherwise the leaf's polygon data is copied to the node of same material...

Oh ok, it sounded like you were storing individual polygons in a linked list.

TheNut said:

Why copy/fill anything?

Because that's faster than multiple drawprim calls, which should be kept at a minimum if you can. Copying indices doesn't cost that whole lot.

[idreamlovey]

.oisyn said:

Then you use several buffers, where you group the verts based on locality.

I have 3.4 lacs vertices and 2.2 lacs triangle faces spread over 12.8km by 12.8km divided into 50 by 50 grids. So one large static vertex buffer is not possible and my device is created with pure hardware not using Software vertex processing. Here i can do one thing is that increase the grid size and put static vertex buffer in each grids. But i want to render at least 1 km distance with three level of detail and i have to render atleast 40000-50000 triangles for good visuals and details. Since i am using splatting for ground too. Hence i can't increase my 256 by 256 grids more than 512 by 512. So i am thinking of too increase grid size to 512 by 512. Now i have to make minimum 2 vb and 30-40 ib switches and more than 7-10 vb and 120-140 ib switches in worst case(At the corner of grids viewing towards diagonal way of square terrain).
Tell me is it really good for me to make vertices static for each grid. Cause changing my system means changing whole things. Since i m working alone and it took more than a year to know all these things. It will make me not only to change my App but also to change my Max exporter, Mesh optimizer and octree converter. I have two books but they are basically for indoor not outdoor. So i want to know the possible ways to improve my existing engine...Do multithreading can be the solution...PLease give me all available options otherwise i have to drop my master degree course...Cause my program incharge are already gets annoyed of my short attendence....

[idreamlovey]

Help me out guys......i am loosing my hair...i went to the doctor and he said its not a malfunction nutrition problem but its a problem with my malfunction ideas that keeps circulating in my brain.....

[idreamlovey]

One more thing i just get an idea that i keeps loading the texture into AGP using D3DPOOL_DEFAULT and meanwhile i keeps calculating the size of texture passed to the AGB. And there is a threshold, the limit of total texture memory in AGP. Reaching that threshold i will starts loading the texture using D3DPOOL_MANAGED. Am i thinking good on it. Note that vertex and index data size is already precalculated.