I got it working! Your right, I was making some stupid mistakes that are now obvious.
First of all, when you reposted my distance formula, I noticed that I was only adding the z1 and not multiplying it! I didn''t see that at all before...
quote:
I can''t see any reason for that line. In the paper ''dist'' is calacualted as you have in the first line. So try ditching that second line.
I took the distance subtraction out (that second line) and it worked as well but I think it''s a little more accurate with it. What I was trying to do was do a kind of spherical distance check, imagining the chunk to be bounded by a sphere, not a box. I calculated the distance from the center, and then that value was the radius (half of the width of the box) and I subracted it. That''s just another calculation though, and I don''t think it makes that much of a difference if I change around my screen space error tolerance to the right measure.
quote:
Looking at it, the second line appears more like the calculation for the LOD geo-error per level. That is if the chunk has a master error metric of say 16 units, then higher levels of LOD should have half the error value - so level 1 = 16 level 2 = 8 etc. I would have thought these values would have been precalaculated and stored with each level of LOD for the chunk
quote:
how do you calcualte each chunks maximum geometric error?
You are right!!
You pointed out one of the biggest errors. I interpreted the paper wrong, and I thought I had to store the maximum geometric error of each chunk, but I can easily get it with just pow(2, 4-level). Even better, store it in a lookup table. Why would this make a difference? I should have even more accuracy about each chunk if I stored its own maximum geometric error. But there was a problem in the way that I got that. I got it when I did the vertex-LOD calculation of each level, I simply checked the current error against the current max, and if it was bigger, set the max to the current. My problem was that when it was at the first level (2 triangles for the whole terrain, least LOD) it would set the maximum geo error very high and then recurse lower and it would still be high. This was a HUGE error and is why it kept recursing down to the most polys- it kept thinking each chunk had a HUGE geo error. Thank you so much noisecrime, you really hit it on the head and made me rethink this part.
quote:
So this means your FOV is 120 degrees - which to me is rather large, but there may be a good reason for it. Anyway it shouldn''t be the cause of your problems.
I think you are mistaken though on my Horizontal FOV.. It would be D3DX_PI/3 which would only be 60 degrees (180/3), not 120, correct?
quote:
I had almost asumed that perhaps you''d use the bounding box for a chunk comparing it against each LOD level. You''d be comparing the highest hieght of each LOD level to the maximum LOD (most polys) and using the difference as the error metric. But i''m not sure tat makes much sense.
I see what you are saying. That would work, but I think it''s more work than it takes. I said before how I did it in the first place (although it had a bug, it could be fixed to work correctly). But I don''t think you get much inaccuracy if you just go ahead and set the maximum error to pow(2, max_level-level); It''s easy, simply, could be put into a lookup table and you don''t have to worry about each chunk as long as you have the level of detail of the chunk.
quote:
Further more i''m confused by the paper as he say''s
''For simplicity''s sake, I assign the same E to all the meshes at a particular level in the chunk tree.''
where E = Maximum geometric error
This seams counter productive to me, as each child chunk could well have an error greater or less than an other.
It''s just what I was talking about in the last paragraph- it''s easy and accurate it go ahead and set every chunk in level N to have the maximum error of pow(2, max_level-level). If it recurses to the child chunk, the level would go higher and have a less max error. Don''t think of it as a tree this time and just think of the 5 (or whatever) different levels as separate, subdividing by pow(2, level) and each chunk having a max error of pow(2, max_level-level).
quote:
Furthermore his equaition for calculating the error for specific LOD levels, is simply to divide the parent level by two, which again I would have assumed to be inaccruate.
I hope you are thinking of the vertex-LOD calculation and LOD-level subdividing as two different steps. We calculate the LOD of the terrain witha max of, say, 16 and space out the vertex as needed according to whatever algorithm. Then we store this in chunks, and subdivide pow(2, level) times. Do the same think with a max of 8, vertices would be calculated, and then the terrain would be evenly divided to one more extent than last time. The max error is calculated by pow(2, max_level-level) as I have said many times.
So you can see that each level WILL have a max error of it''s parent/2. It''s quite accurate, I''m finding that in the first step (vertex-LOD calculation) it rarely (if ever) calculates down to the highest vertices possible, meaning that the max_error is almost always reached in each chunk.
I think that I am getting it
.
