TGEA 1.7.0 Bug - increased clipMapSizeLog2 values cause crashes

#1 I never had it work over 10 here.

#2 I can get up to 13 on my Nvidia 8800 GT, pretty much overkill at that setting, but I found that I needed 11 to match the visual characteristics of distant terrain that I got with the same terrain in TGEA 1.0.3. Still, as long as 10 is pretty safe, it's not a bad compromise.

#3 Going past 11 is going to be risky due to the texture dimension restrictions on most cards, e.g all ATI cards before the HD series (except for the X16xx and X19xx cards) support a maximum texture size of 2048x2048. Going up to 13 gives you a texture size of 8192x8192, which is the largest the GeForce 8/9 series support.

We should be asserting if you try to create a texture which is larger than what the card supports, and even if we're not D3D should. Clearly though we aren't (unless you've been doing all of this in a release build instead of a debug build), which is a bit concerning.

#4 I don't care if it supports greater than 11, I just care that it crashes.

#5 Hmm, the out-of-bounds errors in the ClipMap code sound interesting. Will look into that.

Agree that Torque should check clip map sizes against hardward limits.

On a general note, increasing the clip map size past your screen resolution is completely pointless. Ideally, there should be a 1:1 match here but since clip maps must be powers of two, the clip map is likely to always be somewhat bigger than max(width,height) of the screen res.

#6

Quote:
On a general note, increasing the clip map size past your screen resolution is completely pointless.

This seems like it would be true, but it doesn't pass the "eyeball" test. With a resolution of 800x600 I can observe the difference in terrain texture clarity for settings of 10 and 11 for clipMapSizeLog2 . Those settings create clipmap sizes of 1024 and 2048 which are both larger than 800x600. It's not super obvious, but it's not hard to see. On the other hand, I cannot see a difference from 11 to 12. Perhaps it's a Nyquist thing.

#7 Interesting. If it makes a visual difference, then arguing that it theoretically shouldn't is futile. Assuming that clipstack levels are fed from the correct miplevels in Torque (and that other clipstack level calculations are correct), that's indeed an interesting find.

#8 ClipMapSizeLog2 value of 9 is not safe value.

At 128M Video Memory ,T3D Demo crashed (res 1024X768( FSAAX4), clipMapSizeLog2 =9)

In order to run for the T3D Demo (at res 1024X768( FSAAX4)), clipMapSizeLog2 value should be lowered to 8.

if many object(building,character,etc) has in game, clipMapSizeLog2 value should be lower.(At least Video Memory 128M or 256M) - (T3D Demo (res 1024 X 768 (FSAAX4), clipMapSizeLog2 = 9) used 200M Video Memory)

if do n't reduce clipMapSizeLog2 value, prgram crashed. or as shown below , often dts object is darken.

#9 As many have said, it should warn instead of asserting and we will look at that for the next point release, but I think it's important to understand that this is a video card memory limitation.

Setting the log size increases the amount of video memory required, and if you want to be able to support cards with lower levels of video memory, then you'll have to give up things like FSAA 4, detailed (and therefore large) clipmap texture sizes, and large/many textures in general.

#10 What Stephen says is spot on.

One addition that some people might not be aware of: if you set your clip map size to, say, 2048x2048, it is not just one single 2048x2048 texture that is allocated by the clip map code. Rather, it depends on your texture size which in the case of legacy terrain is the virtual texture size computed by "BlockSize(=256)*squareSize*texelsPerMeter".

So, let's say you have a virtual texture size of 16384x16384 and a clip map size of 2048x2048, then the clip map code actually allocates four 2048x2048 textures (mipcount(texturesize)-mipcount(clipmap)+1).

If you are using MegaTerrains, then you add another clip map for each terrain block, so given the settings above and a 2x2 MegaTerrain, you end up with sixteen 2048x2048 textures.

#11 If there is not enough video memory , instead of program crashed the system memory not available?

#12 @Kim
Not sure I am understanding you correctly here. Do you mean Torque should error out rather than crash when running into these situations? If so, you are definitely right.

-----

One addition to the addition above: those sixteen textures I spoke of aren't normal textures. In the case of legacy/MegaTerrains terrain, that's render target textures, i.e. DEFAULT_POOL stuff that adds directly to video memory payload.

#13 //EDIT: this is mostly BS

@Jeff
I think I now know, why you are seeing the differences whereas they in fact should not be there.

The culprit is one ulgy problem with Torque's clip map code: the code will drop higher detail levels when the clip stack delta exceeds four levels.

What this means is that if a legacy terrain block wants to render out and spans more than four levels on its clip map, the clip map will cut off all but its four coarsest LODs. Since the clip stack depth directly depends on the ratio between the source texture size and the clip map size, increasing the clip map size while leaving the source texture size counters the LOD dropping and at one point will cause all LOD levels to be recovered.

So, in short, what you saw with lower clipMapSizeLog2 values was never your initial texture source data but rather some blurred lower-res stuff from higher miplevels.

Atlas has the same problem but since it renders in chunks, has a better tolerance than legacy terrain.

#14 Should not have jumped to conclusions that quickly. After some proper research and testing (which should have happened beforehand), I found that due to the way legacy terrain works (it's not rendering out all of a block in one go), MegaTerrains aren't prone to these issues as Atlas is. You need to have some real crazy setup to start to see LOD issues.