TGEA 1.7.0 Beta 2 Bug - Atlas drops highest texture detail level

#1 I am not working with blended terrains, so one peculiarity went unnoticed by me: copyBits was already bumping the mipmap level for blended terrains (but not in isDataAvailable).

So, to make this fix work with blended terrain, comment out the following code in atlasClipMapImageSource.cpp@202:

if (!isUnique())
      mipLevel += 1;

Ergo: no improvement for blended terrain. The bug only applied to unique texturing with Atlas.

#2 Ok, finally have the fix for the clipmap code. While most of this matters only to unique texturing, the LOD choosing problem will also affect blended terrain.

So, be prepared for a long list of changes. Here we go...

The first problem is that AtlasInstance drops the highest mipmap level when setting up the clipmap texture (the clipmap code will still access that level correctly given the fixes above, but clipmap setup will be wrong.) To fix this, go into atlasInstance2.cpp@128 and change the following:

// Don't forget to set the texture size!
                     mClipMap->mTextureSize = BIT(acmis->getMipLevelCount()-1);

to:

// Don't forget to set the texture size!
                     mClipMap->mTextureSize = BIT(acmis->getMipLevelCount());

Explanation: log2(textureSize) is the number of mipmap levels for a texture of size textureSize. The -1 above drops one level.

After applying this fix, the clipmap code will bail at runtime as there are some issues to fix. On we go.

First, the mipmap level calculation in the clipmap code has to be adjusted. It is off by one, meaning it always goes a mipmap level higher than what is correct. There are several places in clipMap.cpp where you can see code like this:

getBinLog2(cse.mScale) + getBinLog2(mClipMapSize)

Either replace all these occurrences with the following, or (better) put the following in a separate method and replace all occurrences by calls to this method (taking cse.mScale) as a parameter:

getBinLog2( scale ) + getBinLog2( mClipMapSize ) - 1

After applying these fixes, I found that the code that initially was commented out in atlasClipMapImageSource.cpp and that I had suggested to reactivate here because Atlas terrain loading was deadlocking, can now (and probably should) be commented out again. However, I am only beginning to dig into the Atlas I/O code which is why I don't have a proper explanation.

I really hope I haven't forgotten anything as I extracted this from among my more extensive changes to Atlas. I'd be glad if someone could test and verify all this.

------
Edit: These fixes to the clipmap code are incomplete. Issues remain.

#3 Hi Rene.
Bumping issues with texture's detail levels.

Running stock TGEA 1.7.1 SDK

I'm experiencing issues when Atlas rendering textures from second LOD only for blended terrains. Tried applying fixes in this thread - no changes.

You can easily see the problem if you put debug texture ( like this one: http://my.afterworld.ru/~bank/lod_test.dds ) replacing the rock1.jpg (save as rock1.dds ) and snow.jpg in terrain_water_demo mission (AtlasDemo game example).

I have same issues, when the first two (largest) mip levels are never rendered - exporting 1024 terrain with sq.size = 4 and 1024 opacity mask from Grome editor.

What I came up with - is I can force to render highest mip level by decreasing the VirtualTexture while running atlasGenerateBlenderTerrain(), but then - the textures rendered twice larger (less tiles over whole terrain) and it's not really suitable for our needs.

Instructions on TDN does not help efficiently, as more I increase the TreeDepth, I get messages like:
"NOTE: verts/chunk is low; for higher poly throughput consider setting the tree depth to X and reprocessing."
And it's really low - less than 200 verts per chunk.

Any help/hints/link appreciated.
I can share my *.raw/lightmap/opacity_mask if needed.

#4 This *might* be your issue.

The Atlas vertex shader is the one that does the clipmap level selection. So per-vertex it calculates the distance from the vert to the clipmap center of focus to select the correct clipmap level for that vert.

A problem occurs if your highest detail in the clipmap is smaller than the distance between verts. Since the hardware interpolates values between verts... if the triangle you standing on is too big none of the verts get the highest detail clipmap layer.

If the clipmap level selection was done per-pixel this issue goes away and all the detail levels appear... no matter the size. I've made this change in our own shaders and it solves the issue, but it does require more per-pixel computation.

#5 Oh, thanks Tom, I *think*I got it.

Well... by making terrain sq.size = 1 I'm "forcing" verts to be closer to each other (smaller triangles)... but no luck here. I still miss my first two mip levels.
And, no matter if I use 512x512 texture or 256x256 (smaller textures are simply more tiled).

With default values (sq.size=4, treeDepth=4, heightError=1.5) I was able to see highest LOD, but only when I set virtual texture size to 8192 (default 32768/4). But then - the texture is 4 size bigger (less tiles), so I again missing the quality I want.

Then I set treeDepth to 6 and I was able to see both of highest LODs, hooray! But I get warning that 208 verts per chunk is too low and I need to reprocess with lower treeDepth... Should I ignore that warning?

Now I see the highest LOD of texture, but when I try to set virtual texture size to 64k (to double tiling of textures), I'm missing top highest texture LOD. How do I increase tiling, but keeping the displaying top LOD of texture? Increasing treeDepth again? Not a good solution for me, as from the initial 20mb atlas file I already have 60mb.

I'll keep trying to find out more on that - although I'm not good at clipmaps/atlas/shaders
thanks!

edit: spl

#6 Sorry for the long delay in responding here.

Anyways, maybe I should give a (sort of) short explanation about the two major issues that are involved here: cliplevel dropping and Atlas mesh generation.

Cliplevel dropping

The clip map has to span all miplevels beginning from its own miplevel (miplevel(512) == 9) up to the miplevel of the terrain texture (either unique or virtual in the case of blended terrain). This number determines the depth of the clipstack.

What causes cliplevel dropping now is a restriction inherent in the clipmap rendering code which limits the number of levels that can be rendered out in one go to four. This makes sense as each level is a separate texture that has to be passed on to the graphics card.

With Atlas, dropping levels happens when a single geometry chunk spans more than four levels on the clip map which most often is the case near to the camera causing high detail levels to be lost.

This all shows why you were seeing different results when you fiddled with the generator's parameters. Unfortunately, there are many cases where *no* configuration will give you a terrain that renders correctly.

ATM, deeper geometry trees (increasing treeDepth) and higher clip map sizes (increasing AtlasInstance2::clipMapSize) are the only means of coping with this (highly annoying) issue.

Atlas Mesh Generation

Well, I'd like to avoid being too candid here but let's just say this part of Atlas is in dire need of a make-over. Generate two versions of the same terrain, one with a low maxError and one with a high maxError (both with a reasonably high treeDepth), and then take a look at both of them in-game using AtlasInstance2::noUpdate=1 (plus AtlasInstance2::renderWireframe=1 and AtlasInstance2::renderChunkBoundsDebugLevel=1) to get a good picture of what I mean. You'll instantly understand a few things about Atlas that you never wanted to know.

Atlas Rendering

There is another problem that played into this with pre-1.7.1 Atlas: geomorphing. Suppose you run into cliplevel dropping problems and want to fight back using deeper geometry trees, but in order to prevent explosive growth in data set sizes, you also adjust maxError. While now you *may* wind up with a configuration that renders all detail levels even with a 512px clip map, you will likely run into a whole range of configurations where the terrain starts to wobble like mad.

What happened is that the distance that morphing had to bridge got bigger and closer to the camera (Atlas does not limit screen space errors) and thus became ever more visible.

In 1.7.1, Atlas does not do geomorphing anymore since with the current geometry code, it simply doesn't make sense. Once the geometry stuff has seen some TLC, color blending will probably take the place of geomorphing.

@bank
I hope this helps you a bit in your struggles with Atlas. Haven't yet responded to your email. Will do that next.

BTW, sometimes ending up with ridiculously low polycounts in chunks is the only way of generating properly behaving terrains with Atlas.

@Tom
I'd be real interested in your changes. How do you pass all the clipmap data to the fragment shader without running out of samplers or bumping into other limits (like badly supported volume textures)?

//EDIT
Strange typos... what's going on inside my brain?

#7 @Rene - It was a fairly simple change and didn't involve any additional samplers. Note i haven't even tried this on anything other than shader 3.0...

// NOTE: You need to change the C++ code to do a setPixelShaderConst() for mapInfo.
 
FragOut pixClipmap(  PixClipMapConnectData IN, 
                     uniform sampler2D diffuseMap[mapCount] : register(S0),
                     uniform float4 mapInfo[mapCount] : register(C0))
{
   FragOut OUT;
 
   // Do a layered blend into accumulator, so most detail when we have it will show through...
   OUT.col = tex2D(diffuseMap[0], IN.texCoord[0].xy);
 
   for(int i=1; i<mapCount; i++)
   {
      // Calculate the fade value per-pixel.
      float fadeDist = distance( mapInfo[i].xy, IN.texCoord[i].xy );
      float fadeVal = fadeDist * (2.0 * fadeConstant) - (fadeConstant - 1.0);
 
      float scaleFactor = saturate( fadeVal );
 
      float4 layer = tex2D(diffuseMap[i], IN.texCoord[i].xy);
      OUT.col = lerp( layer, OUT.col, scaleFactor );
   }
 
   return OUT;
}

To be sure everyone understands what this does...

Say your standing on the middle of a large triangle. The correct fade value at your position at the center of the triangle is 1, but the verts of the triangle are far enough away that at each vertex the fade value is 0.

When you calculate your fade per-vertex the 0 is interpolated across the triangle. That clipmap layer across that entire triangle would not be visible.

Now if you instead calculate the distance per pixel you'll get the correct interpolation to 1 at the center of the triangle. In this case that clipmap layer will be visible.

This change is not important if your clipmap is fairly low detail... but if you have a high detail it improves things alot.

#8 @Tom
Hey, thanks for posting this! Interesting change and yep, makes a lot of sense.

Unfortunately, it won't solve the real problem, I think, which is that certain clip map levels never even get to the shaders. As soon as you exceed the four level delta on the clip stack, you will end up with your higher LODs not appearing at the shader end at all.

Ben suggested laying out Atlas primitive buffers in 2D quadtree fashion to be able to render a single chunks in multiple batches. Depending on where Atlas is going, this may be the proper way to deal with the problem.

I found using more samplers to not make sense, especially because when doing some more elaborate rendering, you'll want to have some samplers available still.

#9 @Rene - Right. This won't help if your clipmap is truncated by the sampler limit. But once you solve that (it takes a ton of experimentation with the creation step) then this would be your new problem.

We implemented a vertex buffer based TerrainBlock implementation a few months ago. TerrainBlock sucks because it spends a crazy amount of CPU time building an optimal list of visible triangles per frame. So we went the opposite direction... we built 4 static VBs for the entire terrain and rendered it with 4 draw calls. Instantly we shot up to like 400fps... but the clipmap sucked. This was again because the levels were being truncated by the 4 sampler limit.

So to solve this issue i broke the terrain into more draw calls. First i built a list of index buffers for rendering the full NxN vertex buffer down to a single triangle par. I then built a simple quadtree structure with the vertex offsets to each sub-region of the vb i would need to render. Now using drawPrimitive start vertex offsetting i can draw the terrain in much finer chunks without the cost of switching thru 1000s of VBs.

Using this i was able to get really high resolution on the terrain clipmap, but at a cost. I went from 4 draw calls to like 30 or so draw calls. This was when our issues with the vertex interpolation of the fade values became apparent.

So thats what i tired and it if you did something similar with Atlas it would work.

Still i saw two issues.

First high resolution clipmaps look bad. Once you get to a really high resolution you can see the bad falloff between levels. This is because normally mipmap selection takes into consideration the screen area of the triangle where as the clipmap cannot not. You just get a falloff from the focal point.

Also i wonder if all the work to maintain and render this complex structure is worth it. If i just broke the clipmap texturing into a multi-pass operation i could do the same work in fewer draw calls. I would render the same chunk N times to get the full clipmap resolution i need at the cost of a little more fillrate.

#10 - Quadtree layout of prim buffers

Yay, that's what Ben suggested for Atlas, too. So far, I refrained from implementing it because a) the generators are a nightmarish mess that I'd rather replace than modify, b) the Atlas geometry stuff already suffers from being needlessly complicated, and c) there are even more severe issues here.

Basically, if the rest of the geometry system was working as intended, then cliplevel dropping wouldn't really be that much of a problem and I don't think it would even be worth paying for the additional complexity here.

- Multi-pass

Great input. This may indeed turn out to be the far better option. Unfortunately, with (current) Atlas, we're talking about a *considerable* contribution to overall fillrate already. Also, I was thinking about going with color blending in place for the (now removed and fairly troublesome) geomorphing which in turn would also increase the fillrate.

Thanks, Tom, for the good ideas.