Jump to content
  • Advertisement
Sign in to follow this  

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

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

If you intended to correct an error in the post then please contact us.

Recommended Posts


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.


Thanks a lot for your comments.

Share this post

Link to post
Share on other sites

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.

Share this post

Link to post
Share on other sites

Ok, here is a bit more about this problem.


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.

Share this post

Link to post
Share on other sites

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.

Share this post

Link to post
Share on other sites

Thx for your answer.

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.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!