I thought a quadtree would be something i definetly need since going to allow for frustum checking and occlusion surely this would be needed even in an editor?
Maybe im confused about quadtree but i thought it would be the quadtree that i would actually check against for culling?

Thanks for the Texture links will certainly have a look :)

I would still recommend implementing quadtrees in your editor because it's a very easy way to optimize frustum culling. If will definitely reduce the CPU usage when your terrain grows larger or you reduce the size of your chunks. As I understand DirectX its very beneficial to reduce the number of drawPrimitive calls and frustum culling helps you achieve exactly that.

One thing I don't understand is that you talked about storing your index buffer with WORDS (32 bit) What you probably want to do is to use SHORTS (16 bit) for indices. Another thing that is strange is your low performance when rendering only around 130.000 triangles. With the hardware you describe you should be getting closer to ten times as many frames per second (around 500 fps).

kind regards,
Nicolai

Quote:Original post by ndhb
I would still recommend implementing quadtrees in your editor because it's a very easy way to optimize frustum culling. If will definitely reduce the CPU usage when your terrain grows larger or you reduce the size of your chunks. As I understand DirectX its very beneficial to reduce the number of drawPrimitive calls and frustum culling helps you achieve exactly that.

One thing I don't understand is that you talked about storing your index buffer with WORDS (32 bit) What you probably want to do is to use SHORTS (16 bit) for indices. Another thing that is strange is your low performance when rendering only around 130.000 triangles. With the hardware you describe you should be getting closer to ten times as many frames per second (around 500 fps).

kind regards,
Nicolai de Haan Brøgger

I dont exactly know what happened but running my app on my computer today im getting about 300 fps which is definetly and increase maybe its a bug in my system maybe not, but i guess i cant really tell unless it re produces itself.

A little strange i think.

I've been wondering about storing my terrain in VB's and IB as the terrain by should have the ability to be Large or Small, with LOD per each chunk it should make sense to have each chunk stored in its own VB rather than one large VB since the VB will have to be dynamic since i am changing the data to be rendered. Is that right or am i on the wrong track completely is the one VB approach a better fit.

Actually i've been thinking about what i just wrote and realised the VB will stay the same the index buffer should be the thing that changes and if these changes are calculated at load time, it should just be a simple matter of a memcpy to the indices for changing the LOD at run time?

Yes you i guess i should not be using WORD but since i experimented with 32 bit indices i forgot to change back to 16 bit indices. I need to change it back now from int as i was experimenting further >.>

Quote:Original post by LordFallout
I've been wondering about storing my terrain in VB's and IB as the terrain by should have the ability to be Large or Small, with LOD per each chunk it should make sense to have each chunk stored in its own VB rather than one large VB since the VB will have to be dynamic since i am changing the data to be rendered. Is that right or am i on the wrong track completely is the one VB approach a better fit.

yep, you need to do this in editor, when you need to change your terrain. in game, however you probably won`t change terrain, so you can have it in one VB.

Quote:Original post by LordFallout
Actually i've been thinking about what i just wrote and realised the VB will stay the same the index buffer should be the thing that changes and if these changes are calculated at load time, it should just be a simple matter of a memcpy to the indices for changing the LOD at run time?

you are right again.



for that quadtree thing. I believe that having grid instead is enough(in the editor). in case you have decided to have a quadtree in the editor, you would need to store data in leaves, and that means only difference from grid would be faster frustum culling(less frustum-AABB checks, in case of 30x30 terrain maybe 30 instead of 900). but quadtree is more difficult to implement(grid is just an array and you loop through it), and I guess frustum culling is not going to be a bottleneck anytime soon. personally I have implementing quadtree to editor on the very end of my to do list. I have more pressing matters to do. like grass. I have found a paper about amazingly looking real time grass few weeks ago. mmmm.

Thanks for the reply it helped me to clear things up a little in my head. OK now i have the theory down i just need to figure out a way to calculate the indices from previous indices, i will tomorrow my heads a bit funky atm :)

Any chance you could post me a link to the paper you where talking about :P

OK, i got the geomipmapping working i feel great :P now i just need a distance management system with a quadtree and i can sort out the edges :)

Anyhoo it could just be me but when looking at my terrain in wireframe with less vertices the terrain seems a little smaller, like its shrunk even though its using the same vertices for all corners? Is this a common thing to see, apparant shrinkage?

congratz [smile]

i hope i will do geomipmapping during this week too. i have really no idea why it should shring though [looksaround].

just one last thought, do you think i could take a look at your editor? you could take a look at mine. maybe some parts of your editor are better than mine and vice versa. i can kick on ftp server if needed.