| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
The convention about how to construct an HttpHeaders::ptr_t has changed.
Change new code to adapt to merged changes.
|
|
|
|
Specifically, change the ptr_t typedefs for these LLCore classes to use
IntrusivePtr rather than directly using boost::intrusive_ptr. This allows us
to use a simple ptr_t(raw ptr) constructor rather than having to remember to
code ptr_t(raw ptr, false) everywhere. In fact, the latter form is now invalid:
remove the now-extraneous 'false' constructor parameters.
|
|
For a RefCounted subclass T, boost::intrusive_ptr<T> must be instantiated as
boost::intrusive_ptr<T>(raw ptr, false) to avoid immortal instances.
Forgetting that final bool parameter is both easy and extremely hard to spot
with desk checking or code review. IntrusivePtr<T> provides constructors that
Do The Right Thing, so we can typedef a subclass T's ptr_t to IntrusivePtr<T>
rather than directly to boost::intrusive_ptr<T>.
|
|
|
|
This allows engaging slshare-service debug logging for a particular viewer
session without having to twiddle the slshare-service hosts.
Also fix leaky LLCore::HttpHeaders::ptr_t construction.
|
|
|
|
clang doesn't like finding HttpCoroutineAdapter::postFileAndYield(...) inside
the class definition for HttpCoroutineAdapter. It's much happier with plain
postFileAndYield(...).
|
|
|
|
|
|
|
|
|
|
|
|
only 254
|
|
are selected.
|
|
|
|
|
|
|
|
|
|
favorite login locations
|
|
|
|
|
|
didn't catch it.
|
|
The default behavior in the HTTP layer changed to follow redirects automatically.
This was causing a problem with connecting to the SL share service which was attempting to
riderect to the login page at the CURL level. Connections to SL Share will no longer redirect,
corrected for Facebook, Flickr and Twitter.
|
|
|
|
|
|
|
|
incorrect Units)
MAINT-5208 FIXED (Grid Lines Changing Scale Depending on Distance from Camera)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
the previous DD-416 commit
|
|
a group member list is loading.
|
|
|
|
sender name
|
|
before we get data from SLM
|
|
some functions avoiding depth computation when we could, fixed cut case
|
|
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]> }
|
