Quote:Original post by Trienco

Quote:Original post by SiS-Shadowman
i meant that i update the IB for one patch, IF it has to change it's LOD, because it's too far / near from the camera.

I`m not sure if I get you right. So, if you have, say, some 32 patches (chunks) on-screen, and about 20 of them require different LOD, you`re updating those 20 IBs each frame ? Or only once when the LOD is being changed ?

i'm only updating them, when they need to change ;)
i know it would be a waste of time to update them every frame. but i'll write a different terrain class, wich pre calculates the IB's for the different LODs and then just use the propriate: i haven't decided what i want to use.

Quote:Original post by Trienco

Quote:Original post by SiS-Shadowman
i'm not shure how big my terrain needs to be. i think i'm satisfied when it can read out a 256 or even 512 sized heighmap and draw it speedy ;)

You don`t mean 256x256 for whole heightmap, do you ? Probably 256x256 just for one chunk of the terrain, right ? Such a small heightmap would be too blocky for regular use. Even 1024x1024 can be too small (depending on total area that you want it to cover).

well, actually i meant this, but i haven't spend much time thinking of it. i'm not shure how big my actual game can be ( i'm just one person ;) )
apart from that, am i able to use such big heightmaps with a 16bit indexed buffer?
if i'm getting it right, 16 bit integers are just able to display values up to 32.767, and so i could just use up to 32.767 vertices for one IB ( and propably patch/chunk ( 181*181 )
or am i misunderstanding something?

Quote:Original post by SiS-Shadowman
i'm only updating them, when they need to change ;)
i know it would be a waste of time to update them every frame. but i'll write a different terrain class, wich pre calculates the IB's for the different LODs and then just use the propriate: i haven't decided what i want to use.

That`s good. I just wonder, wouldn`t it be easier to write precalculated LODs than updating each during runtime ? But since you`ll write it anyway, you`ll be at least able to measure the performance differences.

Quote:Original post by SiS-Shadowman
well, actually i meant this, but i haven't spend much time thinking of it. i'm not shure how big my actual game can be ( i'm just one person ;) )

This has nothing to do with how "big" the level is going to be. It all just depends on your scale. If you scale it 10 times the distance between clipping planes, it`s gonna be quite huge. But it`ll be very sharp and low-detail. So it depends just on you.

Quote:Original post by SiS-Shadowman
apart from that, am i able to use such big heightmaps with a 16bit indexed buffer?
if i'm getting it right, 16 bit integers are just able to display values up to 32.767, and so i could just use up to 32.767 vertices for one IB ( and propably patch/chunk ( 181*181 )
or am i misunderstanding something?

You can index 65536 vertices with 16-bit IB. So, if you want to use larger terrain, you should either switch to 32-bit Indices (double the memory usage for IBs) or stick with 16-bit Indices and switch between several VBs (each containing max 65k vertices). Of course, using 32-bit Indices is easier, since you don`t have to change anything except few flags and IB creation details. So, if memory isn`t an issue, just go for 32-bit Indices.

i don't agree with you at the second point.
the level also needs to be filled with everything ( buildings, trees, plants, rocks and all the other stuff ) and i don't want to spent months in building the whole level, thats why i don't need a huge terrain. i know i can scale it. but 512x512 should be sufficent enough for my needs

I see. What type of game is the terrain for ? Do you have character animation and AI already done ?

unfortunately not.
this is my first direct x project. i'm learnign everything from scratch.
i've written my own kernel, debugging system along with some useful functions classes etc... with the help of gamedev and some books ;)

i started with a simple model loader and advanced to a basic terrain demo, just to learn it. i've only done a skydome, starbox, sun / moon, so far, the rest still needs to be done ^^
i haven't spend much time on other subjects than graphics, because this is the most important part of my engine and i think at this speed i still have time till the end of this year, to begin to work with KI routines, mesh animation etc...

the terrain is for some sort of tactic shooter / rpg. i always wanted to do something like that :)
perhaps something post-apocalyptic for the first scenario ;)

I`ve been there too long ago. My estimate is that you`ve currently got about 5%-10% done of whole work, though you seem to be aware of it. And terrain renderer is probably one of the easiest (and most "cool") parts. How many hrs per week do you devote to it on average ?

hm, i programmed the last 2 weeks about 5-7 hours per day, but that was because i didn't have school then :p

but now it's started again and i'm just too lazy to work much on my prog. i'm tired of the stupid terrain, i would really like to advance to something else, but i need to finish it, hopefully this weekend will give me the strength .p

perhaps next thing will be water rendering ( after the texturing of my terrain is done *g )
and yep, i know i'm only at the beginning of my game / engine, but i'll just take it as an exercise for my later job ( if i will finally graduate from school and get a job )

Quote:Original post by SiS-Shadowman
i meant that i update the IB for one patch, IF it has to change it's LOD, because it's too far / near from the camera.

It still sounds like you have a seperate IB for EACH patch and due to not realizing that ALL patches can use the same indices would be plain screwed with a large terrain. Even if you simply place vertices line by line you will never need a single index that's larger than patch_height*terrain_width. There is a good reason why the draw call lets you specify an offset.

Or at least try to collect the indices in one big index buffer to avoid having a gazillion draw calls.

Quote:i'm not shure how big my terrain needs to be. i think i'm satisfied when it can read out a 256 or even 512 sized heighmap and draw it speedy ;)

If you think about a 256x256 or 512x512 terrain, then stop wasting time with lod schemes. Applying lod to such a small terrain is beyond pointless unless you just do it for practice. Rough numbers freshly pulled out of various body orifices and assuming a decent view distance:
<=512: draw brute force or use patches for culling only
512-4096: geomipmapping
>4096: geoclipmapping (still kind of overkill)

Quote:Original post by VladR
Well, it seems that you got confused by number 16, which in my case was number of separate VBs (max.terrain chunk size that can be indexed with 16-bit IB). In your case, it`s the number of different LODs per chunk.

Nope. 16 is the number of different IBs for ONE lod, because the pieces that may be required to connect to lower lods need to be left out for all combinations of neighbours. Essentially because I don't find it too elegant to keep the edge of each and every patch at the same lod or use skirts. With that whole drawmultiwhatever-thingy it doesn't even hurt too much.