Game Development Community

Atlas problems and questions

by Paul Sprague · in Torque Game Engine Advanced · 06/19/2005 (1:02 pm) · 13 replies

I have some questions; perhaps someone has some anwers. :)

Everything is based on a 4097x4097 raw height map with a 2048x2048 texture.

Code used to build everything.
function runChunking()
{
    EnableWinConsole(true);// send logging output to a windows console window
    Echo("Starting chunker");

    generateChunkFileFromRaw16(
        "assets/semic/semic_16b_1c_4097.raw",
        4096, 20, 1.0 / 20,
        "assets/semic/semic.chu", 3.9, 6);
    Echo("Done chunking");
    
    generateTQT("assets/semic/semic_2048.jpg", "assets/semic/semic.tqt", 6, 64);
    Echo("Done");
    EnableWinConsole(false);
    Quit();
}

Output:
=== Chunk Statistics ===\
\===== Level    Count    Avg. Size
            0        1024      3345.493164
            1         256      13048.699219
            2          64      25561.406250
            3          16      38383.875000
            4           4      77857.000000
            5           1      186075.000000
========================================
                chunks:       1365
           input verts:   16777216
          output verts:    1042382
%
       avg verts/chunk:        764
NOTE: verts/chunk is low; for higher poly throughput consider setting the tree depth to 5 and reprocessing.
          output bytes:      50533
      bytes/input vert:       0.00
     bytes/output vert:       0.05
        real triangles:    9513827
Done chunking
Allocating ~384 kb of JPEG decompression working area...
Generating 32x32 leaf tiles...
  Done!
Done
This produces an 89mb chuck file. I've been playing around a lot with scale factor, error metric and tree depth. I've had chunk files anywhere from 30mb to 1.3gig off this same data set. One thing I noticed is that Torgue loads the chuck file into the page file when the game starts which seems like a really odd thing to be doing. I wonder if it is because of my view distance being set to 100,000... at any rate the game was using 1.3gig of ram at one point, however it ran smooth after it finally loaded it.

1st questions: I went from 16m input verts to 1m output verts; why?. I was under they impression that the lowest level in the tree would have the same number of verts as the input raw file.

This is a shot of the terrain in game: I've bumped the view and fog distances to 100,000.. It runs smooth on my system but there are some strange things going on.
www.the-gate.net/imghost/textloading.gif
For some reason textures are missing. Perhaps my view distance is insane, the game seems to handle it fine, in fact as far as I can tell it is rendering the geomtry in the black areas (hence the horizon line). The part that really doesn't make sense is why the lone texure out in the distance is loaded and not the one to my right which is far closer.

I've noticed that sometimes I'll move right over a tile and it will be black, if i swing the camera away from the tile (as in looking away from the tile) the texture pops in.


I get about 40 of these:
AtlasActivationHeightfield::generateNodeData - Max exceeded! May have paging issues!
AtlasActivationHeightfield::generateNodeData - Min exceeded! May have paging issues!
AtlasActivationHeightfield::generateNodeData - Min exceeded! May have paging issues!
AtlasActivationHeightfield::generateNodeData - Max exceeded! May have paging issues!
This has something to do with the a chuck's z bound.. What exatly does this mean? what are the paging issues I should be looking for? Solutions to fix the problem? Will this cause my texture problems?

Thanks!
-paul

#1
06/19/2005 (3:57 pm)
One thing to be aware of is that very long view distances tend to make the z-buffer calculations mess up. This is a limitation in the graphics card (things like W-buffers tend to help).

I saw a lot of render artifacts at a 10,000m view distance; I can only imagine that 100km they're significantly worse. The near plane affects this considerably, though - bumping it out a few meters resolves all sorts of problems.

One thing to be aware of is that the way the terrain code is currently configured, it loads in ALL of the low level geometry blocks to allow for collision. This behavior happens in AtlasInstance::onAdd, if memory serves. Depending on your game you may only need to page in collision info for an area around the player(s), which can potentially give VERY strange results if you have physics going on on the edges of the world... Imagine playing GTA, and watching cars drop through the ground or move up and down as collision geometry is paged in or out!

But, all the support and safety checks are in there for paging that stuff in and out. So if you can find a way there that will work for your game, you'll be golden.

A 1.3gb .CHU file is fantastically huge. I've never seen one that large get generated. It might be that your quadtree is too deep and you're just replicating a lot of geometry data?
#2
06/19/2005 (4:36 pm)
All the same settings as before just changed to 10,000 for view dist and fog. changed in game and in the .mis file:

www.the-gate.net/imghost/textloading2.gif
#3
06/19/2005 (4:57 pm)
Do you get anything when you run with D3D in debug mode? (Set from the DirectX control panel.)

What does NVPerfHud/Pix show in terms of used GPU memory?

Any console spam at runtime?
#4
06/19/2005 (9:09 pm)
I got this problem too. it only seems to happen when the texture dimensions are smaller or equal to the terrain's dimensions. it went away when i increased the size.
#5
06/19/2005 (9:18 pm)
I'm using an ATI RADEON 9800 PRO. I downloaded the PIX plugin and gave it a run.
I wasn't 100% sure what data to collect so I loaded up a lot of stuff in the per-frame counter set.

I upgraded to the latest video drivers and checked i have dx9.0c with D3D in debug mode before the test.

This is the PIXRun report file.

There are no errors in the console that seem relevant. mostly complaints about on old style terrainblock missing.
I just renamed your example game folder to atlas and dropped my files in there to run the test.

If this helps..
this is the tqt file 2.4mb
this is the chu file 31.5mb
#6
06/19/2005 (9:45 pm)
Say... If you make the texture bigger than the heightfield, does the problem go away?
#7
06/19/2005 (10:50 pm)
Using an 8192x8192 fixes the problems. 4096 has lots of artifacts on the horizon but not like the 2048 texture. (no tiles are missing)
#8
06/19/2005 (10:53 pm)
Oh and thanks for the help Ben and Michael :)
#9
06/19/2005 (11:12 pm)
Hey, thanks for finding a bug. :) I'll have to look into this one...
#10
06/22/2005 (10:39 am)
Quote:One thing to be aware of is that the way the terrain code is currently configured, it loads in ALL of the low level geometry blocks to allow for collision. This behavior happens in AtlasInstance::onAdd, if memory serves. Depending on your game you may only need to page in collision info for an area around the player(s), which can potentially give VERY strange results if you have physics going on on the edges of the world... Imagine playing GTA, and watching cars drop through the ground or move up and down as collision geometry is paged in or out!

But, all the support and safety checks are in there for paging that stuff in and out. So if you can find a way there that will work for your game, you'll be golden.

Prehaps you can use paging on the client and have the server load the terrain in full. Any sync errors might not be noticable at a distance (You see how quickly the orc disappears).
#11
06/22/2005 (11:12 am)
Actually, I think I do that... I'll have to check up on the code when I next sit down with it. The resource management code I have in there assures that nothing will be loaded twice, so loopbacks don't unnecessarily double memory usage. :)
#12
06/22/2005 (11:27 am)
Well i was thinking in the case of multiplayer with a different server + client.
#13
06/22/2005 (11:35 am)
In that case the dedicated server will have the full hit of the collision, but no texture related hit.

The client, I believe, will collide only against geometry that's fully paged in. But the server will be authoritative so the system can deal with the player hitting unpaged geometry.