Skip to content
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.

[BUG-7433] Change in Maintenance Viewer breaks my joint rigged mesh avatar #15147

Open
5 tasks
sl-service-account opened this issue Oct 2, 2014 · 77 comments
Open
5 tasks

Comments

@sl-service-account
Copy link

sl-service-account commented Oct 2, 2014

Steps to Reproduce

logging in world on the Second Life Maintenance Viewer version 3.7.17.294943

Actual Behavior

i logged into Second Life to find my avatar deformed (stretched) out of shape. My new mesh avatar uses Joint rigging to achieve certain shoulder positioning. This thing i find odd, is other avatars that use joint rigging to achieve smaller size seem to appear fine.

I'm worried this is an issue with the way i have rigged my avatar and there for lead to having to scrap my avatar if this change in the maintenance viewer progresses to the main viewer.

Expected Behavior

I was expecting my mesh avatar to appear the same as on the main Second Life version 3.7.16.294015. I have attached two pics showing the difference.

Other information

Attachments

Links

Related

Original Jira Fields
Field Value
Issue BUG-7433
Summary Change in Maintenance Viewer breaks my joint rigged mesh avatar
Type Bug
Priority Unset
Status Accepted
Resolution Accepted
Reporter Loki Eliot (loki.eliot)
Created at 2014-10-02T11:48:31Z
Updated at 2015-02-26T03:28:45Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2014-10-02T08:31:52.237-0500',
  'Severity': 'Unset',
  'System': 'SL Viewer',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': "i logged into Second Life to find my avatar deformed (stretched) out of shape. My new mesh avatar uses Joint rigging to achieve certain shoulder positioning. This thing i find odd, is other avatars that use joint rigging to achieve smaller size seem to appear fine. \r\n\r\nI'm worried this is an issue with the way i have rigged my avatar and there for lead to having to scrap my avatar if this change in the maintenance viewer progresses to the main viewer.",
  'What were you doing when it happened?': 'logging in world on the Second Life Maintenance Viewer version 3.7.17.294943',
  'What were you expecting to happen instead?': 'I was expecting my mesh avatar to appear the same as on the main Second Life version 3.7.16.294015. I have attached two pics showing the difference.',
}
@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2014-10-02T13:31:52Z

Are you seeing https://jira.secondlife.com/browse/BUG-3416 ?

@sl-service-account
Copy link
Author

Maestro Linden commented at 2014-10-02T17:36:20Z, updated at 2014-10-02T18:06:32Z

Hi Loki, could you send Marissa Linden, Vir Linden and myself a copy of this avatar, so we can attempt to reproduce the issue? Alternatively, if you don't have the ability to transfer it, can you describe where it is in your inventory?

@sl-service-account
Copy link
Author

Loki Eliot commented at 2014-10-02T18:12:48Z

Ok Setting one up now, should arrive in the next 15 minutes

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-10-02T21:10:15Z, updated at 2014-10-02T21:12:26Z

Please see BUG-7436
I think BUG-7436 is likely to be a dupe of this issue but I wasn't sure so filed a new issue with a repro.

Not sure but I think this issue may be a regression of BUG-6304

@sl-service-account
Copy link
Author

Maestro Linden commented at 2014-10-02T21:43:19Z

Thanks, I've tried the meshes on, and have attached some screenshots:

  • "maestro BUG-7433 294015 release.png" is what I see on the 294015 release viewer, after replacing my normal avatar with the two meshes

  • "maestro BUG-7433 294943 DRTVWR-380 at login.png" is after logging out from the release viewer, then logging in with the 294943 viewer (where I logged in with your meshes worn)

  • "maestro BUG-7433 294943 DRTVWR-380 fresh outfit replace.png" was also from viewer 294943. In this case, I switched to my normal avatar, then replaced my outfit with your two meshes

    The images look pretty similar to me - nothing like your stretched.png. I wonder if this bug depends on having a certain avatar shape?

@sl-service-account
Copy link
Author

Loki Eliot commented at 2014-10-02T21:52:04Z

I shall send you my shape as well

@sl-service-account
Copy link
Author

Maestro Linden commented at 2014-10-02T21:52:41Z

Actually, do you see the stretched appearance in 294943 if you don't have any other attachments on (and then relog), as in my screenshots?

@sl-service-account
Copy link
Author

Maestro Linden commented at 2014-10-02T21:57:44Z

Whirly, you know what, I was just observing myself on the Maint RC. I guess I should have a 2nd avatar on the same build observe me in that case.

@sl-service-account
Copy link
Author

Vir Linden commented at 2014-10-02T22:22:37Z

If any other meshes worn by the original avatar have rigging information (that is, if they deform with character motion), they could also be affecting the joints on the character. Could the gloves or boots be rigged?

@sl-service-account
Copy link
Author

Loki Eliot commented at 2014-10-02T22:23:11Z, updated at 2014-10-02T22:26:40Z

Tried with no other attachments, still get the same strechyness, So no other rigged attachment is causing the issue. is it cos i is Mac? anyway made a video to show my issue. http://telly.com/1N83DKA

@sl-service-account
Copy link
Author

Loki Eliot commented at 2014-10-02T22:54:39Z

Im adding the is side by side comparison. Running both Main release & Maintenance viewers side by side. Im in black shorts on Maintenance, victor in blue on Main Viewer. We are both wearing just the Joint Rigged Mesh Body and simply rigged shorts.

@sl-service-account
Copy link
Author

Maestro Linden commented at 2014-10-02T23:51:58Z, updated at 2014-10-02T23:52:44Z

Loki gave me a shape named "Loki MeshBody Pro - 5.9"", and I see a pronounced difference when wearing it with the mesh body and shorts. The avatar is noticeably more 'stretched' in the maintenance viewer.

The attached "maestro BUG-7433 compare with loki shape.png" compares the appearance of the agent in the 3.7.16 (294015) release viewer (right side) with the 3.7.17 (294943) maintenance RC viewer (left side). It basically matches the results in Loki's latest side-by-side attachment.

Both viewers in this screen shot were observing a 3rd party avatar, but I see a similar view when viewing myself with this outfit set, in both viewer versions.

@sl-service-account
Copy link
Author

Maestro Linden commented at 2014-10-02T23:56:26Z

I see the same body shapes in each viewer version when I wear Loki's shape but don't wear the shorts (even after a relog with this outfit).

@sl-service-account
Copy link
Author

Maestro Linden commented at 2014-10-03T00:17:10Z

The 'stretching' is almost certainly related to the fix for BUG-6197, which is in the maintenance viewer. It's possible that the mesh has some 'ugly' joint offsets which only became apparent with the fix, but we need to investigate further.

@sl-service-account
Copy link
Author

Loki Eliot commented at 2014-10-03T00:34:16Z, updated at 2014-10-03T00:44:18Z

It is quite possible that my joint rigged mesh avatar skeleton is NOT traditional, it might even be missing a joint or two.

To try and get a better shape for my child like appearance I went for shrinking an adult skeleton down. I then adjusted the shoulder joints to compensate for the slimmer arms and higher shoulders. I also removed the eye joints to avoid bug eye syndrome. It's also using 'partial' fitted mesh, because it's bloody hard to add full fitted mesh to a custom avatar mesh. So perhaps one of these innovations (ugly joint offsets) is not compatable with the 6197 Fix? .

I shall do some investigations of my own after I've slept, specifically the eye joints and fitted mesh.

@sl-service-account
Copy link
Author

Loki Eliot commented at 2014-10-03T15:32:47Z, updated at 2014-10-03T15:45:15Z

OK i deleted my previous comments because i thought i had fixed the issue myself. I've been experimenting all day messing with the armatures and bones. I reintroduced eye bones and this seemed to fix the issue. Unfortunately when relogging still causes the avatar to stretch to an Undeformed state. I can almost correct this by detaching and reattaching the mesh avatar, but i found that my feets ankles would become angular. But then sometimes it loads and deforms correctly, its all being a bit random so i'll keep testing.

I also discovered that if i link the mesh avatar to a prim and attached it, the avatar would stretch to undeformed state. If i linked the prim to the Mesh avatar it would deform almost correctly, not sure if thats helpful info:-s.

While i love the fix, I'm not sure what to do about my creations. People have been buying my clothes, shirts and hoodies over the past year and this fix will break them.

@sl-service-account
Copy link
Author

Vir Linden commented at 2014-10-08T21:39:58Z

Hi Loki,

It would be very helpful if Maestro Linden and I could get copies of any other items that are affecting your results. That would let us make sure that we understand what is causing the results you are seeing. If there is a "bug eye" syndrome that's different from other joint offset issues, it might be worth filing a separate issue for that - and there also, it would be very helpful to have the items for reference.

@sl-service-account
Copy link
Author

Loki Eliot commented at 2014-10-09T10:56:41Z

The bug eye thing i don't think is a bug, more a limitation of the SL skeleton which i did a work around by deleting the eye bones, which i now consider a big mistake. I no longer use this practice in making clothes for SL and my Mesh Avatar is still in the creation stage so I've been able to fix that. This issue now only effects legacy products, namely my V3 Range, Hoodies, T-Shirts, Longsleeve Shirts.

The Maintenance Viewer seems to exhibit different deforming effects. For instance sometimes the eyes will disappear when wearing the tops,sometimes the shoulders will deform correctly, other times they will not.

I have sent you the basic teen avatar with a demo shirt. This one will often deform correctly to the joint rig, but the eyes disappear.

The second shirt i sent is the Programme Black shirt, This shirt is a jointed rigged shirt, with a non-joint rigged overlay linked on top of the shirt for the masked Glow pattern. The combination of the two types of rigged object might cause the shirt to never deform correctly giving a sloped shoulder look. Relogging.

in both cases relogging brings back the eyes. I have added the V3RangeProblems.jpg to show these shirts.

@sl-service-account
Copy link
Author

Henri Beauchamp commented at 2014-10-15T15:35:21Z

I, too, noticed issues with eyeball joints and tiny mesh avatars after backporting the changes from viewer-tiger that are supposed to fix "MAINT-4158 WIP" (or so it is called in the commits. BTW, why can't we see MAINT JIRA issues ?...).

I therefore disabled the new joints position tracking code and kept the old one (I can switch from one to another by simply flipping a define in the sources).

I'm adding two screenshots, one taken with the current release version (old code) of the Cool VL Viewer (TinyHenriMeshOK.png), and one taken with the same version recompiled with the new code enabled (TinyHenriMeshKO.png): notice how the eyeballs are displaced with the new joint position tracking code.

I can send a copy of the (self-made) tiny mesh & associated shape to any Linden needing them for tests/repro.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-10-22T12:53:09Z

Henri, I believe I'm seeing this same eye problem on the Lion builds - see BUG-7583

@sl-service-account
Copy link
Author

Henri Beauchamp commented at 2014-10-22T13:39:26Z

@whirly

Yes, the related commit apparently got propagated to many viewer branches (bear, tiger & Co)... That's kind of worrying, since it could end up in viewer-release without getting fixed first...

@sl-service-account
Copy link
Author

Loki Eliot commented at 2014-10-22T21:36:10Z

The maintenance viewer has been withdrawn, so i doubt its going to appear in main viewer. Im sure they are beavering away and will come back with another maintenance viewer to try. Just gotta sit and wait :)

@sl-service-account
Copy link
Author

Loki Eliot commented at 2014-11-07T11:11:20Z

Do Lindens get Bonuses? because who ever apparently fixed this issue in the latest Second Life Attachments Viewer version 3.7.20.296355 deserves a bonus. http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/3.7.20.296355

So far my Mesh body can be removed and re-attached with nor distortion to deformations. My old joint rig shirts appear to attach exactly how they should and now detach without any issues. Eyes also appear to display correctly.

Hope others see same results?

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-11-07T15:14:50Z

Yep!
Its working really well.

I cannot reproduce any of these issues on the Attachment-RC:

Avatar distorted when changing outfits
BUG-6197 MAINT-4158

Shape distortion when wearing / taking off rigged mesh with joint offset (BUG introduced in version 3.7.9.290582
BUG-6439 MAINT-4189

Body crusher animations for quadruped avatars do not appear to load
BUG-7505 MAINT-4572

[LION] Avatar eyes sometimes disappear after adding or removing rigged mesh
BUG-7583 MAINT-4605

[LION] Avatar shape is deformed after removing some rigged meshes. Deformation is only seen by users on the Lion viewer, not default release.
BUG-7585 MAINT-4606

[Maintenance-RC] Attachments appear in wrong position for observers on the Maint-RC but appear in the correct position to yourself on the Maint-RC. Observers on default release see attachments correctly.
BUG-7436 MAINT-4536

@sl-service-account
Copy link
Author

Maestro Linden commented at 2014-11-07T17:05:23Z

Thanks for the feedback, guys. Vir's the one who fixed these issues.

@sl-service-account
Copy link
Author

Henri Beauchamp commented at 2014-11-08T13:48:07Z, updated at 2014-11-10T10:00:28Z

I'm afraid the latest code changes are not enough to cure the bug... Here is what I get when changing a full (mesh-less) outfit for an outfit containing a full-rigged mesh and a different shape.

I proceeded as follow:

  • I started the viewer wearing a base (mesh-less) avatar (see step1_InitialAvatarOK.png).

  • I changed to a full-rigged mesh avatar using right-click on folder and "Replace Outfit" (see step2_RiggedMeshAvatarOK.png): so far, so good.

  • I then changed back to the initial outfit (step3_BackToInitialAvatarKO.png): see how the shoulders are narrower.

    Repeating this cycle again (wearing the mesh avatar, then back the initial mesh-less avatar), I get even narrower shoulders each time (see step6_BackToInitialAvatarKO.png).

    The problem is only when you change a full outfit and the new outfit got a different shape (here, with much narrower shoulders).

    Interestingly enough, in the Cool VL Viewer (that got the same code backported to it), I get the opposite effect (the shoulders widen), which can only be explained by the way the two viewers differ in their "Replace Outfit" implementation (I implemented the COF in a different way in the Cool VL Viewer, so the order in which the wearables and the attachments are worn is different than in the official viewer).

    My guess (but it's just a guess because I had no time and will have no time to investigate it in the coming days/weeks) is that the problem is related with:

  • the absence of proper tracking for joint rotations (only offsets are tracked and, stop me if I'm wrong, but I do think rigged meshes may also affect rotations).

  • the absence of tracking of shape changes (each shape got different joint offsets when compared with the base skeleton (Ruth), so this should be tracked as well as for the rigged meshes).

  • the inherent out-of-order operations implied by changing outfits (the shape may be changed first, then the mesh, or the other way around, depending either on the algorithm in the viewer, the server lag, or simply the user's action on individual items), which needs to be tracked in a LIFO stack (I have been surprised when backporting the code, that a map was chosen for keeping track of offsets: granted, offsets should be commutative, but when rotations come into play...); as a coder, I'd have personally used a list instead of a map...

    To summarize: the new code is a step in the good direction, but still far from sufficient.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-11-10T07:33:16Z

Henri, This looks like the same repro you gave in VWR-28458

@sl-service-account
Copy link
Author

Henri Beauchamp commented at 2014-11-10T09:58:28Z

@whirly

Wow... I had forgotten about that (two and half years old !) report, but yes, it's basically the same bug: fact is, the new joint position tracking code that was supposed to solve it (together with all the joint position related bugs) fails.

@sl-service-account
Copy link
Author

Vir Linden commented at 2014-11-17T22:14:37Z

Folks who are still seeing problems, could you try this build:
http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/vwr_attachment-fixes-drtvwr-388-2/rev/296809/index.html
and let me know if it helps? Any feedback would be appreciated.

@sl-service-account
Copy link
Author

Henri Beauchamp commented at 2014-11-17T22:39:21Z

@vir

Just did a quick test(with the problematic outfits) and so far so good, but it's bedtime for me now, so I'll do more tests tomorrow...

@sl-service-account
Copy link
Author

Vir Linden commented at 2014-11-21T20:42:24Z

Loki, if you could send me a copy of the rigged mesh avatar as well I will take a look.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-11-21T21:16:15Z, updated at 2014-11-21T21:38:51Z

Thanks Loki.
I can easily reproduce it with your mesh anime avatar.

On Second Life 3.7.21 (296876) Nov 19 2014 06:57:49 (Second Life Test)

Replace outfit with the anime folder
Edit shape and change eye depth setting - observe that you see the eye depth change correctly on your screen.
Save changes to shape - eye depth still looks correct at this stage.
Exit edit appearance mode
Observe eye depth has reverted.
Edit shape again an check eye depth setting
Observe eye depth shows the correct value on the slider.

I do not need to relog to reproduce this.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-11-21T21:23:50Z

On the Attachments-RC viewer, Second Life 3.7.21 (296729) Nov 10 2014 16:35:49 (Second Life Release)
I see different behaviour.
The eyes look correct after editing eye depth and exiting edit appearance.
However, after relogging, the eyes have reverted.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-11-21T21:29:26Z

Default release Second Life 3.7.21 (296736) Nov 10 2014 19:23:31 (Second Life Release) behaves the same way as the Attachments-RC
Eyes hold their edits and look correct until you relog. After relog the eyes have reverted.

@sl-service-account
Copy link
Author

Vir Linden commented at 2014-11-21T21:41:55Z

If you are wearing a mesh that defines a joint override for the eyes, then the "correct" behavior really is that the eyes go where the mesh says - that is, the mesh overrides the position requested by the shape or any other wearable. So I would say the bug here is that the shape editor doesn't enforce that constraint while the sliders are being manipulated. If you want the eye positions to be editable, you would need to omit the eye joint offsets from the mesh and just let this be set by the shape.

@sl-service-account
Copy link
Author

Loki Eliot commented at 2014-11-21T22:15:51Z, updated at 2014-11-21T22:20:00Z

@vir i have sent you the joint rig mesh. I'm ok with the eyes not being editable, but it's just that they don't seem to stay in the same position after a relog or change in viewer, or swapping joint rigged mesh. It's not being consistent from one session to the next, nor is the bug being persistent with is annoying me, because i can't say for definite this is an issue with my mesh, nor am i sure its a viewer issue.

@sl-service-account
Copy link
Author

Vir Linden commented at 2014-11-21T22:20:16Z

Thanks, I'll take a look.

@sl-service-account
Copy link
Author

Loki Eliot commented at 2014-11-21T22:59:22Z

OK, so i think i've sorted out a way to clearly show the bug, it does not happen all the time though, but i managed to film it.

  1. Make a duplicate folder of both The Meshykid-Anime and the Meshykid-Bigboy
  2. Wear the Meshykid-Anime, then wear/replace with the Meshykid-Bigboy folder.The eyes will appear bug-eyed which is wrong.
  3. Wear/replace with the 'second' Meshykid-Bigboy folder. This should cause the eyes to display correctly in their sockets.
  4. Now Wear/replace with the Meshykid-Anime folder. The eyes will appear cross eyed, also the neck seemed slighting distorted.
  5. Wear/replace with the 'second' Meshykid-Anime folder. This should cause the eyes to display correctly in their sockets.

Here is a video demonstrating this : http://www.zippcast.com/video/00cd02bba48e6e9a9e3

Its as if the eyes are keeping the previous deform position when swapping with a new joint rigged avatar. Sometimes when i log in the eyes are not deforming to the joint rigged avatar I'm wearing on login.

Hope this helps.

@sl-service-account
Copy link
Author

Vir Linden commented at 2014-11-24T18:11:23Z

Loki, which build were you using for the tests in your previous comment?

@sl-service-account
Copy link
Author

Loki Eliot commented at 2014-11-24T18:14:04Z

i dont remember, either viewer 3.7.20.296094 or viewer 3.7.21.296876. or both. Its there a specific one you'd like me to test on?

@sl-service-account
Copy link
Author

Vir Linden commented at 2014-11-24T18:24:24Z

The latest changes are in the build http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/vwr_attachment-fixes-drtvwr-388/rev/296904/index.html, so that would be most helpful to get feedback on. I tested that build with the folders you sent and was not able to repro the problems, but that may just be me.

Thanks for checking!

@sl-service-account
Copy link
Author

Loki Eliot commented at 2014-11-24T18:54:20Z

Using that viewer I can NOT reproduce the sticky eye syndrome i showed in my video. Awesome. I think it was this that led me to be confused about editing eye position.

@sl-service-account
Copy link
Author

Vir Linden commented at 2014-11-24T19:20:22Z

The previous discussion, about issues with adjusting sliders that are also affected by a rigged mesh, is very likely not fixed. The exact symptoms will vary from build to build, but a complete fix would require a deeper rework of the joint code than the current changes.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-11-24T19:23:55Z

Testing on Second Life 3.7.21 (296904) Nov 20 2014 08:42:15 (Second Life Release)

Vir, I'm still having problems with my COF getting in a weird state on this viewer.
I'm not sure whats going on heh.

Over the last couple of days (including today) I've changed outfit numerous times on default Linden release and Firestorm and had no problems. Now I'm on the test viewer Im getting the same problems as I had on the previous build (Second Life 3.7.21 (296876) Nov 19 2014 06:57:49 (Second Life Test)).
I relogged on default Linden viewer and did some outfit changes and everything is back to normal.
I relogged back on Second Life 3.7.21 (296904) Nov 20 2014 08:42:15 (Second Life Release) and after replacing outfits a couple of times, things went wrong again.

If you think its "just me" then I'll accept that but something seems to be wrong.

When I do a replace outfit on your test viewer, the outfit doesnt completely replace. Some parts of the old outfit stay stuck on and I end up wearing 2 skins or 2 shapes or 2 sets of eyes etc.
This is what happened after I went to Develop -> Avatar -> Character tests -> Test female to reset my avatar: http://i.imgur.com/Ag7njQv.png
COF shows Im wearing 2 shapes, 2 eyes and 2 skins.
I cannot remove those worn alpha layers - if I right click one of those alpha layers in COF and choose "Take off", nothing happens, it still shows as worn in COF and this prints to log...

2014-11-24T19:14:02Z WARNING: AISCommand::httpFailure: [DELETE:https://sim10721.agni.lindenlab.com:12043/cap/b4eb08d6-ad88-09ce-bef6-e1e73e09df20/item/9d955af5-f896-37c0-adb7-fdb9cf1a6c34] [status:410] [reason:Gone] [content-type:'application/llsd+xml'] [content:{'error_code':i9,'error_description':'Item does not exist or was already deleted.','error_filename':'item.py','error_function':'Item.delete','error_line_number':i189,'item_id':u9d955af5-f896-37c0-adb7-fdb9cf1a6c34}]
2014-11-24T19:14:02Z INFO: LLAdaptiveRetryPolicy::onFailureCommon: Non-server error 410, will not retry

This is how I see myself: http://i.imgur.com/4bbJwt1.jpg
This is how an observer sees me: http://i.imgur.com/lbrjrMK.jpg

Log file attached (lots of icky appearance errors in it): Whirly_2.log

I'm guessing this isnt much use to you without a consistent repro though?

@sl-service-account
Copy link
Author

Vir Linden commented at 2014-11-24T20:48:34Z

Well, a consistent repro would certainly help. There really shouldn't be any changes in the test viewer that affect COF management as such, so it's odd that a problem would only manifest there. If I can repro it we can dig deeper into the problem.

@sl-service-account
Copy link
Author

Henri Beauchamp commented at 2014-11-24T22:41:29Z

@vir & Whirly, about COF state:

I saw that kind of problem (two identical body parts worn in the old and the new outfit, after replacing the former with the latter) a long while ago, when backporting (part of, since the COF was not backported back at that time) the v2 code to the Cool VL Viewer: the cause is that even when the body-part wearable UUID is the same, but pointed to by two different inventory items, you must "remove" the old body-part before wearing the new one, else you'll get the two body parts inventory items flagged as worn in the inventory: this is counter-intuitive, since you normally can't remove a body part (but only replace it with another), but it's how it must be done.

In the test viewer, the "Replace Outfit" function got changed to only wear items that actually differ from one outfit to the other. It's not a problem for attachments (since when they live in different folders, they always bear a different UUID), but it is for wearable (a same wearable UUID may be associated with different wearable inventory items that live in different folders, so you must always unwear every wearable before wearing the "new" ones in another folder, even if they share the same wearable UUID...

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-11-24T22:51:09Z, updated at 2014-11-24T22:52:57Z

Aha! So I'm not crazy and this is a new problem on the test viewer?
It is only affecting wearbles yes - skin, shape and eyes mostly - I end up wearing two of them and it appears I really am wearing two of them because both show in COF. I cannot take one of them off either, I get totally stuck in a bake fail and have to relog on the default Linden viewer to fix my avatar. When I get in this state if I right click COF -> Remove from outfit, all the attachments come off but no clothing layers or alpha layers will detach at all.
If I replace outfit again when in this state, I still have multiple body parts worn.

I'm still trying to work out a solid repro for this - all I have so far is login on the test viewer, right click an outfit folder in My Outfits or a normal folder containing outfit componenets and "Replace outfit". After a few replace outfits, the bug (or whatever it is) hits me.
I cannot reproduce it consistently swapping between the same outfits though - feels like it's a timing thing....

@sl-service-account
Copy link
Author

Henri Beauchamp commented at 2014-11-24T23:43:37Z

@whirly

I cannot tell for sure (I'm not using LL's viewer unless I want to check a bug that exists in my viewer is also in LL's viewer, and the Cool VL Viewer is not affected by that bug, thanks to a much saner COF implemenation...), but the changes I saw while backporting did make me think "there could be a problem here, but my viewer won't be affected anyway...", so yes, I think this is the problem you are seeing.

To consistently repro the issue, the trick is to have the same body part (i.e. same visual params and textures), either the eyes or shape, or hair, or skin as two different inventory items in the two outfits folders (the one you wear and the one you change to with "Replace Current Outfit"). This will cause the test viewer not to unwear the old body part (because it got the same wearable UUID as the new one, even though the two body parts got different inventory item UUIDs) and still to wear the new body part, which will cause the two body parts to be flagged as "worn" in the inventory, and the viewer to get stuck when you try to unwear any (but it should still be able to wear a body part bearing a different UUID (i.e. a different shape/eyes/skin/hair). That issue does not appear when wearing a different (by their visual params or textures) shape/eyes/skin/hair, because then their wearable UUID differs, and the code in llagentwearable.cpp uses this UUID (and not the inventory item UUID) to decide to replace a body part or not...

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-11-25T00:23:26Z

...even though the two body parts got different inventory item UUIDs

Is the inventory item UUID the UUID I get when I right click the body part in inventory -> copy asset UUID?

I'm aware of the old bug which can cause the inventory to show 2 shapes worn for example when they have the same UUID (same UUID when using "copy asset UUID" under right click), for example if you copy a shape and then wear the copy. I already checked the UUIDs (under right click -> copy asset UUID) and they were different.

How do I see the "wearable UUID" ?

From what you say I think I know why this problem is triggering so badly for me on the test viewer.
I have a lot of the exact same shapes saved in my outfits that have different UUIDs under right click -> copy asset UUID because to work around that old bug, I import my shape fresh for each outfit so it has a different UUID. But I guess if that shape isnt changed in any way, it will have the same wearable UUID?

@sl-service-account
Copy link
Author

Henri Beauchamp commented at 2014-11-25T10:00:54Z

@whirly

Yes, just like "Copy Asset UUID" will copy the UUID of the associated image when you use it on a texture inventory item, it copies the wearable UUID when using it on a wearable inventory item, and yes, the way to get the same wearable UUID in several different inventory items is indeed to use copy/paste; as soon as you edit a wearable and save it again, its UUID changes however (so if you edit a shape and change just a parameter and save it, then edit it again and revert that last change and save it again, even though the edited shape and the original shape are the "same" (same params), they will now have different wearable UUIDs).

The "inventory ids" are in fact many, because for a same item listed in your inventory, you will have the UUID of the corresponding UI element (a list item in a folder view, which UUID is generated on the fly during the viewer session), the UUID of the inventory item (as saved in the inventory server) and the UUID of the "asset" (for wearable items it's the wearable UUID for, texture items it's the image UUID, and for objects, when attached or rezzed, they get the viewer object UUID generated, which also changes at each new session when attached, but their "asset UUID" (as returned by "Copy Asset UUID") is always LLUUID::null).

@sl-service-account
Copy link
Author

Vir Linden commented at 2014-11-25T14:03:18Z

Sounds like the issue may be caused by a fix for another bug that's not attachment-related, but has been working its way along in the same repositories. I'll put up a test build with that disabled.

@sl-service-account
Copy link
Author

lindenrobot commented at 2014-11-25T14:21:54Z

New Changeset:
http://bitbucket.org/VirLinden/attachment-fixes-drtvwr-388/changeset/70c76393edd0
possible fix for COF issues reported in BUG-7433 - test only
Committed by: Brad Payne (Vir Linden) vir@lindenlab.com

@sl-service-account
Copy link
Author

Vir Linden commented at 2014-11-25T18:20:43Z

Whirly:

see: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/vwr_attachment-fixes-drtvwr-388/rev/297047/index.html

removed a recent change for handling of wearables with the same asset id. If you have a chance, could you let me know whether COF gets corrupted running this build?

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-11-26T21:04:07Z

@vir
So far no problems seen with Second Life 3.7.21 (297047) Nov 25 2014 06:52:19 (Second Life Release)

I'll comment back if I have any problems with COF.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-12-01T00:13:24Z

Quick update: 3.7.21 (297047) Nov 25 2014 06:52:19 (Second Life Release) still behaving fine. No COF problems seen.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant