[Project Bento Feedback Thread]

https://gyazo.com/3b06ca6a0ac4ad4cf539e988931ad313

 

Here's an example of failed deformations, easily achieved by switching between a few mesh avatars that each have their own joint offsets. You're arguing against animating bone position presumably because it can be used to leave a user badly deformed... but the viewer does this all by itself. No animation was used to achieve this deformation. In fact, animations are used to FIX it. This feature should not be blocked.

[Project Bento Feedback Thread]

Unless Linden Lab has specifically tackled the problem of the viewer failing to load joint positions on an uploaded mesh, this is false. Because I am around animal avatars all the time, which have drastic differences in shape compared to the default human, I can very clearly see exactly how often joint positions fail. Moreover, joint positions will fail by viewer, so one person might see you deformed while you see yourself perfectly fine. Playing a backup deform animation which forces the bones to move into the position they should have ALREADY moved into based on the mesh's joint offsets completely fixes this problem, and should be allowed to continue as a backup measure.

[Project Bento Feedback Thread]

I agree on the digitigrade bone. I would love to see new optional bones inserted between ankle and knee and between head and neck, for those creators who would like to use them. These should not break existing content if they are kept locked at default position when not in use.

[Project Bento Feedback Thread]

I would really rather keep those "hacked" animations, since we were using them to fix what has been a problem with mesh joint offsets since the moment mesh launched, and has gone unfixed after numerous jiras and bug reports.

[Project Bento Feedback Thread]

After having browsed the various notes and wikis regarding the new changes, here are my initial thoughts:

 

- I wholeheartedly disagree with the decision to block animation of bone location - not only because very visually interesting animations can be achieved by moving a bone away from and back to its original location, but also because of the SEVERE problems with sorting mesh joints. Especially when switching from one mesh avatar with joint offsets to another mesh avatar with different joint offsets, the probability of seeing deformations has always been very high. More importantly, these deformations can be simultaneously seen by one user and not seen by another. To get around this, we avatar creators have put animated deformers inside our avatars which will play an animation that puts our bone joints where they should be when the avatar is worn, and play an animation putting the bones back in the default position when it is taken off. This way, even when SL fails to load the correct joint positions, the end user does not experience these unsettling deformations, and all users in the region will see that user exactly the same way. While my hope would be that you made absolutely sure to fix this problem before restricting the animation of joint location, I would still feel far better if you would re-enable it on release so I can continue to ensure a stable viewing experience for my customers.

 

- I think you've made good decisions with your bone selections, but I would like to request an additional neck bone for nonhuman avatar makers. I am presently working on one such avatar that uses two neck bones and a rigged face by locking the positions of the avatar shoulders to mTorso instead of mChest. If I am no longer able to animate bone location, I will have to choose between a fluidly animating horse neck or an animated face, and I hate to lose functionality in what is supposed to be an improved feature.

 

- I am absolutely giddy that the joint limit on a single animation has been raised from 32 to 106. Thank you.

[Linden Lab is building a NEW virtual world]

I can't say I'm looking forward to redoing the work either... especially since this news has come right in the middle of a massive update to my highest selling avatars, which bumps the workload on each of them from 8 months to 14 months. Having to redo it all again in two years' time is akin to a nightmare.

As for sims... I already know I won't be able to afford to keep sims in both worlds. I'll just have to wait and find out where the bulk of my customers will be, and have the sim there. It will be hard to maintain identity in both worlds without full sims, though. The way my sim is set up now, only about 1/16th of the sim is my main store. The rest is dedicated to hosting shops for the 80ish third-party vendors who sell accessories and addons for my mesh avatars. I'll be very sad to lack that kind of one-stop shop feeling on one or the other of the grids. It will be a difficult transition for some time, until one grid or the other shows dominance.

[Linden Lab is building a NEW virtual world]

Ebbe,

While catching up on the last 10 or so pages of posts which happened last night, I've noticed a lot of you saying, in essence, "SL1 won't change; if you don't like it, don't switch." I can understand the reason behind that response. I, too, am getting tired of reading dozens of rude comments by the same handful of naysayers. But, speaking as one of many content creators whose full real life income is earned from Second Life, this response isn't helping to build my confidence. Any way you look at it, the launch of SL2 will divide our user base between two virtual worlds. (Possibly four, depending on launch dates of High Fidelity and the Facebook virtual world project.)

I believe all that I, and several other creators in this thread, want to convey to you and the SL2 dev team is that we need as much backwards compatibility as we can possibly get between the two grids... because, for us, not switching is not an option. If we don't move forward to the new grid, we divide our income in half. Even when we do switch, we as creators will be slowed by having to format our products for two different worlds. We won't be able to put out items as quickly as we could. My avatar projects require a detailed rigged mesh, dozens of textures, 100+ animations, sounds, scripts, HUD designs, addons, accessories, and third-party creator tools to be made, as well as extensive bug testing. Each of my avatars takes me an average of 10 months to complete (working full time, because SL is my full time job). By the time I complete my next avatar, SL2 will be in beta. By the time I've finished the one after that, SL2 may be approaching its launch date. Will those 20 months of work still be worthwhile when SL2 launches?

I'm thrilled to see that custom skeletons are something that have appeared on your roadmap; I'm hopeful that this will allow a lot of re-use of older meshes and animations, and I look forward as well to seeing the improvements that can come as a result of that feature. I'm hopeful that SL2 can grow to be a wonderful thing, and I'm eager to see what you come up with. All I ask is that, as you move forward and lay the groundwork for this new world, you don't fall into the trap of "you don't have to switch if you don't want to". Make us WANT to switch. Make it EASY to switch. And put high priority on maintaining as much backwards compatibility with SL1 as you possibly can. Custom armatures will greatly help with reusing meshes and animations. What can you do to reduce the workload of re-writing scripts? How about textured clothing and skins? The idea posted earlier of allowing some sort of method of matching old SL1 content in users' inventories to new SL2 updated content is a good one. Please make the transition as painless as possible. Don't let yourself become dismayed by the panic; find a way to excite us. Be on our side. Because we, the creators who form the backbone of the virtual world, need to be on your side too.

[Linden Lab is building a NEW virtual world]

---

Ebbe Linden wrote:

You asked: 

1 - What type of assets are more likelly to be transferable to SL2 and what probably not? (meshes, animations, sculpts, scripts, textures, builds made of normal prims, system clothing ?)

We don't have all the answers to this one yet, but several areas will have radical improvements and thus not possible to be fully backwards compatible. 

Mesh is ok (but with better lighting and other tech you may want to make tweaks)

Animations will change (major mprovements as we don't currently do it the way it should be done)

Sculpts (TBD, but not as is, but maybe converted to Mesh?)

Scripts (major improvement, so will change)

Textures ok

Prims (TBD, but probably not as is)

Avatars will be radically improved as well so a lot TBD 

---

Let me start by saying... I'm thrilled to see news of a new, improved grid. I'm looking forward to seeing a lot of the changes we've been needing and have been unable to build on the old platform.

But... seeing that animations will change has made me very nervous. As a creator of mesh avatars which must be fully custom animated, you've just implied that my entire line of work may need to be redone for SL2. So this brings up one major question which, from my point of view, could be the single make-or-break factor for SL2:

Will mesh avatar creators finally be able to create and name our own custom armatures?

Providing this high-demand feature to mesh avatar creators could allow us to do so much - rigged mesh wings, tails, rigged faces, rigged fingers and toes. And (perhaps now more importantly) would prevent mesh avatar creators and animators from essentially having to start over on our creations.

Is custom armature creation a feature we can hope to see with the new grid?

[Issues with tiny mesh avatar z-offset]

I believe I've discovered the source of the problem...

In the test in the first image, I was wearing a shape which appears to have been more affected by the new z-offset "hover" property than other shapes I have (I don't know why...) After more research, I think some friends and I have pinned down the actual problem, at least to the point of producing predictable results.

 

The Z-Offset Bug:

This new z-offset bug appears to affect all mesh avatars which contain joint positions. It causes mesh avatars to sometimes appear floating in the air or sunken beneath the ground, most often by an offset of plus or minus 0.33 meters above or below where the avatar should display. 

What causes it?

If you were already wearing a mesh avatar and then wear another mesh by right clicking the single mesh object in your inventory and selecting "add" or "wear", your mesh will jump up in the air and hover approximately 0.33 meters above the ground. Your mesh may also jump or sink when you attach or detach objects to your mesh avatar.

How do you fix it?

• Change your shape (for example, wear a different copy of the same shape)
• Enter "edit appearance" mode and close it without saving any changes to your current shape
• Right click another folder in your inventory which contains a shape (for example, another copy of your horse avatar) and click "Replace Outfit"
• Relog

How do you avoid it?

• When changing between one mesh avatar and another, always use the "Replace Outfit" option instead of adding items one by one
• If you are adding objects one by one, apply your shape last
• If your avatar appears deformed and you must re-wear your mesh, use one of the four fixes above after re-applying your mesh to assure your feet get back on the ground

 

I've submitted a new jira on this issue. Here's hoping it gets fixed.

[Issues with tiny mesh avatar z-offset]

I've searched jira several times today for related issues; found this (https://jira.secondlife.com/browse/SUN-59) which appears to be the same sort of thing, but less severe. Can't seem to comment to add my two cents. At least I don't seem to be the only one who's noticed an issue.

Still, if anyone does come up with a reliable fix, I'm all ears. I've been trying all day to find a workaround. I have noticed that the hover slider appears to be limited by the distance between the foot bone and the pelvis bone; on my poor tiny ferret, with its small legs, it can hardly move down at all. It'll just snap back into place if I try to move the avatar lower than its foot bone (which seems to me like undesired behavior, since the z slider was implemented to compensate for the changes made to shape rendering in SSA.) By moving the foot bones lower than the actual avatar, I managed to increase the amount of distance I'm able to move my shape down, but doing so causes the avatar legs to warp and even move above my head.

[Issues with tiny mesh avatar z-offset]

For the past few days, I've been having issues with a tiny mesh ferret avatar I created, regarding the z-position at which different users see the avatar appearing. Each user seems to see the avatar at a completely different height: sometimes as high as 2.3 meters above or below the ground, while others will view the exact same avatar at the exact same time at a completely different location.

I first noticed that, when I wear the avatar and set the correct z position, my friends would tell me that I was below the ground... and when I relogged, I would appear below the ground for myself as well. Most commonly, relogging would drop my avatar about 0.33 meters downward. I thought 0.33 was the answer - position it 0.33 above the ground, and most people would view you normally.... but this wasn't the case. When I then set out to ask others where they saw me, I discovered as high as a 2.9 meter difference between what I saw (0.4 meters above the ground) and what they saw (2.5 meters below the ground.)

I've searched around for a solution to this problem, but can't seem to find one. I saw a few mentions of moving the avatar's pelvis bone to where a standard human's pelvis would be, but this had no effect; reported locations were just as varied as before. I uploaded 24 different mesh files with the pelvis bone all in slightly different locations to check if there was any visible effect in terms of the reported positions being closer together or farther apart, and found no notable difference.

I've also witnessed this behavior in a micro avatar I've had on the market for upwards of 6 months; there's never been any issues with seeing the avatar's feet planted firmly on the ground, until I tried it on again today. I assume this change has something to do with SSB, which just went grid-wide. All users who participated in my little experiment are on up to date, SSB enabled viewers - Firestorm 4.4.2, or second life viewer 3.6.3.

 

For a visual example of the issue, the following is an image of boxes rezzed to mark the apparent z-offset of my tiny ferret avatar. All of these were rezzed for the same exact avatar, which has a 0.0 offset applied to the mesh and no animations playing.

http://i.imgur.com/ENRaoAg.jpg

 

Are there any savvy tiny or petite creators who have already found a solution for this issue? I would hate to lose my work on this adorable little avatar due to an unexpected viewer bug.