• Create Account

# LOD algorythm for sphere made of a cube. Help needed.

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

5 replies to this topic

### #1Rannion  Members   -  Reputation: 154

Like
0Likes
Like

Posted 12 September 2013 - 12:23 PM

Hi,

I would really need some help here.

I have a sphere made from a cube so my first lod 0 is 6 patch of 33 verts. The usual stuff.

Now I'm trying to find an algorythm to increase the LOD given a point on the sphere. And this seams really not trivial.

I have tried a  couple of things already but even when looking at the same face of a cube at some points there is irregularities when splitting patches into 4 smaller ones.

The worst is when looking at another face of the cube, the references are changing and it's driving me crazy.

So here I am asking if anyone has seen anything about that particular problem or has faced it or any clue about it.

### #2C0lumbo  Crossbones+   -  Reputation: 1431

Like
0Likes
Like

Posted 12 September 2013 - 12:27 PM

This is the algorithm I'm using: http://www.gamasutra.com/view/feature/1754/binary_triangle_trees_for_terrain_.php

There are plenty of other options though.

### #3Rannion  Members   -  Reputation: 154

Like
0Likes
Like

Posted 12 September 2013 - 12:45 PM

Thanks, but I'm fine with this.

My problem is the connectivity with different faces of the cube as the axis are changing from one to another.

I'm looking for a better way to discribe this problem at the moment.

This is somehow my starting point if you prefer : http://mathproofs.blogspot.ch/2005/07/mapping-cube-to-sphere.html

So you see that each face is constructed differently like the up face would be constructed around X and Z axis (given Y up) but the down face will be build around X and -Z as the up vector is rotated.

And this is what makes the LOD a real nightmare to me.

### #4Rannion  Members   -  Reputation: 154

Like
0Likes
Like

Posted 13 September 2013 - 06:22 AM

First I have a constraint to have adjacent patches being at the same lod or +-1 lod. This is to guarantee perfect edges connections.

I have read that some people implemented 6 different quadTree to implement this kind of LOD.

Ok but I don't see how it could possibly help. The 6 quadTree would still need to know about their neightbours at edges. In the worst case, you would need to zoom in 3 different quadTree.

I'll start to think about having references between patches on a flat unfolded cube instead of the 3D one as my patches knows on which face of the cube they are, I can still construct them.

PS: If you think I should post in another forum thread let me know.

### #5C0lumbo  Crossbones+   -  Reputation: 1431

Like
1Likes
Like

Posted 13 September 2013 - 11:38 PM

My approach is that each patch stores an array of its 4 neighbours.

To calculate lods, I iterate through all the patches, and determine the lod based on the distance of the camera from the patch's AABB. By using that simple approach and tuning the lod thresholds, I find I can avoid having situations where the lod changes by more than one. Once each patch has decided on its own Lod, I can iterate through them all again and decide on the index buffer to use that will eliminate cracks (using the BTT algorithm I posted earlier in the thread).

The tricky bit is actually generating the list of neighbours in the first place. My game is a tile based strategy game, and I actually have a hierarchy of classes that make up the structure:

- Face (one of the 6 faces of the cube)

- Section (often I can't stretch a single texture across a whole face, or there's too many vertices for a vertex buffer, so I split a face into sections, I can render patches within a section with no render state changes)

- Patch (the unit of lodding)

- Cell (the game based tile)

For my strategy game, the cells need to know their neighbours anyway for gameplay reasons, so to calculate the patch's neighbours, I'm just peeking at their cell's neighbours.

My code that calculates cell's neighbours is particularly inelegant (not least because my cells need to know diagonal neighbours too), so I don't think I'll be able to post anything helpful. The approach is that I have a function that will stitch one edge of the rectangular grid of cells that make up a face to another edge of a grid of cells and I call that 12 times for the 12 edges of a cube to build up the neighbour lists. Because of the topology of a cube, some of the stitches require a reversal of the direction.

### #6Rannion  Members   -  Reputation: 154

Like
0Likes
Like

Posted 18 September 2013 - 12:40 AM

Apparently it confirms what I'm experiencing. That neighbours link problem is really messy and it's a real drag.

Plus I haven't got it running properly yet and the code is already looking awfull.

So based on my experience and what you said I'm trying a different approach now which should still meets my requirements.

Everything will be at the same lod level allways avoiding patches to know about their neighbours. I'ts a bit more brutal but apparently it might just do as well.

When from far away the planet won't have too much patches to render and when just above ground the culling is powerfull enough to do some decent job with the 6 quadtrees.

That is concidering my planets are way smaller than even our moon.

Anyway, that area would be a good subject for a big tech doc.

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS