Day: October 26, 2012

Of mayflies and waterfalls

Posted on by Inara Pey

Today, and on a whim, I decided to drop back into Kitely and my home there – Fallingwater. It’s been a while since I’ve been back, as I’ve been busy in SL and elsewhere, and I didn’t really want to revisit until I’d got a couple of scripting issues sorted (still haven’t) and I’d decided on a suitable windlight preset (I have).

The Guest House

The windlight preset I’ve gone for – at least until I can get scripting issues sorted – is Bryn Oh’s “Mayfly”. I’ve opted for it partly because I love the sunset it provides, but mainly because I believe the dusk half-light it provides works well with the lighting I’ve installed in the house, which isn’t really suited to full daylight (again, something I hope to change in the future). As I want to be able to show-off the house, simply setting the region environment to night doesn’t work either, as people will likely flick over to daytime in their viewer. So my hope is that Mayfly will provide the best for everyone. I do tend to tink it does bring the place to life….but then I would, wouldn’t I? 🙂

Fallingwater

I also finally got around to putting in the footpath and steps from the drive to the river bank facing the house. This isn’t 100% to my satisfaction, and I’m liable to be returning to it and fiddling with things on-and-off, but it’s a start, and in slipping it in, I’ve gained a fair idea as to what I actually want to do when I have sufficient time to spare.

The Great Room and kitchen beyond

There are a few more things I want to do interior-wise as well. A couple of the rooms in the main house are a tad spartan, and the terraces could probably do with a little furnishing. Certainly, a few more pictures around the place would give more of a feeling of homeliness.

Foggy morning

I don’t know what the state-of-play is vehicle-wise in Kitely. I’m not actually after one for driving, but I can’t help feeling having a big old American 1930s Packard parked out under the rear car port would also add to the place as well.

Ilan has been asking my what I’d do if I had one of the new Kitely advanced megaregions. I think that if I did, it would likely become the home to not one, but four of my interpretations of FLW’s houses – I’ve always wanted to try my hand at the Robie House, and I have a couple of other candidates in mind as well. Although I think that were I ever to tackle anything so ambitious, they’d have to be 100% accurate reproductions, just for the heck of it :).

Fallingwater

Ah, well. Such is the stuff of dreams. In the meantime, if you’d like to visit the place yourself, please do. I did notice a couple more issues I need to fix in the place. You can reach it via my Kitely world page

Related Links

SL project news week 43/3: viewer status updates

Posted on by Inara Pey

SL Beta Viewer

A new Beta version of the beta viewer was release on the 24/25th, (3.4.1.266251), which has more-or-less the same visible changes as the previous release, except that tcmalloc has been re-enabled as LL seek to determine whether stability issues have been improved or not. However, given the high crash rates experienced with the previous release, Oz Linden is requesting people take time out to give the beta a run. Speaking at the OpenDev meeting on Thursday 25th October, he said, “Run the beta viewer a lot. We think this one will be good, but it takes a lot of usage to find that out and things won’t get unstuck until we do.”

Tcmalloc has been re-enabled with the latest beta release, and this probably means that those using cloud storage such as Microsoft Skydrive and others (such as Cloud Drive – see FIRE-7520 – are liable to encounter issues using it.

The intent at LL still appears to be the complete disabling of Tcmalloc from the viewer code, however, the attempts to do so to date have only met with partial success – the “fix” for MS Skydrive, for example, apparently only worked for some instances, not all.

Commenting on the situation at the OpenDev meeting, Oz said that efforts to completely disable tcmalloc are “taking too long”. As a result, and to prevent work with tcmalloc from adversely affecting attempts to stabilise the viewer, the decision has been taken to move the work on tcmalloc to a separate branch of the viewer code for the time being, with efforts on the beta branch focusing on stability.

In the meantime, code releases remain blocked, pending confirmation the beta release has improved on previous crash rates (which were around 14%).

Mesh Deformer Viewer

As reported in part 2 of this week’s project news, a new version of the Mesh Deformer project viewer appeared over the weekend – 3.4.1.266081, dated October 20th. In addition, Darien Caldwell has made updates to the SL wiki page on the avatar shape XML format which are related to the project.

The updated shape selection options for mesh clothing and human shapes in the mesh upload floater, as seen in the latest version of the Mesh Deformer project viewer

The current thinking is at present that the latest version of the viewer requires wider testing, so if you are involved in mesh clothing / shape creation (humanoid shapes, remember), then you might want to download the viewer and try it yourself. Commenting on the JIRA (STORM-1716), Darien notes:

If people could provide feedback on the use of the custom base shape part specifically, that would be great.

Keep in mind the potential bone length problems outlined above: do these affect your creations negatively when used with custom base shapes?

And is the potential workaround of setting bone lengths to the defaults a problem for your workflow?

Those and any other issues, please post. Thanks 

Initial feedback from those who have tried the viewer have been largely positive, although the issue with custom shapes and certain sliders, as previously reported in these pages (and on the JIRA) remain. Darien has been looking a little deeper into the latter issue, which affects a total of eleven shape sliders, and seems to have found the potential cause:

“The bone length deformation seems to be performed in the function LLRiggedVolume::update(). The deformer is doing its processing before this is reached, and when creating the custom base shape, it’s never run on that custom base shape. So the bone length deformations aren’t included.”

Instead, the current  deformer code assumes that all joints in a shape have the same scale, and that the scale is uniform in all axes. This is fine for a standard shape, but doesn’t work so well with custom shape forms, and wouldn’t work were scaled bones within avatar shapes ever to come about. The solution for this issue is unclear; the current plan is for Darien to write-up her findings for LL, so that someone there can look into the code as well.

The problem: bone length deformation is performed outside of the deformer code, which in turn appears to assume that all shapes use the same, uniform scale for joints. When working with a default shape, neither of these issues present themselves in obvious ways. When working with custom shapes, however, the problems become very evident. In this image a tall, then shape is use to generate an upper body mesh (flesh toned). When uploaded and applied to the shape itself (shown in black), the discrepancies become clear. Had the mesh been correctly deformed according to the shape data, it should more closely match the original shape

Group Services Project Viewer

Baker Linden’s server-side Group Services code for handling very large in-world groups was rolled out to four regions on the main grid on the 25th October, as reported here. However, due to the issues with the beta viewer code as reported above, testing of the new code requires the Group Service project viewer. If you do manage any group(s) with more than 10K members, you may wish to download the project viewer and give things a test on the nominated regions (see link above).

The viewer is available in Windows, Linux and Mac flavours.

Related Links