| Age | Commit message (Collapse) | Author |
|---|
|
|
|
the selected texture.
|
|
|
|
|
|
their attachments render at 0 LoD to prevent loading higher LoD complexity in memory thus deterring crashes.
Stability improve.
|
|
|
|
Originally a fix for MAINT-4773. This was causing a number of issues since
changes made in this code were pushing null textures into server and viewer
should not modify 'content' at server of own violition.
|
|
worn legacy prims, sculpts and non-rigged mesh.
FIXED.
Remark: for Linux platform, for the best times, when we will use gcc > 4.6, otherwise ICE :-(
|
|
their attachments render at 0 LoD to prevent loading higher LoD complexity in memory thus deterring crashes.
Fix for Linux build.
|
|
their attachments render at 0 LoD to prevent loading higher LoD complexity in memory thus deterring crashes.
Comments:
- Fix based on "RenderAutoMuteByteLimit" setting.
- File indra/llxml/llcontrol.h - add all signals to 0 group.
It garanty that handlers (in indra/newview/llviewercontrol.cpp) will be called last.
|
|
|
|
|
|
|
|
Reverting MAINT-6259
|
|
Reverting MAINT-6793
|
|
|
|
|
|
|
|
|
|
|
|
Need backed out this changes because it influence on material
update see: MAINT-5818
Also this lead to the following:
UserA and UserB logged in same location.
UserA edit normal/specular map texture offsets while UserB is not observe this
changes.
|
|
|
|
--HG--
branch : maint-5416
|
|
|
|
|
|
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]> }
|
|
specular maps still randomly revert to previous settings when building.
|
|
This bug fix related also to MAINT-4092. In 4092 sometimes when we
don't have information about the texture during the setup the materail
(LLVOVolume::setTEMaterialParams()), we should substitute the material with
disabled "diffuse alpha mode" (for detail in cases see MAINT-4092 JIRA ticket
comment).
This bug fix cover the case when after the loading texture we have all
information about alpha mode, and in this case we should restore diffuse
alpha mode if need.
In short: now we always believe that information about the material is valid
(LLVOVolume::setTEMaterialParams()).
Of course before setup it we check information about texture (if it possible)
, if texture is not exist in database or not 32 bit depth (for diffuse) we
made changes.
But in all other cases (if we can't receive information about texture)
we remeber this case in mWaitingTextureInfo multimap.
When information about texture will be available we get it in:
LLVOVolume::notify AboutCreatingTexture()
or
Volume::notifyAboutMissingAsset()
and again, we recheck it and if need change (substitute)
the material parameters.
I suppose that this solution is better than was before.
If this patch will be accepted
, I think that MAINT-4092 should be rechecked again.
|
|
calculator instead of binormal calculator, convert binormal centric code to tangent centric)
|
|
|
|
channels and make the materials CB use a UUID instead of this pointer for safety
|
|
|
|
|
|
|
|
|
|
brundlefly solution with old reg and new callback
|
|
applied materials
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reviewed by me. (Bao created)
|
|
|
|
|
|
|
|
queues.
|
|
|
