TGEA 1.7.0 Beta 1 Bug - Crash in tiled texture import

Importing of textures tiles for Atlas terrains may crash (console function atlasGenerateTextureTOCFromTiles). In release builds, you will get something like "Invalid stub" and in debug builds that include mem debugging, you'll see something like "Not an allocated block." The console log will show something like "... processing row 0..."

The reason is that atlasImportTiles.cpp improperly sets up its AtlasTexChunks. To fix this, replace the following in atlasImportTiles.cpp@89:

// Create a chunk to store this data in.
         AtlasTexChunk *atc = new AtlasTexChunk;
         atc->mFormat = (AtlasTexChunk::TexFormat)outFormat;
         atc->bitmap = *bmp;

with this code:

// Create a chunk to store this data in.
         AtlasTexChunk *atc = new AtlasTexChunk;
         atc->mFormat = (AtlasTexChunk::TexFormat)outFormat;
         atc->bitmap = new GBitmap[ 1 ];
	 atc->bitmap[ 0 ] = *bmp;
	 SAFE_FREE( bmp );
	 atc->layerCount = 1;

However, after applying this fix you will notice that it still crashes further down the line when trying to copy the texture TOC. This is because when copying the TOC, bitmap data is not duplicated and subsequently gets freed twice later on. So, to get done with this issue, replace the following in atlasTexChunk.cpp@251:

atc->bitmap[layer] = bitmap[layer];

with:

constructInPlace< GBitmap >( &atc->bitmap[layer], &bitmap[ layer ] );

You can do the same with the copying code for DDS files a few lines down in the same file, but DDSFile has no copy constructor. I am pretty sure, this is a bug as well and will cause the same problem when using DDS files.

And then, after spending hours (as I am completely new to Torque) tracking down and fixing these bugs and finally succeeding in generating an Atlas terrain, TGEA will then deadlock on loading the terrain. Looks like another round of bug hunting. Sigh...

-----------------------------
To finish this off: In order to solve the deadlock, reactivate the code that has been commented out in AtlasClipMapImageSource::isDataAvailable. What has been commented out there actually triggers load requests on unloaded data; without this, the loader code will wait forever for the data to get loaded.

So, the full code for the method in atlasClipMapImageSource.cpp@106 reads:

bool AtlasClipMapImageSource::isDataAvailable( const U32 mipLevel, const RectI inRegion )
{
   // We need to convert from a mip level to a level in our TOC, potentially scaling.
   U32 baseMips = getBinLog2(mTOC->getTextureChunkSize());
   U32 tocLevel = -1;
   if(mipLevel >= baseMips)
   {
      // In an inner or leaf tile.
      tocLevel = mipLevel - baseMips;
   }
   else
   {
      // It's in our base tile.
      tocLevel = 0;
   }
   
   // We don't scale beyond the depth of the TOC, so simply assert in that
   // case.
   AssertFatal(tocLevel < mTOC->getTreeDepth(), "AtlasClipMapImageSource::isDataAvailable - went beyond depth of tree.");

   // Check all the chunks of all the stubs in the appropriate region...
   RectI r;
   convertToTOCRect(tocLevel, inRegion, r);

   const S32 xStart = mClamp(r.point.x,               0, BIT(tocLevel));
   const S32 xEnd   = mClamp(r.point.x + r.extent.x,  0, BIT(tocLevel));

   const S32 yStart = mClamp(r.point.y,               0, BIT(tocLevel));
   const S32 yEnd   = mClamp(r.point.y + r.extent.y,  0, BIT(tocLevel));

   bool haveData = true;

   for(S32 x=xStart; x<xEnd; x++)
   {
      for(S32 y=yStart; y<yEnd; y++)
      {
         AtlasResourceTexStub *arts = mTOC->getResourceStub(mTOC->getStub(tocLevel, Point2I(x,y)));

         if(!arts->hasResource())
         {
            Con::printf("   - data unavailable for getStub(%d, (%d, %d)) %d", 
            tocLevel, x, y, mipLevel);

            mTOC->requestLoad(mTOC->getStub(tocLevel, Point2I(x,y)), AtlasTOC::NormalPriority,
                  F32(tocLevel) / F32(mTOC->getTreeDepth() + 1));

            haveData = false; 
         }

      }
   }

   return haveData;
}