LOD support for my terrain scene nodes

Announce new projects or updates of Irrlicht Engine related tools, games, and applications.
Also check the Wiki
Post Reply
arras
Posts: 1622
Joined: Mon Apr 05, 2004 8:35 am
Location: Slovakia
Contact:

LOD support for my terrain scene nodes

Post by arras »

First, this thread is about work in development. It's nowhere from finished and it will not be finished soon maybe. Maybe never. Thats why I am posting it here. Even if I do not produce something useful, somebody else can get inspired.

I was thinking hove to add LOD support for my terrain scene nodes and hove this LOD should work. And I came with idea of kind of flexible tile which can be subdivided in to four smaller tiles and those can be subdivided further. All on run time of course. In such a way unlimited number of LODs can be created and more importantly LOD can be used in different ways. Except classical further away from camera = less detail I especially like idea of putting detail only where needed. Flat parts can consist of smaller number of large tiles while other parts can get more smaller tiles.

This idea was written in to class with work name of FlexibleTile. It is template in fact so it can use any vertex format. Rest is developed around this class ...or better say should be. Code which I provide here is mostly for testing.

Small demonstration program: demo source files

Image

Flexible tile class:

Code: Select all

template <class T> class FlexiTile
{
protected:
   T Vertex[4];
   FlexiTile *SubTile[4];
   
public:
   FlexiTile()
   {
      for(u32 i=0; i<4; i++) SubTile[i] = NULL;
   }
   
   ~FlexiTile()
   {
      if(isSubdivided())
         for(u32 i=0; i<4; i++) delete SubTile[i];
   }
   
   virtual void subDivide()
   {
      for(u32 i=0; i<4; i++) SubTile[i] = new FlexiTile;
   }
   
   virtual void unifi()
   {
      if(isSubdivided())
         for(u32 i=0; i<4; i++)
         {
            SubTile[i]->unifi();
            delete SubTile[i];
            SubTile[i] = NULL;
         }
   }
   
   virtual bool isSubdivided()
   {
      if(SubTile[0]) return true;
      return false;
   }
   
   virtual u32 getTileCount()
   {
      s32 count = 0;
      if(isSubdivided())
         for(u32 i=0; i<4; i++) count += SubTile[i]->getTileCount();
      else
         count = 1;
      return count;
   }
   
   virtual u32 getVertexCount()
   {
      s32 count = 0;
      if(isSubdivided())
         for(u32 i=0; i<4; i++) count += SubTile[i]->getVertexCount();
      else
         count = 4;
      return count;
   }
   
   virtual FlexiTile& getSubtile(TILE_CORNER position)
   {
      return *SubTile[position];
   }
   
   virtual T getVertex(TILE_CORNER corner)
   {
      T vertex;
      if(isSubdivided()) vertex = SubTile[corner]->getVertex(corner);
      else vertex = Vertex[corner];
      
      return vertex;
   }

   virtual void assignVertex(T vertex, TILE_CORNER corner)
   {
      Vertex[corner] = vertex;
      if(isSubdivided()) SubTile[corner]->assignVertex(vertex, corner);
   }
};
BlindSide
Admin
Posts: 2821
Joined: Thu Dec 08, 2005 9:09 am
Location: NZ!

Post by BlindSide »

There is one tiny problem with this however, Irrlicht should be getting VBO support soon, so modifying the tiles on the CPU might not be such a great idea, I was thinking instead to have a vertex shader based solution, but I haven't had any practical ideas.

One idea that will require atleast SM 3.0 is:

Image

So you take that mesh, and you hover it like a "blanket" based on the current world transformation of each vertice, and you use that world transformation as UV coords to read a texture in the vertex shader (This is what requires atleast SM 3.0) and you use the height obtained from this (It will be bilinear interpolated too, I think :D ) to specify the height of the vertice.

Basically, this mesh will follow the camera, with the camera always being at the center of it, so the camera will always see closest, the terrain with the highest resolution.

Offcourse, this is all done in the rasterization stage so there is no real application data concerning the terrain, this makes it difficult to do things like collision detection etc.

I'm not sure if I explained my idea correctly but I hope you get the "gist" of it.

Cheers.

PS: If the mesh is small enough, I may be able to send the heights as uniforms (Similar to Hardware skinning). I know that I can send around 880 floating point values to the shader as uniforms maximum, so the mesh has to be very low detail then (32x32 grid or something). But this might not be so noticable if they are arranged correctly.
ShadowMapping for Irrlicht!: Get it here
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
arras
Posts: 1622
Joined: Mon Apr 05, 2004 8:35 am
Location: Slovakia
Contact:

Post by arras »

I am not too deep in shaders but I understand concept. The thing is that you than can simply create mesh with smaller and smaller tiles toward center, then let that mesh follow camera just like my Tiled Terrains. Mesh would be of course totally static.

What I am aiming to however is mesh which can dynamically change its own LOD.
Yes that will require some CPU time, but I hope it will be offset by gain in rendering geometry.

What my idea allows is wide array of implementations. You can order it to change its detail anytime on any place. and still alove you full control of vertices.

Only problem I have is with texturing. One solution is to let just largest parent tiles be textured. Much better of course would be to allow also subtitles to be textured independently. This would require some kind of multi texture blending. I do not now now hove to do it however.
sp00n
Posts: 114
Joined: Wed Sep 13, 2006 9:39 am

Post by sp00n »

arras just see on T-Strip LOD algorithm. There is something similar to your method. I plan to implement it for Irrlicht by few days:)
arras
Posts: 1622
Joined: Mon Apr 05, 2004 8:35 am
Location: Slovakia
Contact:

Post by arras »

Yes it divide tiles in similar way to mine. Problem is that since he is rendering mesh using triangle strips he is limited in using one texture UV coordinates per whole mesh. I want user to be able to texture terrain per tile. This will of course be slower since tiles do not share vertices and indices. But in my eyes its worth cost.

Anyway, it is certainly interesting, looking forward to your work :)
dlangdev
Posts: 1324
Joined: Tue Aug 07, 2007 7:28 pm
Location: Beaverton OR
Contact:

Post by dlangdev »

i'm no expert in 3D, it looks like you're into procedural terrain rendering. so, i'm not sure if auto-mipmap will help here which is a different way of showing textures depending on cam distance. also, what's different is the approach on uv map at vertex level (is that right?). see http://www.codesampler.com/dx8src/dx8src_2.htm for more info about mipmapping.

it certainly is interesting to put some time figuring out where this method of procedural terrain (cpu based) will lead, it may lead into interesting rendering.

one application of it, one that would to interesting to play around is planet-wide terrain rendering. start with a spere and slowly add tiles as the cam gets more detail, dropping() and adding() tiles and textures as more details show. i know it sounds crazy to even mention it.

for gpu terrain rendering, i'm reading chapter 1 of gpugems3 and it talks about a lot of stuff about LOD and collisions. LOD is handled by using bigger blocks for distant while using small blocks for near. collision where an insect like a spider crawling a terrain, the geometry shader was mentioned to take care of those stuff. i'm also reading the shader code which i find too cryptic at the moment, it will take me months to even understand them.
Image
Frosty Topaz
Posts: 107
Joined: Sat Nov 04, 2006 9:42 pm

Post by Frosty Topaz »

arras, LOD support for your terrain would be great.

I've been having some problems getting your terrain to work with Irrlicht 1.4 (I have version 070803 of your source) and am wondering if you have adapted/are adapting your work for the Irr 1.4. (Or if it's just me having trouble)

Either way, great work! Please keep it up.
Frosty Topaz
=========
It isn't easy being ice-encrusted aluminum silicate fluoride hydroxide...
arras
Posts: 1622
Joined: Mon Apr 05, 2004 8:35 am
Location: Slovakia
Contact:

Post by arras »

dlangdev >> mipmaping is already in Irrlicht supported. Every time you load ITexture, mipmaps are generated (unless you told driver to not). What I have problem with is hove to apply texture to tiles of different size and they still result in continuous terrain without seams and borders.

With planet rendering it would be bit tricky since it do not consist of square tiles and gonna have two poles. But it would be possible.

I am not good with shaders myself, I was already looking at some info but I did not really get deep inside so this stuff is terra incognita for me yet ;)

Frosty Topaz >> I am sorry but I think I can't help you with that, I am sill working with Irrlicht 1.3 and was not even downloading 1.4. Can you describe problem you have? If not me somebody else can help may be...
BlindSide
Admin
Posts: 2821
Joined: Thu Dec 08, 2005 9:09 am
Location: NZ!

Post by BlindSide »

Ok, I wrote DX and OGL shader implementations of the idea I was speaking of before, here and here.

Now theoretically, they work (Infact the OpenGL one works fine but only in software mode and very slowly, like 1-2 fps). The reasons that they dont work is:

A. Texread from vertex shader is only supported on NVidia hardware and 6 series+ (Not currently implemented on any ATI hardware due to a funny loophole in the SM 3.0 specification where you only have to list the filtering modes for vertex texturing but don't have to actually support any types :roll: ).

B. They are only work hardware accelerated on Floating point textures, mainly 1 component and 4 component, and only those two. Neither are currently supported in Irrlicht.

As you can see in the DX one, I tried to simple fake the floating point format by storing it internally as a single component 32 bit float and then unpacking it dynamically in the vertex shader. This and other various attempts to hack the required format into the OpenGL driver have failed.

VBOs tend to work better for me in OpenGL, for some odd reason, so I would prefer it would work there, but ATI's R2VB (Render to vertex buffer, which is faster than vertex texturing, at 86 million verts per second) only works in DirectX.

The only solution left offcourse, is the fairly old and widely supported, render to FBO then copy to PBO (Pixel buffer object) that is bound to a VBO. This clocks out at around 60 mill verts per second (These stats are based on a 6600GT I think), which is still twice as fast as the vertex texturing which is only at 30 mill. (Btw on the newest drivers, the copy from FBO to PBO is done directly on the GPU hardware, so it is very fast).

This makes the last solution the most viable, if you wanna see an indepth explanation of how to implement this in OpenGL its right here.

Offcourse, this would also require floating point rendertargets (Possibly MRT if you wanna include normal calculation too, as you can only fit so much into 4 floats) and massive modifications to the rendering pipeline.

So its viable as a standalone demo of sorts, but not really something extremely easy to implement in Irrlicht.

Anyway, I just thought I'd share my research on the matter.

Cheers
ShadowMapping for Irrlicht!: Get it here
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
dlangdev
Posts: 1324
Joined: Tue Aug 07, 2007 7:28 pm
Location: Beaverton OR
Contact:

Post by dlangdev »

Hi Arras,

Just to let you know I'm taking major parts of your LOD terrain code along with the other code you posted a while back regarding procedural terrain.

This has something to do with procedural modeling of land (terrain), cities (streets and facades), buildings ( urban, suburban and rural ).

See for finer details here: http://delivery.acm.org/10.1145/1290000 ... EN=6184618

http://www.vision.ee.ethz.ch/~pmueller/ ... ersion.pdf

i've modified irrlicht so much now that i have to open a project on sourceforge for keeping the source code managed.

thanks for your code, i'm hoping you could come here often to post more procedural terrain code, or probably work on something similar later on.
Image
Post Reply