MS4 Atlas Unique Terrain Bug.

#1 Hmm, I don't know off hand. Which .atlas file are you counting size on? You should have generated three - a geometry one, a texture one, and a combined one with data from both.

Are there any comments in the console.log?

With the new Alas rendering system, 1k px tiles are not going to be a very good idea. You might want to consider going down to 256px tile sizes, as that will page nice and smoothly.

#2 I just posted about this and its very similiar issues, actually that crash is exact.. but we were having some other oddities

#3

atlasOldGenerateChunkFileFromRaw16("tool.htc/data/terrains/level_one.raw", 2048, 2.0, 1.0, "tool.htc/data/terrains/geometry.chu", 1.2, [B]4[/B]);
atlasGenerateTextureTOCFromLargeJPEG("tool.htc/data/terrains/level_one.jpg", [B]4[/B], "tool.htc/data/terrains/texture.atlas") ;

The error above is solved by setting equal bolded numbers (tree depth) with atlasOldGenerateChunkFileFromRaw16 AND atlasGenerateTextureTOCFromLargeJPEG.

@Ben :
RAW File Size : 8201 Kb (2048x2048)
JPEG File Size : 1172 Kb (2048x2048)
CHU File Size : 13239 Kb (RAW->CHU : +61 %)
Geometry Atlas File Size : 33 955 Kb (CHU->atlas : +156%)
Texture Atlas File Size : 8809 kb (JPG->atlas : +651 %)
Final Atlas File Size : 42764 kb (RAW+JPG->final atlas : +356 % !!!!)

(Terrain setted with tree depth of 4, less makes crash, bigger makes bigger files)

Wow you really need Atlas Strength to carry this heavy terrain file !

#4 But isn't it amazing how these HUGE files load in almost zero time? My terrains are loading faster than the progress meter can keep up!

#5 I am having the same problem, however my Height atlas and Texture atlas both have the same LOD. Compiling works fine, but when you go to load the terrain it gets to phase 2 of the misson loading screen then crashes. Everything works fine with our 3.5 build.

Here is a video of the compile and crash it was encoded in the Xvid codec...

www.renwerx.com/Ms4BrokenAtlas.avi

Dont know if it helps at all or not.

#6 Anyone have any thoughts on what would be causing this? I made another terrain last night and it was having the same problem when trying to load.

#7 It might or might not be related, but I've found a bug in the atlas importers that is verified with Ben outside the forums. He is going to update the code soon + rewrite a section of code that is troublesome.

In the atlas/editor/atlasoldmesher.cpp, there is a place where an initialization is done using F32_MIN, F32_MIN, F32_MIN and F32_MAX, F32_MAX, F32_MAX - around line 125:

Change this

// Reset our bounds!
   mBounds.min.set(F32_MAX, F32_MAX, F32_MAX);
   mBounds.max.set(F32_MIN, F32_MIN, F32_MIN);

to this

// Reset our bounds!
   mBounds.min.set(F32_MAX, F32_MAX, F32_MAX);
   mBounds.max.set(-F32_MAX, -F32_MAX, -F32_MAX);

F32_MIN is as close to 0 as possible and not the most minimal negative value, and you will get weird errors with your terrain if imported using the old code - including the getStub problem. If you converted using a release build, you might never have seen these problems.

There are tons of asserts failing checks if you try to convert/import the terrain files using a debug build. Something about "bad child quadtree node min/max! (negative a)" or "AtlasOldMesher::writeCollision - empty bin, crap!". If you change the above to -F32_MAX, all these errors go away.

The issue is related to typically very flat terrains. Try adding some small variations and also try to play with the error value. Set it low - very low. Conversion will run slower and generate larger files, but will eliminate your problems. I'm using values around 0.1-0.2 on my flat terrain.

I have not had a single problem with terrains after this fix - and prior to that I spend 2 days without getting terrain to run at all (in debug builds for both conversion and running the terrain).

#8 I have the same problem and I know what is causing it but I do not know how to fix it. This only happens when your leaf tiles are larger than 256px. Try using a larger tree depth so that your tiles become 256 x 256.

#9 This seems to have fixed some of our crashes, but now its crashing elsewhere...

virtual void requestLoad(StubType *stub, U32 reason, F32 priority)
   {
      ResourceTOCType::StubType *s = getResourceStub(stub);
      s->mRequests.request(this, priority, reason);

      // Notify the resource TOC so it can queue/unqueue it for load.
      mResourceTOC->requestLoad(s, reason, priority);
   }

It seems at the time that s->mRequests.request(this, priority, reason); is crashing for us now. It looks like mRequests is null/invalid, but since some of this is multithreaded, to some extent, it is hard to say if it trully is.

Debugger stops in AtlasRequestHeader::request, but "this" is invalid/null at that point in time, which would mean it is infact invalid and is causing the crash


edit: Upon further looking, we're still getting the index out of bounds error, so maybe it is tree depth and I will check with my level guy about it

#10 Message from Ben (when I had the errors) was - use a high tree depth (like 5 or 6) and very low error tolerance (0.1-0.2).

#11 Im still getting the error what is the best way of going about debugging this. I cranked my chunk size up to 6 and my error matrix down to 0.6 (lowest it would go without moaning about to many poly's per chunk) but its still crashing...

#12 Temporary fix for this issue can be found here www.garagegames.com/mg/forums/result.thread.php?qt=50678 problem #2

#13 When I set the LOD above 4 I get the following error
AtlasGeomChunk::generateCollison - Bad child quadtree node min/max! (negitive a) engine\atlas\resource\atlasGeomChunk.cpp @ 767
happens in the conversion from chu to .atlas
This is the last lines of the console before it dies.

ImportOldAtlasCHU("base/Data/Terrains/AnarTempera_HeightMap.chu","base/Data/Terrains/AnarTempera_HeightMap.atlas");  
importOldAtlasCHU - opened 'base/Data/Terrains/AnarTempera_HeightMap.chu' for conversion.  
AtlasDeferredFile::ensureStreamWritable - switching file into writable mode... This may cause a crash if you have other copies of Torque accessing it!  
importOldAtlasCHU - created new Atlas file 'base/Data/Terrains/AnarTempera_HeightMap.atlas'  
importOldAtlasCHU - Atlas file initialized, converting...  
importOldAtlasCHU - Headers read, remapping chunks...  
importOldAtlasCHU - Importing geometry chunks...  
importOldAtlasCHU -    level 4 chunks...

If its set to 4 or below I get the index error I posted above when its loading phase 2 of the mission.

#14 I fixed the bug,

in engine/atlas/core/atlasbasetoc.h @217 Change

AssertFatal(nodeID < mStubCount, "AtlasBaseTOC::getStub - index out of bounds!");

to

AssertFatal(nodeID <= mStubCount, "AtlasBaseTOC::getStub - index out of bounds!");

I also used the fix outlined in the link above my post but it had no effect until I also changed the line outlined in the code block above.

That fix was:

in C:\Torque\TSEms4\tse\engine\atlas\runtime\atlasClipMapUniqueCache.cpp line 116

Change this

 for(S32 i = mAitToc->getTreeDepth()-1; i >= mLevelOffset; i--)


to this 

for(S32 i = mAitToc->getTreeDepth()-1; i > mLevelOffset; i--)

#15 Right.. I put this in as a bug in the bugs thread.. the reason why it crashed is because the call to getStub was expecting an U32, it was in fact using that for loop, which you'll notice is a S32...

The math for the for loop was allowing the i value to go -ve, which when cast to U32 becomes massively positive and asserting in getStub.