J. Donavan Stanley - TerrainManager question..

#1 I dont have the answer on your question.
I have a another question instead :)

I am trying to create a paging system with the TM, but i have a huge problem to render the new terraintile. It seems to remove and add the collisiontree, but doesnt render the tile after i loaded/unloaded the tile in the TM. I wonder if there are anyone who have succeeded in doing this?

#2 Brett,

I can add that to my list of things to look into. I think I'll block out some time this week for TM work and try and see if I can knock some of these weirdisms out.

#3 Thanks Donavan! It is much appreciated.. if I happen to run across it in the meantime, I'll post my findings here.

Fredrik,

It's not something that I'm interested in using in my game, but none the less an important feature (I think) for TGE and TM. I'll see what I can dig up on it too!

- Brett

#4 Okay, here's the deal... It appears that when it's trying to decide if an object should be shadowed, it's finding the TerrainManager. It cycles through the local objects in sceneObject.h:

inline void Container::findObjects(U32 mask, FindCallback callback, void *key)
{
   for (Link* itr = mStart.next; itr != &mEnd; itr = itr->next) {
      SceneObject* ptr = static_cast<SceneObject*>(itr);
      if ((ptr->getType() & mask) != 0 && !ptr->mCollisionCount)
         (*callback)(ptr,key);
   }
}

The code is called from within shadow.cc in the function Shadow::prepare

buildPartition(pos,lightDir,radius,shadowLen);

It's finding the TerrainManager, but it isn't generating any polys. By the way, the type for the Manager is 67108869 so you can find it in the iterator. I'm assuming this is because the TerrainManager itself doesn't contain any polys... So, maybe it needs to be modified to locate the TerrainBlocks within the TerrainManager??

I was looking at the code and believe that inside the callback (Shadow::collisionCallback) it should instead locate the terrain block the player is currently in (or do a sub loop on all terrain blocks) and subsitute the TerrainBlock pointer for the object pointer: (pseudo-code)

void Shadow::collisionCallback(SceneObject * obj, void* thisPtr)
{
   Shadow * shadow = reinterpret_cast<Shadow*>(thisPtr);
   
   // Returning the TerrainManager, should prolly get the TerrainBlocks
   // within to build the poly list
   if (obj is TerrainManager) {
	  // Get the current terrain block we're in instead
          obj = CurrentTerrainBlock;
   }
   
   if (obj->getWorldBox().isOverlapped(gShadowBox))
      obj->buildPolyList(&smDepthSortList,gShadowBox,gShadowSphere);
}

Also, I doubt people will find this in here, but here's a useful piece of code:

In shadow.cc change:

U32 Shadow::smShadowMask = TerrainObjectType | InteriorObjectType;

to read:

U32 Shadow::smShadowMask = TerrainObjectType | InteriorObjectType | StaticRenderedObjectType;

Voila! Shadows on static objects... :-)

- Brett

#5 Very nice Brett I'll add that to the patch ASAP.

#6 I'm working on this today... I've got to do some SWIG work on the Win32 side first since I can't currently link my copy of the engine under Win32.

Hopefully I'll get shadows working and fix that stupid texture painting bug.

#7 J. Donavan,

As long as you are looking at terrain textures you might want to close this bug in the terrain manager...

http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=2004

I actually patched this fix into a previous release of terrain manager and gave the code to Bryan to be added in, but it slipped thru the cracks. I'll see if I can find the old post.

I'm sure that the fix would not go in exactly as I wrote it - there have been too many changes to TM for that, but it should point out where the fix goes and roughly what it looks like.

#8 Found the old post. The code is about half way down.

http://www.garagegames.com/index.php?sec=mg&mod=forums&page=result.thread&qt=4474

#9 I'll add that to my list as well. Dealing with SWIG under Win32 combined with my having imported some files into CVS improperly has taken up most of the day today.

Corrupted font files are NASTY. Caused my exe to consume 300+MB of RAM in no time flat before I killed the app.

#10 On the shadow issue:

It appears as though the problem lies with the ObjBox and by extension the WorldBox for the terainBlocks being initialized to 0,0,0,0,0,0 and never getting set. I have a sneaky suspicion this also ties in with the problems reported for TerrainManager and vechicles.

In the old terrData.cc this gets set in onAdd to a huge number (-1e8,-1e8,-1e8,1e8,1e8,1e8). I don't think I can do the same in TerrainManager, I think doing that would cause Shadows to appear on every block... I'll do some more digging.

Tomorrow should show more progress now that I've gotten my Win32 build stable.

#11 I'm really begining to hate this code.

TerrainManager now has a buildPolyList function that defers to the terrain blocks, which fails the Z test every time. So still no shadows.

I think there's something seriously wrong with the findSquare logic but I can't find it. This borks up a lot of things, like terrain painting for example. You can see the materials pop and shift depending on what LOD setting is being used.

The only thing I've managed to accomplish other than giving myself a headache is to fix a crash bug in TerrRender: Around line 1765 there's an "if !mTerrainManager" check that shouldn't be there. This causes the blowups if you exit a mission and load a new one. Just set mTerrManager everytime to fix it.

I SHOULD have just finished this back when I was working with it on a daily basis. I'm having trouble getting back into the TM mindset.

#12 Well, I for one appreciate your efforts and will try to contribute where I can.. Thanks again!

- Brett

#13 I am a bit curious about how the engine and TM is tied to each other. I am trying to page a bit, and i have succeeded to remove one block without getting any NULL POINTER exception, but no rerender is taking place.

#14 TM acts as a replacement/proxy for terrain blocks. Anything that deals with terrain passes through TM which determines which block should get the request. Individual blocks refer back up to TM for some functions (anything that deals with grid squares for example).

To implement paging you're going to need to modify the behavior of TM depending on wether you're a client or server. Your server is going to want to have all blocks resident in memory (Or least I'd think it would). On the client side, you're going to want to keep all visisble, or soon to be visible blocks in memory. If I were doing it I think I'd put together a container class that proxied terrainBlocks and knew how to load/unload them, then have TM deal with the new class instead of terrain blocks directly.

The paging in and out of terrain is only part of the battle. In order to make this worthwhile you're going to need a way to keep track of shapes, interiors and the like by terrain block (maybe stuff them into SimSets based on terrainblock?). Then you're going to make sure the server doesn't send information of items that the client has unloaded, plus sends sync's the client up as it loads up blocks.

#15 What a difference a night of sleep can make.... I reimplemented buildPolyList as a TM function instead of delegating to the blocks themselves to do it and I now get *some* shadows, I still get assertions saying "no plane possible" occasaionaly so I need to track that down.

I also fixed some of the grid functions so that the texture "popping" problem appears to be fixed.

I forgot to mention this yesterday but I finally hooked up and tested the saveTerrain function so there's no need for script based function anymore.

Progress is a good thing. :)

#16 Yes. I understand the complexity with paging. But the first step should be to page terrain tiles.

#17 I've just uploaded the latest version of TerrainManager to my website. It'll be up on gorpe.com later but I'd like for some folks to try this pacth out and make sure I didn't miss anything. Click here to download it.



@Fredrik I wasn't sure exactly what you were asking so I figured a shotgun approach might be helpful. ;)

#18 Did you do this diff in the unified format?? It doesn't work when trying to apply the patch.


- Brett

#19 Manually applied the patch and shadows appear to be working now.. :-) YAY

- Brett

#20 Hmmm I'll rebuld the patch. I thought I'd done unified but I could be wrong.