search

secondlife / jira-archive

2 stars 0 forks source link

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

Open sl-service-account opened 9 years ago

sl-service-account commented 9 years ago

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 commented 9 years ago

Loki Eliot commented at 2014-11-21T18:18:19Z, updated at 2014-11-21T18:23:58Z

I sent you a copy of my rigged mesh avatar. If you wear the anime avatar, the eyes should appear as if bugged out from he sockets. You can edit the body shape to adjust the eyes depth to make them sink in behind the blinking eyelids and save. Everything looks fine, but if you relog the eyes return to being bugged out, but if you go and edit the body shape again, you will find the sliders are still set to the previous changes you saved before relogging. Then if you rely in the main current viewer eyes are all set different again.

sl-service-account commented 9 years ago

Loki Eliot commented at 2014-11-21T18:37:28Z

Maybe its something to do with the fact the eyes are part of the joint rig, so can't be edited? But I'm almost certain i was able to before viewer 3.7.20.296094.

sl-service-account commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

Thanks, I'll take a look.

sl-service-account commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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.