Is it a bug? it sure feels like it :)

#1 I did this because I too was very annoyed about the window staying blank for a while. So I basically loaded one png and displayed it, *then* loaded all GUI/sound/materials so the user has something to look at rather than the black box.

I considered delaying the window until everything was ready, but that felt cheap when it could take a while and the user might not be aware if the application is executing or not.

Just random thoughts.

#2 I think that the real problem is that the resource manager loads everything at once rather than loading the just the bits that it needs at a particular time.

#3 I guess thats the big part of it Brian, but is there a reasonable scheme where you can actually tell what NOT to load?

I guess ideally some kind of load on demand handle based system would do it, or a "stand-in" system where it bound a tiny version of whatever texture you wanted and only loaded the full version if you actually request it to be cached.

#4 www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=12068

It hasn't been approved yet, but its what we have been using since October or so, but with various shifts between MS3, MS4, MS4.1.. I never could find time to do a clean patch and post it as a resource, but I've seen a few posts as of late, asking the same thing about loading times..

so hopefully that'll suffice and imho should be a normal part of TGEA now :p

#5 That's pretty cool. Alot more cleaner than mine.

Any chance something like this could be included in TGEA at some point, Brian?

#6 Just as a note, It'd be great if the resource could get approval, so others who may not read or notice this... unless its going into 4.2/4.3.. then well yeh

#7 Yeah, that looks like good stuff, I'll see about getting it in for 1.0.

#8 OK, I've got a more lightweight version of Jeremiah's patch that seems to work pretty well. If I could get some guinea pigs who are seeing the long load times to test this, it would be much appreciated. I got rid of the "preload" flags as only the water needed it and that was a special case, so I had the water code deal with it.

First change is in material.cpp - add this in around line 84:

dynamicCubemap = NULL;
   cubemapName = NULL;

   dMemset( mPath, 0, sizeof(mPath) );  // NEW

   dMemset( animFlags, 0, sizeof( animFlags ) );

replace this code in ::onAdd() (line 186 or so):

SimSet *matSet = getMaterialSet();
   if( matSet )
   {
      matSet->addObject( (SimObject*)this );
   }

   mapMaterial();

   setStageData();

with this:

SimSet *matSet = getMaterialSet();
   if( matSet )
   {
      matSet->addObject( (SimObject*)this );
   }

   // save the current script path for texture lookup later
   const char *curScriptFile = Con::getVariable("Con::File");  // current script file - local materials.cs
   const char *path = dStrrchr( curScriptFile, '/' );
   U32 fileStrLen = path - curScriptFile + 1;
   dStrncpy( mPath, curScriptFile, fileStrLen );
   mPath[fileStrLen] = '[[4fc54b4c3f208]]';

   mapMaterial();

Don't miss the removal of that setStageData() call at the bottom!


Then at the bottom in ::createTexture() (line 474 or so)

replace:

//   const char *curScriptFile = Con::getCurrentFile();  // current script file - local materials.cs
   const char *curScriptFile = Con::getVariable("Con::File");  // current script file - local materials.cs
   const char *path = dStrrchr( curScriptFile, '/' );
   
   U32 fileStrLen = path - curScriptFile + 1;

with:

const char *curScriptFile = mPath;          // mPath is filled in onAdd()
   const char *pathCtr = dStrrchr( curScriptFile, '/' );

   U32 fileStrLen = pathCtr - curScriptFile + 1;

in material.h, add this at line 192:

char mPath[128];

in materialList.cpp, in the ::mapMaterials() function (line 399)

replace:

if(entry && entry->materialName)
      {
         Material *mat = dynamic_cast<Material*>( Sim::findObject( entry->materialName ) );
         if( mat )
         {
            MatInstance * matInst = new MatInstance( *mat );
            mMatInstList[i] = matInst;
         }
         else
         {
            mMatInstList[i] = NULL;
         }
      }

with:

if(entry && entry->materialName)
      {
         Material *mat = dynamic_cast<Material*>( Sim::findObject( entry->materialName ) );
         if( mat )
         {
            mat->setStageData();  // NEW
            MatInstance * matInst = new MatInstance( *mat );
            mMatInstList[i] = matInst;
         }
         else
         {
            mMatInstList[i] = NULL;
         }
      }

Finally, in waterBlock.cpp ::onAdd() (line 69 )

replace:

// Load in various Material definitions
      for( U32 i=0; i<NUM_MAT_TYPES; i++ )
      {
         if( mSurfMatName[i] )
         {
            mMaterial[i] = static_cast<CustomMaterial*>(Sim::findObject( mSurfMatName[i] ));
         }
         if( !mMaterial[i] )
         {
            Con::warnf( "Invalid Material name: %s: for WaterBlock ps2.0+ surface", mSurfMatName[i] );
         }
      }

with:

// Load in various Material definitions
      for( U32 i=0; i<NUM_MAT_TYPES; i++ )
      {
         if( mSurfMatName[i] )
         {
            mMaterial[i] = static_cast<CustomMaterial*>(Sim::findObject( mSurfMatName[i] ));
            mMaterial[i]->setStageData();  // NEW
         }
         if( !mMaterial[i] )
         {
            Con::warnf( "Invalid Material name: %s: for WaterBlock ps2.0+ surface", mSurfMatName[i] );
         }
      }

#9 That's a long post, if you would rather just have me email you the related files, it's no problem.

#10 Looks good. I had added the preload mainly for specific things that people might've wanted to load, that weren't being handled by MaterialList, but were still shaderized...

I guess that can be handled per class, depending on what it is.. It all looks good and I'll retouch up what I have with yours and see how we run with it :)

#11 Just tested it.... it is significantly faster and seems to work right. Before our startup was like ~30 seconds... after it is ~11 seconds. Still 11 seconds seems like a pretty long startup delay to just bring up the main menu... but great fix... get that in HEAD!

#12 Removing the CustomMaterial preloading (minus Water) should've definately helped load times. I'm looking at doing a similiar system with purging materials when they are no longer used, which will help some of our client base who may have lower end machines that aren't quite packed on memory or video memory

#13 Ah just noticed your changes in createTexture don't need to be there. You're doing a redundant operation, as you're already handling the file path/filename in onAdd, so all you need to do in create texture is pass it on

#14 Thanks for testing guys.

@Jeremiah, yeah, I think I have that removed in my code, just forgot to post the removal of it. Will double check on Monday.

@Tom - hmm, still 11 seconds, dang yeah that is long. Do you know where that time is going? It may be a general resource thing and not a Material/texture/shader thing.

#15 I just wanted to confirm that we are experiencing the same load times in our build. However the load time is at least 1 minute or more with just a black screen. We have quite a bit of materials defined, so I assume that is part of the issue. Hopefully those changes above will help our problem because this seriously hinders productivity when it takes 2 minutes to test one little thing.

#16 SRO,

The above just moves the loading elsewhere. You won't get into your mission faster, the application will just "boot up" faster so that you can show any eventual GUI's and what you have.

#17 Maybe having a material cache is the way to go?

#18 With this code, youll have to add in Special cases for Atlas materials too. As I posted in the TGEA MS 4.2 thread, that there will be severe flickering of Atlas Terrain due to materials not being setup properly.

#19 @Jeremiah - yeah that code was actually redundant, so I cleaned that up. I also added the "preload" back in to deal with Atlas rather than change it in code - was a one line thing for WaterBlock, but Atlas is more involved. Besides, I do like having the option available for other things like special effects.

@SRO - you might want to try and find out where that time is going. It it's mostly just compiling all the Materials, you should try turning .dso's back on and see if that helps.