Whirly Fizzle commented at 2016-10-11T06:46:28Z

As discussed on the forum thread, Henri from CoolVL Viewer already spoke to the avatar creator who said that there are other avatars affected by this bug.
I left the creator Dreamcrawler Martin an IM pointing to this JIRA issue & asked him to add any other repro avatars he knows about.

Henri Beauchamp commented at 2016-10-13T07:39:32Z

@dan Linden

Err... I'm a bit puzzled, here. Why did you change this JIRA status to "Needs More Info" ?... You got all the info we could possibly gather, even with a repro mesh to test the viewer code against !

Whirly Fizzle commented at 2016-10-13T07:49:53Z

I'm guessing it's so the creator (or others) could comment.
Comments are locked to everyone apart from filer & triagers on an issue in the Accepted state.

This bug's been imported as MAINT-6814

Henri Beauchamp commented at 2016-10-13T08:43:57Z

I'm guessing it's so the creator (or others) could comment.
Comments are locked to everyone apart from filer & triagers on an issue in the Accepted state.

Ah, that would be a explanation (and I didn't know the JIRA became so rigid and closed...).

This bug's been imported as MAINT-6814
"Permission Violation"
I can't even view a single "MAINT" JIRA issue, despite having been a viewer developer for 9 years already...

polysail commented at 2016-10-14T09:43:43Z

Just for public documentation purposes. Vir said he looked in to this and apparently the mesh asset file itself contains "invalid entries" of some sort ( I'm paraphrasing here ). The old viewer ignored those entries / defaulted them to ones that made sense, whereas the bento viewer displays it differently. Theoretically re-uploading the content with corrected values would fix it.

Vir Linden commented at 2016-10-14T13:25:49Z, updated at 2016-10-14T13:30:05Z

The problem here is that some of the sub-meshes contain bad joint position overrides for various joints that the model is rigged to. For example, the werewolf has 6 different joint positions defined for the left ear attachment point. Before bento, these joint position overrides were not applied, because we were enforcing a 20-joint minimum - if a sub-mesh was rigged to fewer than 20 joints, then it was not treated as rigged and the joint positions were ignored. For bento, we have relaxed this restriction to make it easier to create meshes that affect only part of the avatar - for example, you could have a set of mesh wings that only affects the position of the wing joints, or a mesh arm that only affects the position of the arm joints. Unfortunately, this means that any model that had bad but non-visible joint positions defined may now appear distorted. There is no obvious way to change the viewer behavior to fix this, without also breaking some bento models and making the extended skeleton less useful. The content could be fixed by re-uploading it with the bad joint positions removed, or by adding an animation to fix the joint positions after the fact. Of course, if the model does not require joint positions at all then the option could also simply be un-checked at upload time.

Henri Beauchamp commented at 2016-10-14T14:15:38Z

Thanks for the analysis of this issue: has the creator been made aware already, or should I point him here ?

Just an idea, however: won't it be possible to add a flag in the uploaded mesh meta data, to indicate that it was uploaded from a Bento viewer ? In this case, when a mesh gets downloaded by a Bento viewer, a check could be made for that flag: if absent, then invalid joints in the mesh would be treated (ignored) like they were in non-Bento viewers... Of course, this would break current Bento meshes (but after all, Bento is still in RC, and many such meshes were already broken due to skeleton/joints changes in Bento).

Whirly Fizzle commented at 2016-10-14T15:29:11Z

Henri, can you let the creator know?
I did contact him about this JIRA issue but he didn't get back to me.
He may not even have seen this JIRA issue.
You said on the forum thread that the creator told you other creators work was also affected by this problem too. Do you have any idea how much content will be affected by this?

Vir, have you decided yet if this is a "wont fix"?

Vir Linden commented at 2016-10-14T18:50:56Z

Whirly, this hasn't been classified as anything yet. Henri, we will try to contact the creator.

If anyone knows of other affected content, please let us know; it would help to know more about the scope of the problem.

veryvicki commented at 2016-10-17T01:12:34Z

I have a Rigged Mesh teddy that renders correctly on top, but the bottom half is inverted. Here are the details:

Creator: Auston Harbour
Store Name: [Haste] http://maps.secondlife.com/secondlife/Offbeat/66/184/23
Item Name: Coy
Item Description: Rigged Mesh Teddy

The bottom half of the item is inverted, extending back up over the wearer's head. This happens on all standard attachment points.

Whirly Fizzle was able to repro on the SecondLife Bento viewer.

Whirly Fizzle commented at 2016-10-17T01:26:06Z

VeryVicki's repro item is here on the marketplace: "Haste Coy" - http://bit.ly/2ed7dct
Any colour will reproduce the bug.

I have attached images to this issue showing the problem.

• Fig 5 - Coy teddy on default LL release.
• Fig 6 - Coy teddy on LL Bento-RC.

Testing system:

Second Life 5.0.0.320160 (Second Life Release)
Release Notes

You are at 24.0, 33.0, 21.9 in Doris located at sim10255.agni.lindenlab.com (216.82.49.177:12035)
SLURL: http://maps.secondlife.com/secondlife/Doris/24/33/22
(global coordinates 247,576.0, 310,817.0, 21.9)
Second Life Server 16.09.23.320027
Retrieving...

CPU: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz (3491.96 MHz)
Memory: 16268 MB
OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 750/PCIe/SSE2

Windows Graphics Driver Version: 21.21.0013.7306
OpenGL Version: 4.5.0 NVIDIA 373.06

J2C Decoder Version: KDU v7.2
Audio Driver Version: FMOD Ex 4.44.31
LLCEFLib/CEF Version: 1.5.3-(CEF-WIN-3.2526.1347-32)
Voice Server Version: Vivox 4.6.0017.22050

Packets Lost: 65/2,749 (2.4%)
October 16 2016 18:25:50

Whirly Fizzle commented at 2016-10-17T01:41:26Z, updated at 2016-10-17T01:48:35Z

A lot of content from [Haste] is affected by this bug.
MP store: https://marketplace.secondlife.com/stores/118301

Two more examples.

1. [Haste] Strings Bikini
   Demo: https://marketplace.secondlife.com/p/Haste-Strings-Bikini-Demo/6304654
   Fig 7 - Strings bikini rendering as expected on LL default release.
   Fig 8 - Strings Bikini broken on the Bento-RC.

2. [Haste] Micro Bikini
   Demo: https://marketplace.secondlife.com/p/Haste-Micro-Demo/6277906
   Fig 9 - Micro bikini rendering as expected on LL default release.
   Fig 10 - Micro bikini broken on Bento RC

polysail commented at 2016-10-17T02:08:10Z, updated at 2016-10-17T10:14:24Z

Okay ~!! So at this point it's pretty clear it's not just one or two meshes that might be broken by this.

However, I can't help but notice that mesh LLM files have a date-of-upload specified in the file spec. ( "date" – LLDate (as LLSD, seconds since epoch UTC) of upload, filled in by simulator)

So! Is it theoretically possible to just make all mesh uploaded after "bento release date" render one way, and all mesh prior to that date render the old way? And kind of ~ just not worry about this? No need to remove any functionality at all?

It's not a perfect fix, but in the interest of having our cake and eating it too while minimizing the damage this seems like it would be the best short-cut solution.

Whatever tool was used to generate these sorts of hacky multiple joint position errored content will obviously have to be updated. But I suspect that will basically just be Avastar, since there aren't many other tools out there for SL specifically. Though it would be nice to check for sure so the appropriate party can be informed.

Whirly Fizzle commented at 2016-10-17T02:09:51Z

I left Auston Harbour (the [Haste] creator a message explaining this problem and a link to this JIRA issue.
He was offline though.

Henri Beauchamp commented at 2016-10-17T13:09:15Z

However, I can't help but notice that mesh LLM files have a date-of-upload specified in the file spec.
So! Is it theoretically possible to just make all mesh uploaded after "bento release date" render one
way, and all mesh prior to that date render the old way? And kind of ~ just not worry about this? No
need to remove any functionality at all?
It's not a perfect fix, but in the interest of having our cake and eating it too while minimizing the
damage this seems like it would be the best short-cut solution.

Please, see the proposal I made in my comment above (dated 14 Oct): a flag in the meta data, indicating the mesh was uploaded with a Bento viewer, would be, IMO, a better solution than comparing dates. Another possibility would be to increment the mesh format version for mesh uploaded with Bento viewers (in this case, old viewers will not render the newer mesh: it should however be verified that it doesn't make them crash because of bugs in the version detection).

polysail commented at 2016-10-17T21:27:59Z, updated at 2016-10-17T21:38:38Z

Oh ~ I thought the LLM file format was a static unchanging thing, much like the internal anim format is, hence my date notion. If adding a flag to the mesh file format is indeed a practical solution, or basing it off version number ~ then it would be a superior one. Mine was simply for in the case that it was not, since dates can be retroactively tracked, whereas I'm not sure mesh version numbers were incremented in a meaningful fashion recently.

Vir Linden commented at 2016-10-18T17:01:34Z

Thanks for mentioning the [Haste] asset issues. This is a different issue; the models I've looked at so far don't even define any joint positions, so it's not a problem with bad values there. Probably related to changes in our logic for handling invalid joint references.

Whirly Fizzle commented at 2016-10-18T18:40:27Z

@vir
Do you want a new JIRA issue filed for the Haste bug?

Vir Linden commented at 2016-10-18T18:43:59Z

Already filed as MAINT-6841, thanks.

Whirly Fizzle commented at 2016-10-18T20:25:04Z

Just saw the Haste bug fix go in: https://bitbucket.org/lindenlab/bento-box/commits/834aaf9de5bc79b16c3c5e2963ea99aa184042e0

Vir Linden commented at 2016-10-19T12:26:47Z

Haste bug fix will be in the next RC update for Bento.

Vir Linden commented at 2016-10-19T12:28:12Z

Again, we urgently need to know about any broken content. If you know of problem cases other than the original werewolf or the various [Haste] assets, please let us know.

ZacharyZemsen commented at 2016-10-21T06:16:15Z, updated at 2016-10-21T06:21:25Z

I've found a similar problem on the arms and chest of the 1st Act Garou Male avatar: https://marketplace.secondlife.com/p/1A-Garou-Male-Starter-Kit/6866528
(I have not tried it on the female version.)

Most noticeably it affects the shoulders, arms, chest, and hips.

Here are screenshots taken in the current non-bento viewer (4.1.1.320331):
https://puu.sh/rQjxH/a127c4b1da.png
https://puu.sh/rQjxS/e60217a289.png

Then viewing in Bento (5.0.0.320815) after first logging in:
https://puu.sh/rQjxM/2ae94d3f9f.png
https://puu.sh/rQjxE/91b0b15faf.png
Might not be noticeable at first, but the arms are slightly distorted.

And finally after clicking "Reset Skeleton":
https://puu.sh/rQjxL/3586867c5c.png
https://puu.sh/rQjxI/d06bc468fb.png
This is where it's the most obvious.

(PS: I've never posted in JIRA before, so if linking screenshots this way is frowned upon, please let me know. I couldn't find any guidelines about that.)

polysail commented at 2016-10-21T07:20:45Z

I'm able to reproduce that "scrunching" on 'First act" werewolves too, but it reverts to looking proper the moment I cam away and back again.

Whirly Fizzle commented at 2016-10-21T10:24:50Z

@ZacharyZemsen
Linking screenshots like that is just fine :)
You can also attach images directly to a JIRA issue by using More Actions -> Attach files option at the top of the issue.
Don't use the More Options -> Attach Screenshot option - it's broken on this version of JIRA.
Also if you are not the filer of the JIRA issue, you may not see the Attach Files option when the JIRA issue has certain statuses.
tl/dr - what you did above is ok :)

Whirly Fizzle commented at 2016-10-21T11:44:01Z

I can also reproduce the shoulder deform on the 1st Act werewolf on Second Life 5.0.0.320815 (Second Life Release).
Zooming camera out & back did not fix the problem for me.

I didn't buy the avatar (expensive & no demo) but there was a shopper wearing one at the store when I went to look :)

On the Bento-RC: http://prnt.sc/cx2jny
On default release, Second Life 4.1.1.320331 (Second Life Release): http://prnt.sc/cx2lf4

Whirly Fizzle commented at 2016-10-21T12:34:03Z

Another repro werewolf avatar that has bulging eyes on Bento only.
Weredog Hell Series by JackRipper666
https://marketplace.secondlife.com/p/WEREDOG-HELL-SERIES/5484636

Note that this is the repro avatar from BUG-8616
@vir - if you still have the original "BUG-8616 repro avatar" box from BUG-8616, that will reproduce it.
I placed the "BUG-8616 repro avatar" box out at http://maps.secondlife.com/secondlife/Testylvania%20Sandbox/125/183/22 again.
Look for http://prnt.sc/cx3ab2
Just unpack to inventory and the replace outfit.

On Bento Second Life 5.0.0.320815 (Second Life Release)

• The avatar eyes bulge out of the head and the eyes do not fully close when blinking.
• Image showing eye bulge: http://prnt.sc/cx34lg
• Gif showing eyes blinking: https://gyazo.com/948ea839a9000658d9459ec793c3240a
• Resetting skeleton does not fix the problem.
• Reset skeleton seems to make the eeyes bulge even more actually: http://prnt.sc/cx38nr

On default release Second Life 4.1.1.320331 (Second Life Release)

• Image showing eyes rendering correctly with no bulging: http://prnt.sc/cx36c6
• Gif showing eye blink working correctly: https://gyazo.com/b3bb1c21c0be98b0da15a5ab74997fe0

Whirly Fizzle commented at 2016-10-21T21:32:29Z, updated at 2016-10-21T21:35:51Z

Regarding the 1st Act Garou Male avatar from above, it isn't just the shoulders that deform when resetting skeleton, the whole head deforms and the eyes are no longer in their sockets.
Before resetting skeleton: http://prnt.sc/cxaob3
After resetting skeleton: http://prnt.sc/cxap1x

If you need details of exactly what's worn in those images (muzzle etc), contact Sovereign Engineer (Alchemy viewer dev).
His avatar is one of the 1st Act rigged mesh avatars though.

Zooming camera out & back doesn't fix it once you did a reset skeleton.
I had to relog to see his avatar correctly.

polysail commented at 2016-10-22T01:18:17Z

My 'zoom out' and zoom in again was unloading the avatar from memory. Effectively a full reload. I should have specified "Cam out until it unloads from direct memory."

Whirly Fizzle commented at 2016-10-22T21:08:53Z, updated at 2016-10-22T21:21:22Z

@vir
You may want to check https://marketplace.secondlife.com/p/Skadi-Sergal-Armor-Small/6502780

One if the Firestorm beta testers [~Chaser.zaks] reported this armor broken on the Firestorm Bento build the beta testers have.
The armor renders correctly on the latest Bento-RC viewer and is also fixed on Firestorm Bento after merging in the latest changes, so I'm presuming it's the same bug as the [Haste] assets.

Buggy on older Firestorm Bento build: http://prnt.sc/cxmvrj
Impressively broken, it covered half the region!

Fixed on Firestorm Bento merged up to Bento-box tip: http://prnt.sc/cxnwo7

Vir Linden commented at 2016-10-26T19:14:38Z

Hi Whirly,
Thanks for passing that along. I've tried a few different settings, including trying to reproduce your eye size, eye depth, and head length values from the above paste. The only difference I've seen so far is the known issue with eye size, so if I change the eye size slider to 50, then the bento and default viewer images match. If you get a chance, could you try that and tell me how it works for you?

Whirly Fizzle commented at 2016-10-26T20:46:16Z

@vir
Confirmed.
As long as eye size is set to 50, the rigged eyes look the same on the Bento & the non-Bento viewers.

This will be a fun transition until everyone is on Bento :D

sovereign.engineer commented at 2016-10-31T13:44:49Z

So in regards to the Garou avatar, if you wear it, reset skeleton so it gets stuck into that messed up skeleton state, detach it, reset skeleton again, then reattach it, it will still be stuck in a broken state.

Izome Rigaud commented at 2016-11-02T04:29:39Z

Hi there, I did the rigging on the Garou avatar and was made aware of this issue recently. The armature for the avatar is the reference skeleton just with bones translated into position before skinning. The only "weird" parts I can recall are the face and tail which use attachment bones for animating. These .anim files for some facial expressions do have bone translations in them if I recall correctly, I know sometimes SL's animation blending can produce unexpected results. Additionally, I'm not sure about the engine side of things but if SL treats attachment point bones differently it might be possible that a sanity check somewhere might be moving them into unexpected (for avs with skinned attachment bones anyway.) positions. The head has the following hierarchy:

mHead 
├ mSkull (Rigged to mouth)
├ HEAD
├ mEyeLeft
├ Chin (Rigged to left eyelid/brow)
├ mEyeRight
└ Nose (Rigged to right eyelid/brow)

I'm also unsure what might be causing the arms to deform. I used scale values from the XML inside the SL directory for the fitted mesh volume bones, so I suppose it might not be out of the realm of possibility that I might have made a typo someplace. I'll have to go through and double check them all. If anyone needs a copy of the avatar for testing feel free to IM izome.rigaud inworld.

polysail commented at 2016-11-04T15:46:50Z

Ty, Izome~ I pinned down the problem finally after a few hours of poking at it. For some odd reason the collision volume positions are not being correctly "read" by the Reset Skeleton tool. I've created another issue for that problem specifically and have tethered it to this one. Ty for explaining to me how you rigged and set up your av's~ it helped point me in the correct direction for where to look.

Vir Linden commented at 2016-11-04T17:55:42Z, updated at 2016-11-04T19:49:47Z

It does look like there's a problem with reset skeleton - it resets joint positions defined for bones and attachment points correctly, but misses joint positions for collision volumes. Will be fixed in an upcoming build.

Thanks for all the input on this!

Dante Tucker commented at 2016-11-26T11:27:33Z

I have some rigged mesh feet effected by this. Puppy paws available here https://marketplace.secondlife.com/p/Puppy-Paws-Rigged-Mesh/4019091

Before bento: https://i.sli.mg/m3KRO1.png
After: https://i.sli.mg/F5Q074.png

Whirly Fizzle commented at 2016-11-26T20:28:13Z

I can't reproduce the broken puppy paws on my system, the mesh renders correctly on LL release, LL Bento-RC and the latest Firestorm Bento Alpha at all graphics quality settings.
The paws still render correctly when Hardware Skinning is disabled.
Resetting skeleton does not break the paws.

Second Life 5.0.0.321760 (Second Life Release): http://prnt.sc/dc57nu

Dante, in the top menu bar of the viewer, go to Help -> About Second Life / viewer name.
Click the "Copy to clipboard" button & paste all your system information into a comment here.

This is my system information where the bug does not reproduce:

Second Life 5.0.0.321760 (Second Life Release)
Release Notes

You are at 89.9, 115.1, 21.9 in Testylvania Sandbox located at sim10344.agni.lindenlab.com (216.82.50.66:13012)
SLURL: http://maps.secondlife.com/secondlife/Testylvania%20Sandbox/90/115/22
(global coordinates 332,634.0, 306,291.0, 21.9)
Second Life RC BlueSteel 16.11.02.321369
Release Notes

CPU: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz (3491.96 MHz)
Memory: 16268 MB
OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 750/PCIe/SSE2

Windows Graphics Driver Version: 21.21.0013.7570
OpenGL Version: 4.5.0 NVIDIA 375.70

J2C Decoder Version: KDU v7.2
Audio Driver Version: FMOD Ex 4.44.31
LLCEFLib/CEF Version: 1.5.3-(CEF-WIN-3.2526.1347-32)
LibVLC Version: 2.2.4
Voice Server Version: Vivox 4.6.0017.22050

Packets Lost: 59/23,026 (0.3%)
November 26 2016 12:23:30

Dante Tucker commented at 2016-11-26T22:20:16Z

I'm only here because Lassie included the link in the latest alpha notice. I have not tested it on an official LL viewer.
The issue persists after deleting cache and all related SL/Firestorm folders. And is resolved on Release Firestorm.

 Firestorm 4.7.10 (51989) Nov 21 2016 17:31:34 (Firestorm-alphax64) with OpenSimulator support
Release Notes

You are at 163.3, 242.8, 58.7 in Ryder Beach located at sim9186.agni.lindenlab.com (216.82.42.122:13006)
SLURL: http://maps.secondlife.com/secondlife/Ryder%20Beach/163/243/59
(global coordinates 233,635.0, 257,267.0, 58.7)
Second Life Server 16.11.02.321369
Release Notes

CPU: AMD FX(tm)-6300 Six-Core Processor              (3515.54 MHz)
Memory: 16366 MB
OS Version: Microsoft Windows 10 64-bit (Build 14393)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 660 Ti/PCIe/SSE2

Windows Graphics Driver Version: 10.18.0013.6191
OpenGL Version: 4.5.0 NVIDIA 361.91

RestrainedLove API: RLV v3.1.4 / RLVa v2.0.3.51989
libcurl Version: libcurl/7.47.0 OpenSSL/1.0.1i zlib/1.2.8
J2C Decoder Version: KDU v7.8
Audio Driver Version: FMOD Ex 4.44.61
LLCEFLib/CEF Version: 1.5.3-(CEF-WIN-3.2526.1347-32)
LibVLC Version: 2.2.4
Voice Server Version: Vivox 4.6.0017.22050

Settings mode: Phoenix
Viewer Skin: Vintage (Classic)
Font Used: Deja Vu (96 dpi)
Font Size Adjustment: 0 pt
UI Scaling: 1
Draw distance: 200 m
Bandwidth: 1500 kbit/s
LOD factor: 2
Render quality: High-Ultra (6/7)
Advanced Lighting Model: Yes
Texture memory: 1024 MB (1)
VFS (cache) creation time (UTC): 2016-11-12T22:40:28 
Built with MSVC version 1800
Packets Lost: 0/1,356 (0.0%)
November 26 2016 14:13:02 SLT 

polysail commented at 2016-11-26T22:28:28Z

I have the exact same graphics card on win 10 with an Intel chip and I haven't been able to repro yet.

Whirly Fizzle commented at 2016-11-27T10:18:18Z

@dante
You are on the latest version of the Firestorm Bento Alpha, which has all the fixes for broken legacy content that the LL Bento-RC viewer has.

Please can you test on the LL Bento-RC viewer at http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/5.0.0.321760 and see if the puppy paws are still deformed.

Thanks!

Whirly Fizzle commented at 2016-11-27T10:34:11Z

Oh now that's odd.
I just relogged wearing the puppy paws and they are deformed as in your picture.
They were displaying just fine before relogging!

Same system information I gave above: http://prnt.sc/dcbo1k

Before relogging I changed into default female avatar - Develop -> Avatar -> Character tests -> Test female.
Then I wore the "Puppy Paws - Male Shape - Chinchilla", the "Puppy Paws Sock", the "Puppy Paws - Alpha" and the "Puppy Paws - Leg Muscle 50 - Fat 0"
Then I relogged.

Reset Skeleton & Reset Skeleton & animation do not fix the problem.

Whirly Fizzle commented at 2016-11-27T10:57:53Z, updated at 2016-11-27T11:41:08Z

Ok so, these paws are acting very oddly.
Sometimes on login they look normal and other times the left paw is deformed.
I'm seeing this same inconsistency on LL Bento-RC Second Life 5.0.0.321760 (Second Life Release) and Firestorm 4.7.10 (51989) Nov 21 2016 17:31:34 (Firestorm-alphax64) with OpenSimulator support.

When the paws are deformed, sometimes they remain deformed for the session, even after taking them off and adding them back on etc.
Other times, the paws will suddenly snap into the correct shape, even after displaying deformed for 10+ mins.

Polysail noticed that when you edit the worn paws on a Bento viewer, the left paw has odd vertices stretching out to infinity.
This does not reproduce on non-Bento viewers.

Example: https://gyazo.com/60d46dc1fcbdd0e9282dd4092933992f

It appears that the paws only deform (sometimes) when ALM is enabled.
I'm only seeing the odd lines shooting off to infinity in edit when ALM is enabled too.

When hardware skinning is disabled, the left paw mesh explodes over the region (but it's inconsistent, sometimes the paw looks ok): https://gyazo.com/27dcbb5815386d2d877925389eb390d0

polysail commented at 2016-11-27T11:31:18Z, updated at 2016-11-27T11:49:49Z

Odd vertex deformation in edit mode is affected by toggling any single one of the following settings while using my nVidia graphics card:
Enabling/Disabling VBO
Enabling/Disabling Basic Shaders
Enabling/Disabling Advanced Lighting Model
Enabling/Disabling Bump / Shiny
Enabling/Disabling Hardware Skinning ( this actually made sense to me )

Swapping to an IntelHD 4600 graphics, with it's associated drivers causes this bizarre behavior to cease. However, with this chipset enabled, disabling Hardware Skinning produces the appended related image.
Enabling Hardware Skinning on this chip, seemingly regardless of what other graphics options ( that are disabled by default due to the card spec ) are turned on , IE shiny, VBO, ALM, Bump Shine etc ~ the mesh still displays correctly.

At this point ~ I'm starting to think that this may have some sort of strange tie-in with https://jira.secondlife.com/browse/BUG-20019 , but that is unfounded theory at this point.

Vir Linden commented at 2016-11-29T13:55:57Z

Puppy paws problems seem to be an issue with vertex weights - there are some out-of-bounds joint references. Presumably there are differences in how we handle these in the Bento viewer. Imported this as its own bug (SL-540) for more investigation.

SweetSerefina commented at 2016-12-07T02:53:32Z, updated at 2016-12-07T02:54:05Z

Not sure if this is related ut on last two versions i have noticed a lot of issues with my toddleedoo head having huge gaps on the head/neck as it moves , with which i have never had or noticed before that last 2 versions. Like before it was stuck solid and would have stretched in the motion it is now having awkward gaping holes :/ quite distracting

https://gyazo.com/fb6a1e695c9785daaf7a2f1c0e666dc4

Henri Beauchamp commented at 2016-12-07T09:53:54Z

What is the status of this bug ?
Bento went live, but AFAIK, the werewolf still renders badly, even with the puppy-paws fix implemented...

Whirly Fizzle commented at 2016-12-07T10:52:49Z

As far as I'm aware, it was decided not to fix the DC next gen werewolf because the mesh was actually broken (some of the sub-meshes contain bad joint position overrides for various joints that the model is rigged to) & no other content has come to light yet that's broken on Bento because of the same problem & it would be difficult to fix without breaking other existing Bento content.

Whirly Fizzle commented at 2016-12-07T12:46:40Z

@SweetSerefina

Which Toddleedoo head are you using from https://marketplace.secondlife.com/stores/182374 ?

Are you wearing the Toddleedoo mesh body too? As far as I'm aware the Toddleedoo heads will only fit correctly onto the Toddleedoo bodies.

Whirly Fizzle commented at 2016-12-15T07:11:07Z

@vir
Here's another fitted mesh that doesn't behave correctly on Bento viewers - BUG-41063

Whirly Fizzle commented at 2016-12-17T13:47:03Z

@vir
Has a decision been made yet about whether to fix the DC Next gen werewolf?
I have a couple of Firestorm support tickets reporting this avatar is broken on the bento release and I'm not sure what to tell them, apart from to point them here & explain it's a known issue and why.
I'm guessing now bento is released, this particular werewolf can't be fixed because the fix would now cause too much bento content to break?

Henri Beauchamp commented at 2016-12-17T14:24:27Z, updated at 2016-12-17T14:25:25Z

@whirly

I was under the impression that LL already said they won't fix it (I got an email about it, but thought it was a reply in this JIRA to my question above and deleted it since from my mail client folder), unless they changed their mind...

I'm also getting reports (for my viewer, but every issue reproduces with LL's official release viewer) about the fitted meshes issues, so that's a lot of existing contents breakage: not sure all of this can be ignored and it would perhaps be wiser to treat new Bento meshes as a new mesh version (in the mesh repository version sense) and treat old mesh with old/compatible code... IMHO it will be easier to get Bento mesh creators to re-upload their quite new/recent contents, than to get in contact with every broken mesh contents creator for assets that got uploaded years ago and is now broken, and obtain from them that they "fix" and re-upload everything, then update all their customers/users with the newly fixed contents...

Vir Linden commented at 2016-12-17T14:28:41Z

We are not currently planning to make any changes related to the next-gen werewolf problem (caused by bad joint positions in the model). We don't yet know what is causing the new fitted mesh issues, so I can't say anything now about what will happen with them.

Whirly Fizzle commented at 2016-12-17T16:25:05Z

Re the fitted mesh issue, BUG-41063.
That bug doesn't reproduce will all fitted mesh, only some.
Would it be helpful to give more repro fitted meshes or are the sweatpants enough to see what the cause is?
Maybe it does reproduce with all fitted mesh & the ones that don't repro are just a baggier fit - I'll have to check that again....

Whirly Fizzle commented at 2016-12-17T16:37:25Z

@henri
I saw this post on your forum http://sldev.free.fr/forum/viewtopic.php?f=6&t=1702
I think this case may be that her shape has the torso muscles set over 50 and her shape will now render correctly on bento viewers because VWR-28308 has been fixed - her arms will be thicker on a bento viewer & the attachments will behave as in her images.
We've had a ton of reports of "broken content" on Firestorm bento that turned out to just be this.

Henri Beauchamp commented at 2016-12-17T17:45:13Z

I think this case may be that her shape has the torso muscles set over 50 and her shape will now render correctly on bento viewers because VWR-28308 has been fixed - her arms will be thicker on a bento viewer & the attachments will behave as in her images.

I won't call this a "fix", I'd call it a backward incompatibility, and therefore a breakage of existing contents... There have been quirks in avatar_lad.xml's joint positions for years (since SL exists !): there have been reasons for not "fixing" them...

Vir Linden commented at 2017-07-06T14:42:48Z

Our apologies, it appears this jira has been a victim of a spammer. We've cleaned up the offending comments, sorry for the mess!