Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
more persistent, tolerant to race conditions during initialization
|
|
|
|
triangle count
|
|
|
|
the selected texture.
|
|
|
|
|
|
|
|
|
|
LLControlAvatar::initInstance() as a potential hook for optimizations.
|
|
|
|
their attachments render at 0 LoD to prevent loading higher LoD complexity in memory thus deterring crashes.
Stability improve.
|
|
must contain some triangles even if not at the root
|
|
|
|
|
|
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.
|
|
handle notification of same to update control avatars on notification from elsewhere.
|
|
some triangle information that we may or may not ultimately keep. Surface area calcs still not working
|
|
always the high LOD
|
|
limits that are also enforced on the server.
|
|
|
|
|
|
animation state.
|
|
operations take place
|
|
|
|
functionality. Currently this is just one bit to flag an object as able to animate
|
|
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]> }
|