#### Archived

This topic is now archived and is closed to further replies.

# Fixing floating point error sized cracks

This topic is 5451 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I am looking for a way to fix a small problem I have in my terrain. It is broken up into quads and each quad is rendered at a LOD that best suits its detail inside of the quad. Because of this I can have patches next to eachother of varying levels of detal from 1-3 detail level differences although it usualy doesnt get any worse than two. Now where the patches meet I go through and adjust the vertexs and normals of the higher detailed patch to match that of the lower detailed patch so that there are no visible cracks, however I have to make a computation to interpolate between the two heights on the lower LOD and I fear that the floating point error is casuing my small problem. If you look here, http://www.ameinc.com/~dclyde/TheDots2.jpg when my terrain is using a grassy texture its nearly cannot be noticed. However, when I am using a snow texture http://www.ameinc.com/~dclyde/TheDots.jpg the cracks which show as dots are much more noticeable. When moving it looks like a very low level of static moving around that is just enough to be noticeable and slightly annoying. Im looking for a way to fix this, Im not looking to increase the amount of geometry at all so skirts are kind of out of the question especially since they would be extreme in this case. I was also thinking of drawing aa giant quad under the terrain but this too seems a little extreme.. although I really dont see another option... ideas? Would the giant quad under the terrain affect performance much? I think fill rate can hit heavily sometimes so... // Full Sail Student with a passion for games // This post in no way indicates my being awake when writing it [edited by - dclyde on August 18, 2003 3:33:28 AM]

##### Share on other sites
If you''re just moving your higher LOD vertices up/down to match the lower LOD, you will get T-junctions, which I think is what your curent problem is. A T-junction occures when an edge hits another edge at anywhere other than its ends. You must always avoid T-junctions!

There are two ways around T-junctions when doing terrain LOD:
1. By increasing the amount of geometry - by either using skirts or re-tesselating the lower LOD.
2. By decreaseing the amount of geometry - usually by re-tesselating the higher LOD.

Use the forums search function, and look for "crack". There are many threads around on this (even one or two recent ones). As for your giant quad suggestion: if you draw it after the terrain using depth-testing, fill rate will not be affected very much (it would still be affected though). I''m not sure if this is a very good idea, though. For example, you might get z-fighting at the distance... But I think you should try it and see what happens.

Michael K.,
Co-designer and Graphics Programmer of "The Keepers"

We come in peace... surrender or die!

##### Share on other sites
I do have T-Junctions but I never change the LOD of the terrain.

To prevent cracks what I do is I figure out the height T should be by interpolating between A and B and using that height for T in the higher tesselated patch. But due to what I think is floating point error there are still some really really tiny cracks the size of pixels really, but enough of them gets annoying on the snow texture.
 ________A_________|       /|   /|   /||      / |  / |  / ||     /  | /  | /  ||    /   T/___|/___||   /    |   /|   /||  /     |  / |  / || /      | /  | /  ||/_______B/___|/___|

.... and as I type this out I think of what might be the cheapest and best answer.. since the cracks are only really noticeable where I have white textures surrrounding the black dots I can just change the fill color (currently black) to something more suiting for the terrains overall color... hmm

// Full Sail Student with a passion for games
// This post in no way indicates my being awake when writing it

[edited by - dclyde on August 18, 2003 4:49:01 AM]

##### Share on other sites
an even easier method would be to have no cracks. using the same vertices for both edges will do that. in your example its even quite simple.

 ________A_________|       /|\   |   /||      / | \  |  / ||     /  |  \ | /  ||    /  (T)  \|/___||   /    |   /|   /||  /     |  / |  / || /      | /  | /  ||/_______B/___|/___|

if you dont plan to change the lod later on anyway its not even as much work as it could be ,-)

##### Share on other sites
Hmm, my whole system wouldnt agree with that much, Id actually have to change quite a bit.

Currently I generate one index buffer for each LOD and use the respective IB for each terrain patch depending on its LOD. If I started doing that each patch would need its own IB.

This helps keep the same IB on the card for faster execution especially since its static and so are all the VBs because of the style of the game a lot of the same VBs stay in view between frames as well. Well, at least in one of the views heh, the other view I need to do some research on precalced occlusion culling I think.

In addition when the VB is made for each patch they are not aware of the LOD of the patch to each side yet, I would have to rearrange how I do everything, hmm.

Which brings up another question....
With my method of having one IB per LOD and then one VB per patch, I set the VB then tell it which IB to use, this method was setup when I was changing the LOD and the VB wasnt customized to the LOD, now it is so would it just be faster to go without the IB all together? Considering I never change any of the IB's or VB's that is.

[edited by - dclyde on August 18, 2003 6:54:57 AM]

##### Share on other sites
if you are dead-set ultra-against fixing the problem (i.e. removing the t-junctions properly) you could just shift the vertex at the center of the T into the polygons of the adjacent patch very slightly. This is an inelegant hack, but would probably work and with no additional geometry load, especially if you''re not constantly retesselating your terrain. however it is so inelegant that i grimace even for suggesting it.

james

##### Share on other sites
quote:
Original post by dclyde
Hmm, my whole system wouldnt agree with that much, Id actually have to change quite a bit.

if i got you right and youre setting your lod once and never change it later on anyway there would be quite a few changes id make ,)

quote:

Currently I generate one index buffer for each LOD and use the respective IB for each terrain patch depending on its LOD. If I started doing that each patch would need its own IB.

nope, but youd need a bunch of ib''s for each lod.

quote:

In addition when the VB is made for each patch they are not aware of the LOD of the patch to each side yet, I would have to rearrange how I do everything, hmm.

thats the painful thing about terrain lod if youre using this method. if this t-junction problem could be easily solved there wouldnt be articles about it in the gpg books ,-)

quote:

now it is so would it just be faster to go without the IB all together? Considering I never change any of the IB''s or VB''s that is.

i thought about suggesting that but think about it: for a triangle list you would need to have every single vertex about 4 times (for every triangle using it). the card couldnt tell its the same vertex it just did and as far as i can tell it would render the whole vertex cache useless. so you would need more memory and get slower performance.

though right now it sounds like you always store the high detail vertex buffer, even if youre never going to use most of them. thats also not just wasting memory but slowing you down, because you have to wildy jump around in your vb.

maybe it wouldnt be that bad to let every patch have its own ib. as a trade off you remove all unneeded vertices from the vb which should more than make up for the extra ib.

##### Share on other sites
quote:
nope, but youd need a bunch of ib's for each lod.

Sorry my statement was specific to my terrain, I only have 256 vertex buffers and with that method I would need 243 IBs which would just about be the 256 for one for each patch. Of course if I end up going withthe bigger patch size this all changes and I only have 64 patches but Im wiaitng for when everything is in the game to further tweak the map stuff. I probably should have stated that before.

quote:
though right now it sounds like you always store the high detail vertex buffer, even if youre never going to use most of them. thats also not just wasting memory but slowing you down, because you have to wildy jump around in your vb.

Actually I had it storing the full high res when I was adjusting the LOD before, but now that I do not adjust it I cut out all of that stuff. Right now the VBs only contain one of each vertex necessary to represent the LOD the patch is.

And for my IB elimination question I never thought about the fact it wouldnt be able to fixgure out wether or not to keep a vertex in the cache or not, and for some reason I was just being completely forgetful that I would need to send each vertex ~twice for a triangle strip as apposed to the once I have now. Wow thats bad forgetfulness =)

quote:
if i got you right and youre setting your lod once and never change it later on anyway there would be quite a few changes id make ,)

Well the thing is, the terrain is small (257*257) and the view is usualy 40 degrees down at a height of 50(assuming a scale of 1.0) so a lot of the geometry is eliminated by the view frustum.

Then a lot of stuff doesnt have a lot of detail except for the areas with rivers so there were bigger jumps between different LODs and to be quite honest I was having a problem with preventing popping fast enough. Cracking never seemed a problem. My method seemed to just take too long. Im still relatively new to all of this (only been working in d3d for two months) so the time I was taking to update the vertex buffers to their new height, and check if they were at their target heights, and computer new target heights,etc etc was just too much. I started coming up with differenct schemes that required considerably more memory (storing one HeightMap for each LOD and storing a CurrentHeightMap for all my height checks) but in the end this didnt seem elegant enough and still not fast enough.

quote:
thats the painful thing about terrain lod if youre using this method. if this t-junction problem could be easily solved there wouldnt be articles about it in the gpg books ,-)

Heh Ive gone through them all and tried a bunch of the methods present in all three of them. Getting an implementation of each method wasnt as difficult as I thought but getting one that was fast was more challenging. I have since bought Greg Snook's new book about terrain engines and I have learned a lot but I have not been able to fully implement the ideas he present in a real-time enough speed. Although I learned a lot of d3d from it, and when my project is done (well according to the school anywho) I will need to go back and implement more, unfortunately I dont have the time now as Im working on game play and the project is to be done in a week and a day heh =)

// Full Sail Student with a passion for games
// This post in no way indicates my being awake when writing it

[edited by - dclyde on August 19, 2003 8:32:36 AM]

1. 1
2. 2
3. 3
Rutin
22
4. 4
JoeJ
16
5. 5

• 14
• 30
• 13
• 11
• 11
• ### Forum Statistics

• Total Topics
631774
• Total Posts
3002294
×