This is similar to the radio and a few other audio files having to be pre-cached (that can freeze rendering for an instant the first time they are played) but manifests itself differently: When someone with funstuff that isn't already seen in the game enters the match, only then the game attempts to read the .md3s from the disk. This again can freeze rendering for an instant (shown with blank gaps on lag meter) because of fread()ing the disk at that time. I timed the event of File Reads for md3s at those instances and at points the delay reached 400msec. 400msec is enough to be a very noticeable/irritating freeze (various were up to 50msec which was still noticeable).
According to Timbo, an ioq3 dev, asset loading [and hence disk access] should not be done during gameplay
a blunt workaround on my sig's .exe (similar to a radio audio precaching workaround) attempts to cache all funstuff .md3s each renderer restart (with RE_RegisterModel()), not sure if it works fine yet. edit: it does, it's fine.
All such effects are more apparent on certain systems and usually only after a boot/1st run of the game. OS caching may prevent freezing from happening for the same asset unless one returns from hibernate, waits a lot, etc.
fs_debug can also show directly what is being read for the 1st time.
This post has been edited by mitsubishi: 23 May 2010 - 04:34 PM