Creating a flat terrain with lines on it.

[njord]

Hello all. We had several somehow related topics but i will start over and upload 3 example scenes to make it clear. We are modelling an airport terrain (actually its just a big gmf(s), we are not using LE heightmap). As all airports, it has some lines on it for the pilots and vehicle drivers to drive with respect to. Initially we had modelled our terrain with trivial polygons and we added lines as seperate polygons over the large terrain surface. To overcome z fighting between the surface and the lines, line polygons are slightly elevated from the surface (lets say 5 cm). While moving on the terrain with a vehicle we look at these lines almost horizontally and as they do not have a thickness (lines are just polygons!) we had aliasing problem on lines. Unfortunately defferred LE antialiasing support was not enough for us at this point. Take a look at our first scene in LE editor. Move the cam very close to the surface. Observe the aliasing problem on lines

 

To solve this problem, we have divided the large terrain into tiles. And for each square tile, we have created a detailed texture including both the terrain and lines. Getting rid of line polygons, we have converted the pixel aliasing problem into texture aliasing problem, where mipmaps and anisotropic filtering are nice solutions and present in LE. However, we could not use small textures with tiling option for grass or concrete anymore, because we needed also lines on them, we had to use much bigger textures. There are exactly 103 tiles on the uploaded scene 2 and each of them have the texture size of 4096x4096 (DXT5 with mipmaps). Each texture is 10923 KB which makes 1.07 GB of textures on the total just for terrain surface. At this point our aliasing problem of lines is solved. Everything seems good, no "stair" effect on lines, mipmaps just work fine. But as soon as we add buildings, LE refuses to open the model on my GTX470. Most probably we are exceeding the total texture memory.

 

Uploaded scene 3 is the same with scene 2 except the texture sizes are 1024x1024 instead of 4096x4096. LE now opens up the same small textured terrain with buildings, there is no problem.

 

First of all, I would appreciate any information regarding texture usage. How much texture, how big textures can we use in LE or any 3D application. How to determine this ? What happens if the texture sizes present in a scene exceed the total amount of gpu memory ? Are they paged on cpu ram, how ?

 

Secondly, do you have any ideas how to solve our aliasing problem without hitting a wall ? What can we do about scene 2 ?

 

Thanks in advance.

 

IMPORTANT : move different scenes into the LE editor map folder one by one. They have similarly named resources. Dont let LE to pick one of several resources randomly.

 

UPLOAD LINK : ftp://81.214.87.33/Scenes.rar

username katron

pass katronftp

[Michael Betke]

You could just place the lines as splines in your 3d app, and "shapemerge" (compund object) the lines into your runway terrain model. it will generate more tris of course but you have no zfighting and you need no alphamap. the engine can deal good with high polycount so it doesnt matter a lot.

[Guest Red Ocktober]

i wanted to take a look at the levels but i cannot open the link...

 

--Mike

[njord]

Michael, we have tried that. Yes, there is no z fighting and no need for alpha. But there is still aliasing problem. What solves aliasing is generating a huge texture with mipmaps and using anisotropic filtering. In the case of a "compound object" the concrete surface and a line on it still has different textures, they dont have a "compound texture with mipmap".

 

Red Ocktober, sorry the link was broken. I will fix it as soon as possible.

 

By the way, since we probably hit the wall over texture memory usage, we have tried using LOD1 for all the tiles. All original tile gmf's have a 4096x4096 10mb texture. All LOD1 gmfs of these tiles have a 256x256 43KB texture. So, only tiles around us would have high res textures with LOD enabled, we thought we could have decrease the pressure on GPU ram. But it did not work, LE loads all original and LOD gmf textures to GPU right ? Then what is LOD for ? It does not help decrease GPU texture ram usage, but only decreases the amount of geometry passed on to GPU ?

[Michael Betke]

what do you mean with aliasing problem? If you "cut" your lines into the runway model and apply the lines as a multi-material all should be smooth. I used it a lot last year.

 

LOD is for geometry reduction in first case. Your mipmaps reduce the texture load. You could also use other material on your LOD model. Like only a diffuse so the normal/spec isnt rendered when viewing from a distance.

 

But I think Leadwerks loads all textures at once so I dont see a benefit. Newer engines are streaming which means only the textures in camera view are loaded as far as i know.

[njord]

1)

what do you mean with aliasing problem?

 

I attached two snapshots.:

Scene 1.png : Scene 1 screenshot with lines as seperate polygons, there is aliasing. But low texture memory usage (small textures are tiled over huge terrain surfaces, lines are extra surfaces).

Scene 2.png : Scene 2 screenshot with lines as textures (with mipmaps & filtering enabled), no aliasing. But high texture memory usage (since textures are unique now, they are not tiled as before).

 

2)

If you "cut" your lines into the runway model and apply the lines as a multi-material all should be smooth. I used it a lot last year.

 

What do you mean "cut" your lines into the runway ? Should we put the lines as seperate surfaces with different materials on the terrain surface? Is this the same thing you explained here ? :

 

You could just place the lines as splines in your 3d app, and "shapemerge" (compund object) the lines into your runway terrain model. it will generate more tris of course but you have no zfighting and you need no alphamap. the engine can deal good with high polycount so it doesnt matter a lot.

 

2)

LOD is for geometry reduction in first case. Your mipmaps reduce the texture load. You could also use other material on your LOD model. Like only a diffuse so the normal/spec isnt rendered when viewing from a distance.

 

When we create a LOD gmf with a smaller texture for each high resolution terrain tile gmf, GPU texture memory usage is increased even more which is the opposite of what we wanted. This means LE loads all the textures to the gpu. How can I reduce GPU texture mem usage , if LODs with smaller textures do not help me at all ? By the way both our original models and their LODs do not have normal/spec but only diffuse textures.

 

3)

Your mipmaps reduce the texture load.

 

What do you mean by that ? When we create mipmaps, textures are enlarged so that several mipmap levels are additionally stored ?

 

4)

But I think Leadwerks loads all textures at once so I dont see a benefit. Newer engines are streaming which means only the textures in camera view are loaded as far as i know.

 

I think the same. I downloaded this program which shows GPU memory usage : http://technet.microsoft.com/en-us/sysinternals/bb896653 .

Here are its results on scenarios with increased texture usage : Attachment3.rar

 

PS: I will fix ftp link asap.

 

PS2: Any other solutions to the aliasing problem like texture blending or decals or anything on your mind, please share it.

Attachment3.rar

[Josh]

This is a very difficult problem because you want unique detail everywhere, but you have an enormous area to span. The problem you are experiencing are fundamental problems with the nature of real-time graphics, although MSAA might potentially help improve this. I don't know if there is a good solution.

[Guest Red Ocktober]

just an opinion... i hope it's helpfull...

 

i think that you're approaching this the wrong way... for the following reasons...

 

1- it's gonna be hard to get the level of detail you want across a huge terrain...

 

2- there's no reason to have the entire large terrain present in memory when all the player's view will be able to see will most likely be in the immediate range of the view cam...

 

based on this reasoning i'd suggest you rethink the approach...

 

a possible solution (one which i use a lot) is to tile a 9x9 grid (the terrain) and use a treadmill algorithm so that the grid the player cam is on is always the center grid, and is surrounded by the remaining 8 grids... the details can be represented by individual decals or structure, and positioned at initialization and separate from the "terrain"...

 

this way each terrain grid can be smaller and can have a high level of detail in the terrain grid, and the fact that it's a flat terrain facilitates it...

 

of course the texture will repeat with each grid...

 

good luck...

 

--Mike

[Josh]

Probably the best way is to make a lot of textures that can be mixed and matched, and make the whole thing a grid with the different textures applied, at least in the areas that require a high density of different textures.

[njord]

Ok the link is fixed. You can download our sample scenes again

 

Red, what i understand that you tell us to put low res huge terrain, and keep a moving "treadmill" small grid-ed terrain (9 tiles) around cam at all times. But tell me, when we move, we need to see the ground passing beneath our feet. How are we going to do that if we keep the same tiles? If not, how are we gonna change them every time we move the cam?

 

What we are doing is now actually parsing the huge terrain into square tiles (forming a quad tree). Where we needed details, we have divided the square tiles at a greater depth. There are 2 parameters for detail in this approach, grid tile size and texture size. Smaller the tile size and larger the texture size -> more details and vice versa. We have kept texture size always 4096x4096, so one parameter left to adjust. We just divided square tiles more and more when we needed details in a quad tree manner.

 

Anyway, we already have a grid on our terrain, check out scene2 (if you cannot open it check scene3 it is low res version) on ftp link. But as you can see on the attachment3.rar of my previous post, we have texture memory problem.

 

1)

Probably the best way is to make a lot of textures that can be mixed and matched, and make the whole thing a grid with the different textures applied, at least in the areas that require a high density of different textures.

Josh, i think we already did that, or did you mean something else ?

 

2) Josh, can you tell us about LOD's please ? All the textures in gmfs and their lods are loaded into LE and then transferred directly to GPU right ? So there is no point for us to use LOD's in our case since they would increase the GPU memory pressure even more?

 

3) What about terrain paging? If I can implement an algorithm that silently loads any gmf on the background, I could load & unload tile GMF's while moving on my grid. This way I would never have too many tiles (thus textures) loaded at the same time and won't fill my texture memory ever at all. But one problem, last time I checked LE didnt allow me to call "LoadModel()" from another thread other than the main thread. If I cannot load meshes on the background, surely comes the stalls and freezes

[Guest Red Ocktober]

when we move, we need to see the ground passing beneath our feet. How are we going to do that if we keep the same tiles? If not, how are we gonna change them every time we move the cam?

 

no... the grid you are on will always be the center grid... and static... the grids in front or behind (or left or right) will reposition themselves depending on the direction you are moving in... and they only move when the cam is a certain distance from the center of the center grid...

 

this is the basis for my infinite ocean code... i'll post it later this morning... gotta get an hour or two of sleep...

 

********* added *************

 

sorry it took me a lil longer than promised to get to this... real life issues were unexpectedly overwhelming today... anyways,

 

here's the paired down logic (in BlitzMax it should be easy enough to translate) of how i implemented the treadmill algorithm in my Leadwerks infinite water code (only the logic to moved grids up is shown for clarity... implementing the downward and sideways treadmilling should be obvious...

 

this function moves all the grids down when the view moves beyond one half the size of the center grid (each grid is 340 x 340)...

 

Function MoveOceanRowDown()
  Local patchPos:TVec3
  If Game.centerOceanIndex=4 Or Game.centerOceanIndex=5 Or Game.centerOceanIndex=6
     patchPos=EntityPosition(Game.fw.renderer.waterPatch1)
     patchPos.z=patchPos.z-1020
     PositionEntity Game.fw.renderer.waterpatch1,patchPos

     patchPos=EntityPosition(Game.fw.renderer.waterPatch2)
     patchPos.z=patchPos.z-1020
     PositionEntity Game.fw.renderer.waterpatch2,patchPos

     patchPos=EntityPosition(Game.fw.renderer.waterPatch3)
     patchPos.z=patchPos.z-1020
     PositionEntity Game.fw.renderer.waterpatch3,patchPos

  EndIf

  If Game.centerOceanIndex=7 Or Game.centerOceanIndex=8 Or Game.centerOceanIndex=9
     patchPos=EntityPosition(Game.fw.renderer.waterPatch4)
     patchPos.z=patchPos.z-1020
     PositionEntity Game.fw.renderer.waterpatch4,patchPos

     patchPos=EntityPosition(Game.fw.renderer.waterPatch5)
     patchPos.z=patchPos.z-1020
     PositionEntity Game.fw.renderer.waterpatch5,patchPos

     patchPos=EntityPosition(Game.fw.renderer.waterPatch6)
     patchPos.z=patchPos.z-1020
     PositionEntity Game.fw.renderer.waterpatch6,patchPos
  EndIf

  If Game.centerOceanIndex=1 Or Game.centerOceanIndex=2 Or Game.centerOceanIndex=3
     patchPos=EntityPosition(Game.fw.renderer.waterPatch7)
     patchPos.z=patchPos.z-1020
     PositionEntity Game.fw.renderer.waterpatch7,patchPos

     patchPos=EntityPosition(Game.fw.renderer.waterPatch8)
     patchPos.z=patchPos.z-1020
     PositionEntity Game.fw.renderer.waterpatch8,patchPos

     patchPos=EntityPosition(Game.fw.renderer.waterPatch9)
     patchPos.z=patchPos.z-1020
     PositionEntity Game.fw.renderer.waterpatch9,patchPos
  EndIf

 

 

the function is called by this logic when the view position reaches 170... the player view location is the key to triggering the treadmilling of the grids...

 

 

  Local camPos:TVec3=EntityPosition(Game.fw.Main.camera)
  camPos.y=Game.waterHeight

  If (Game.centerOceanPatchLoc.z-170) >camPos.z 
    MoveOceanRowDown
    Game.centerOceanPatchLoc.z=Game.centerOceanPatchLoc.z-340
    Game.centerOceanPatchLoc.y=game.waterheight-3
    PositionEntity Game.fw.renderer.waterpatch, Game.centerOceanPatchLoc
   Game.centerOceanPatchLoc.y=game.waterheight
  EndIf

 

the current grid that the player is currently on, and the grid that the player is about to walk on is not moving, but the grids below (lesser .z position) the current grid (the one the player is leaving) are being repositioned to a location above (higher .z position) that of the grid that the player is about to walk onto...

 

the grid that the player is about to walk onto grid will become the new center grid...

 

there'll always be one grid above and one grid below the grid that the player is one at any given time...

 

i hope my bumbling explanation makes sense...

 

 

--Mike

[njord]

Thank you for explaining your method Mike. You basically pave tiles in front of you using the tiles behind you, like a treadmill. But in our case, when we divide the airport, all the tiles are unique. Just look at our scenes in Editor (ftp). Check the .dds textures in the folder. Those big textures (tiles) are all paved around the airport, unless you want to put the lines as seperate polygons and get aliasing artifacts.

[Guest Red Ocktober]

since the terrain is flat, i was thinking that this method would provide 1/2 of the unlimited flat terrain...

 

the second half (the detailed ground marking) i was thinking might be doable using decals... or something similar...

though i've yet to experiment with em, so i'm not sure and this may just be a wag (wild assed guess )...

 

if i get a few free minutes, i'll try something along these lines...

 

 

--Mike

[Scott Richmond]

Haven't really read through all of this thread, but I thought I might add that if you really need high detail decals, and they're only simple lines, then you could probably write a shader of some sort that mathematically draws the decals. That way you'd have unlimited details, like vector graphics.