# Verts jumping randomly.

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

## Recommended Posts

I am writing a planet LOD system, which uses as close to real world scale as I can get, which means the smallest polygons in the LOD patch are about 1-20m across with a planet the radius of the earth. When I am at the highest LOD level, if I slowly move the camera around the scene, all the verticies jump about, like they have a random noise element added to them. The jump isn't too huge, not so polygons start intersecting, but it certainly is noticeable. I think the camera position is jumping around in the same manner. I would guess that this is rounding errors due to the difference in scale, and the accuracy required to represent it. Am I right, and if so, what are the methods for getting around it? I am using the world spheres surface as a basis for the LOD, mapping a grid onto it, so the LOD verticies have to be at the radius of the sphere, or I would need to recalculate them all at every camera move (not going to happen). Thanks!

##### Share on other sites
Well, you could use a double since you're pushing the limits of a float. That would most likely be the easiest change. I think overall you really need to change coordinate systems. Basically your lowest lod is in sections with each section having it's own coordinate system. Basically picture everything having coordinates with a cube 2 units on a side centered at the origin. Crossing boundaries or changing lod levels one of those is the local one and everything else relevant is translated into that. You don't do all the vertices since at six feet above the surface the maximum distance you could see the surface is one mile. Realistically though at a mile you couldn't see a 1m feature. So the furthest patchs need only be at the lod you would have at a mile above the surface.

##### Share on other sites
Thanks for reply. There is no way to up the precision that the graphics card uses is there? I am using shaders but the highest precision is float in GLSL.
I guess what is happening is that every time I move the camera, its matrix (which I am multiplying directly into OpenGL with glMultMatrixf, would that make any difference?) is altering very slightly causing the inaccuracy, in the card, in the already high error fixed mesh points.
My LOD consists of a large grid, with progressivly smaller grids centered on it. Each grid is 1/2 the width of its parent. When the view point moves in a particular direction, columns and/or rows are added to one side of the grid, and removed from the other. Each child grid has its own offset from the base grid, because for a move over a certain distance many more columns/rows need to be added for the high res patches than for the low ones, so they cannot always be centered. I am currently trying to get an 11 level LOD with 64x64 grid of tris to work fast.
How would what you suggest work in this scheme?

##### Share on other sites
I assume when you say half the width you mean a quarter of the size, i.e. half both the width and height. Rather than one grid at each level you have one at the lowest level of detail. Below that you have four grids instead of one, i.e. top-left, top-right, bottom-left, bottom-right. That forms basically a quad tree.

Basically each level uses a differant scale. So maybe one level is at 100m on a side for a grid square. The next lower level has 10m on a side. The actual coordinates are in the units of the scale. So a vertex at (1,0) in one is 100m from the origin while in the other is 10m from the origin. Further the subgrids have their own origin. So going from parent to child requires a scaling common to all the child grids and a translation specific the particular child.

So say you have a level where a grid square is 100m on a side with the overall grid being 100km on a side. Say it's coordinates range from (-500,-500) to (500,500). It has four children each of whose grid squares are 50m on a side and the entire grid 50km on a side. Each of their coordinates also range from (-500,-500) to (500,500). If you take coordinate (100,100) on the parent that translates to (-300,-300) on the top right child.

When rendering you translate everything relative to one grids origin. You don't get carried away with that and say I'll always do relative to the top most grid. That's what I assume you are doing now. Rather you select a coordinate system that pretty well keeps everything visible in a cube a thousand on a side. The problem when you get coordinates up in the millions with a float is that you only have like 4 or 16 divisions between integers. So if you're drawing an object within a 1x1x1 cube with only 4 subdivisions then you only have 4x4x4=64 distinct positiosn for vertices within that cube. Those points could easily be 10, 20, 100 pixels apart on the screen. With coordinates down around 1000 though you have a million distinct points for those vertices.

You can't just scale it down though. Once the coordinates are up in the million range you already lost that precision. You can reduce a sphere with a radius of a million kilometers down to a one of radius of a millimeter without any problem, but you can't describe the vertices of a sphere with a radius of a millimeter in units of kilometers. There is a differance between scaling the object down and describing a small object.

##### Share on other sites
How does such a system handle movement and decisions about what LOD to split to?
For instance when one is at the center of the base grid then I can imagine how it would work, but if one moves the width of the grid to the left say, how are parts added and removed from the grid? Also how is stitching performed between the different grids?
Can you point me to any examples so I can try and understand it better?

##### Share on other sites
You would basically transform the coordinate spaces to the coordinate space of the viewer. With the example of a thousand on a side the center of the next grid is only getting you up to coordinates of about 1000. If they viewer can see far you may get high coordinates, but your need to place vertices precisely decreases as your distance from the camera increases, i.e. vertices within 10m of their correct locations is fine since two adjacent pixels contain vertices 20m apart. It's close to the viewer that you need the precision.

Dungeon Siege is a game that had to deal with this problem and did it in this manner. If you don't have it you might get DS I and play with the editor. That might give you some insight to the specific issues you need to deal with. They also did a few presentations on their game. I think there was one on gamasutra and another for the GDC.

##### Share on other sites
Okay I have done some tests with transforming my entire LOD patch every frame on the CPU and it has no performance loss noticable, which was not what I expected. Guess my bottleneck is fill or bandwidth. Thanks for the advice, I am going to implement my current system (which I recently found out is called a clipmap, although I thought I pretty much made it up), using a local coordinate space based at the center of the base level. Then I only need to update the whole LOD when the base level is shifted.

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

• 26
• 11
• 9
• 9
• 11
• ### Forum Statistics

• Total Topics
633702
• Total Posts
3013450
×