TerrainPage LOD - bad tri-mesh

Couldn’t find a similar post in the archives…

Machine spec GPU - GeForce FX5700, [latest]

Creating a TerrainPage with LOD set True I get bad tri-meshes being rendered. With LOD turned off everything’s fine. Screenshot attached:

The image shows a terrain-block to the right that’s rendered correctly, but the terrain block to the left has torn and the water quad beneath is showing through. It appears to be within the LOD mesh code as the fog is correctly being applied in the distance on both Terrainblocks.

Kinda low-priority as it actuallys runs faster with LOD turned off, but curious to know if anyone else has come across this and what the problem is.

probably either an issue with indices pointing to invalid vertices or only a subset of vertices and the card doesn’t know what to do with the rest of the verts.

Does the jmetest.renderer.TestClodMesh work properly for you? (make sure you update from cvs today as I just fixed a bug where it was adding a model twice…) Use the number pad’s + and - keys to change LOD and use ‘m’ to switch between the liberty model and a simple disc. Using 't’t to view wireframe mode can be helpful as well.

I just did another checkout and the LOD test works fine, but I still get the tearing if I turn LOD on for terrain pages.

Yep, I see it too. I’ll look into it.

Renanse, this looks similar to the issue we had awhile ago on one of my machines with VBO and CLODMesh. I believe it was on a machine with Nvidia graphics and I thought it was fixed. Unfortunately, I don’t remember the specifics.

Kinda low-priority as it actuallys runs faster with LOD turned off, but curious to know if anyone else has come across this and what the problem is.

Yes, I came across this very same issue some months back. Didn't bother trying to isolate the problem or anything though...

I do see a small bug in TerrainPage that prevents the blocks from chopping small enough, but that isn’t the problem. It appears that the problem does has to do with VBO support… turning it off corrects the problem. Off the top of my head, I’m guessing this is related to semi-recent changes to number-of-triangle / number-of-vertices calculations, (it used to work fine on my machine/card) but I’ll have to look deeper to know for sure.

Ok, found the issue. Terrain blocks (would happen with other vbo/clods too) that are far enough away from the camera when first drawn that they are less than full LOD were having their VBOs generated with less than full data. I’ve added buffer updates to VBO creation to ensure the VBOs have full data and the tests all seem to run fine now.

PS: CLOD+VBO on the TestTerrainPage demo gives me a small boost over just VBO, however ymmv.

CLOD is now working for me too, but I’m getting LOWER fps when having it turned on :?

CLOD is very CPU intensive, so if you have a modern card making use of VBO and a slower CPU, no CLOD will most likely be faster. CLOD helps in situations with a slow non-VBO using card, or a very fast CPU.

Aha… that explains it then :slight_smile:

Discreet level of detail would be better for slower computers, or maybe a CLOD with a really high threshold rate?

Yeah, CLOD when used with terrain also has a lot to do with how big (vertex-wise) you make the blocks. Also, how far in the distance you can see terrain will effect whether CLOD or VBO is more useful… I have a feeling some of the optimizations we are planning for .9 will end up speeding CLOD as well.