I’ve been distracted on weekends, so I’m just getting to writing up the last of the news from last week (43). There is no great news, but there are some interesting things.
Large Group Edit
The code for this change rolled out Wednesday. It had problems and was rolled back the same day. It is however currently running on the Snack Release Candidate Channel. You can get the details of that in: Second Life Large Groups Edit Week 43.
Part of the reason for getting this change up and running is to get it where Third Party Viewer Developers can test their viewers against the new server code. To use the new Group Editing code on the server viewers need to change the viewer code. Getting the code on a release channels allows TPV Dev’s to get their QA people and Beta testers involved.
The package with the Large Group Edit code had a problem with the llSenor() function. It stopped returning a sorted list of objects. The sort is on distance. Not being able to figure out what is close or far meant breedables were not able to find food or each other… you know… to breed… The lack of loving was tragic.
The problem has been fixed. So, this week (44) we should see it move into one of the main release candidate channels.
The Friday decision is to roll the package running on Blue Steel and Magnum to the main channel. This is the one with changes for the new hardware. Users are not going to see changes from this package.
This channel should get a matenance package that has been in the works for some time.
Open Source Meeting Changes Time
It has been a bit confusing the last two weeks. Oz Linden is changing his working hours. He got a new home and apparently traffic during rush hour is now a problem. So, his life is altering to avoid that time waster. Living in large cities has its problems. Changing when one starts their commute can cut travel time a huge amount.
For now it seems the Open Source User Group will meet on Wednesday at 3 PM PT (SLT). That’s per Oz Linden as of Oct. 26.
Mono Spaced Text
If you make text pictures you understand the value of this requested feature. A resident named Stickman is proposing it.
I’d like to help work on a monospace font option with IBM PC ASCII box drawing characters for use in notecards and settext.
Notecards would get a simple checkbox at the bottom to toggle between monospace and regular. Settext would get a new function, llSetTextMonospace. Maybe there could even be llSetTextMonospaceTableFromList or -fromCSV, with a box style and divider style flags.
This would allow for much easier display of tables of information. It could even allow for things like an in-world forum HUD 😀
We will have to wait to see if this goes any where. There is no easy way to voice support for or against the idea.
There is some ongoing discussion in the JIRA about the Deformer. It is an old JIRA item and comments are still open. JIRA: STORM-1716. Darien Caldwell points out some of the known limitation of the Deformer. I suspect some of us are assuming others understand the limits. The expected limits are not all that obvious. So, I’ve quoted Darien:
You just have to realize the deformer project is really meant for clothes, as in things that cover the body. The big issue has always been body mass, breasts, muscles, stomach, butt, etc. Because of these issues, clothes literally can’t fit everyone. Or, creators have to make 500 different base sizes, or they have to spend all their time doing custom fittings. The deformer is trying to improve that. (Note: I say improve, and not eliminate).
Hands and feet have always sucked in SL, and frankly that’s not going to change with the deformer. The deformer isn’t smart enough to correct every issue that already exists with the hands and feet. The deformer will in fact be a crude imitation of their current state, at best.
But, the thing is, you can already do reasonably well with the hands and feet without the deformer. In fact you will achieve far better results with the hands and feet being non-deforming than deforming. This is a brutal fact.
As for facial expressions, the only way it will half [way] work is if you recreate the face of your mesh to be LL’s face exactly, vertex for vertex, and exactly the default size. Even then you will only get passable expressions.
Of course expressions have 0 to do with clothes. It’s just so far beyond the scope of the deformer, it’s a joke.
Darien has it pretty much correct. Retargeting animations and morphs from one mesh to another is VERY problematic.
Siddean Munro points out additional problems that are just part of the nature of 3D Character modeling:
It is also possible with a replacement face mesh that has been created using the default avatar shape as a base but doesn’t adhere to exact vertex position to use the facial expression morphs in the avatar to deform the face and in fact this has been working in previous versions (as has the hand deformation) because I’ve tested this exact thing in every previous version. I agree that the face and hands aren’t the prettiest, and using them to deform a custom avatar’s face and hands isn’t ideal, however, as it is, we can’t opt to use the deformer for the body and no deformer for the face and hands (for a custom mesh avatar) if you break the custom avatar up into body/head/hands/feet pieces, the body will deform and leave gaps at the neck, wrists and ankles. And if you don’t break them up, the face, hands and feet of the avatar deform the mesh accordingly. It’s a difficult problem to overcome, and not impossible with some lateral thinking, but saying there’s no case you can think of where it would be used like this doesn’t mean that there isn’t one!
Obviously it becomes a challenge when a creator wants the face, feet, and hands to NOT deform and the rest of the body TO deform. It’s all or nothing.