MAINT-4297 (Mesh models sometimes fail to load completely)

MAINT-4449 (Starter avatars deformed or missing alpha under some conditions / graphics cards / LOD )
BUG-7239 (Starter avatars deformed or missing alpha under some conditions / graphics cards / LOD)

The reason of problem on avatar (or one of avatar attachments) "deformed" it's selected volume (LLVolume) with a lower LOD.
How it works. Why it happens?

Each LLVOVolume object has variable mLOD which is indicate which is LLVolume should be assigned to LLPrimitive::mVolumep.

The assigment happens in LLVOVolume::setVolume which is call LLPrimitive::setVolume, which is then lookup desired volume in LLVolumeMgr class which is keep as I understand all volume groups for all objects in scene.

The data (mesh) for LLVolume class is loading from LL servers by http, and if sucessfully the variable LLVolume::mIsMeshAssetLoaded assigned to true.

But sometimes the data may not be ready, and in this case the LLVOVolume::setVolume make request for download mesh (to the LLMeshRepository) and setup one of available lod. All of this things happens in (see:
LLVOVolume::setVolume, code: block if (!getVolume()->isMeshAssetLoaded() {...})

When LLMeshRepository sucessfully download the mesh it's set (as I said above LLVolume::mIsMeshAssetLoaded, LLVolume::setMeshAssetLoaded()) and then also notify LLVOVolume::notifyMeshLoaded() about it.
This causes add LLVOVolume::mDrawable into the pipline build list (see LLVOVolume::notifyMeshLoaded()) and set LLVOVolume::mSculptChanged;

In order to process it later in LLVOVolume::updateGeometry (In order to see the mechanism of LLPipiline build list processing set bp in this method and see the stack).
After the LLDrawable will be processed it will be removed form the build queue also all falgs will be reseted (see the end of LLVOVolume::updateGeometry).

And here is the problem in variable-flag's "*Changed" processing (in LLVOVolume::updateGeometry):
What if by the time of processing the mFaceMappingChanged also will be set (due to other changes in engine)?
It means that LLVOVolume::setVolume will not be called and LLPrimitive::mVolumep remain unchaged and would point to the LLVolume for a lower LOD.

My changes intended for fix this problem.

BTW this is true for not only for standard avatar's. The reason why it is well visible on standard avatars is because it has a more "ugly" lower-LOD-s, than on avatars which is was loaded by the SL-users.
For example on my DudtPank avatars I didn't see big difference between LOD-0 and LOD-3.
If you want you can "play" with it in LLVOVolume::calcLOD() with add code if(getAvatar() && getAvatar()->isSelf()) { mLOD = <desired lod level [0..3]> }

0 files changed, 0 insertions, 0 deletions