Category: SL Tech

Belated avatar baking service update

Posted on by Inara Pey

The server-side elements of the new avatar baking service (part of the Shining Project) continue to progress, alongside what Nyx Linden has referred to as, “Some pretty scary viewer re-architecting” which is being undertaken by the Lab in order to try to isolate some of the avatar baking aspects from the rest of the viewer code base. As such, he’s anticipating the eventual code merge to be “fairly significant” when it does happen, although at the time of commenting (the last TPV/Dev meeting, September 7th), the code was not in a condition where it could be used by any of the TPVs.

Bake fail: a familiar problem for many

Overall, the viewer elements of the project are the priority, with the aim remaining to get the viewer code completed first, and to make it available to TPVs so that test viewers can be built. This is likely to happen before the code is ready for any formal release, the aim being to allow TPV devs to carry out test merges and to let LL know anything else has been broken as a result of the changes made to the code in order for the new service to work.

Once the code is available for testing both within the viewer and on test regions on Aditi, Nyx will be looking for “as many people as possible to pile-on” and test the code in order to see how the service works and how it may break, so that  by the time the viewer code is merged for release purposes, it will be as robust as possible.

Test Avatars

To assist with the work, Nyx is also looking for volunteers willing to take part in the initial round of testing using avatars wearing multi-layer outfits (e.g. outfits combining undershirt, shirt and jacket layers, etc; outfits using multiple elements of the same layer; outfits with system skirts and glitch pants, outfits using alpha and/or tattoo layers, and so on). Anyone interested in joining-in the testing should contact Nyx via e-mail or by sending him an in-world notecard, specifying the avatar name and details of the outfit itself. When volunteering, bear in mind that:

  • The outfit must be a Viewer 3 outfit, and your viewer must support the Current Outfits folder (which is used to drive the new service from the viewer end)
  • Testing will be on Aditi, and as such, the avatar and outfit must be available on Aditi. If necessary, you may need to update your Aditi inventory to make the outfit available.

Going Forward

The plan is still to have the new code support both the “current” method of avatar baking  and the new baking service, until such time as the new service is fully deployed. This means that if a user is in a region that does not make use of the new baking service, avatar baking will continue to be handled using the viewer-side mechanism. However, if the user is on a region that utilises the new baking service, avatar baking will be handled through that, with a flag set via the region capabilities being used to distinguish whether or not the new service is available.

There is still no definitive time frame for the project because of the complexity involved in both developing the viewer code (which is currently using a branch of the SL development viewer, but will obviously be moved to whatever code release is current) and with the development of the new server-side service. As such, it is still liable to be at least another month or so before the code is ready for significant testing on Aditi.

Related Links

This is a little overdue due to problems earlier in the week accessing the recording of the TPV/Dev meeting (which I was unable to attend in person). Thanks to Oz for sorting the problem out, allowing me to catch-up on overdue updates on this and JIRA matters etc.

More on materials processing

Posted on by Inara Pey

Materials processing was further discussed at the Content Creation Informal User Group meeting on September 11th. During the meeting, Oz confirmed that normal and specular maps will have their own rotation and offset controls from the start, which stands in difference to thoughts that they would initially be locked to the same rotation, etc., as the texture map used on an object or object face.

Materials processing: using a normal and diffuse (texture) map to generate a 3D effect on an in-world wall – coming to SL in the near future

This means that the new materials processing maps will have the same positioning and scaling properties are currently available for texture (diffuse) maps, namely:

  • Mapping: one of Default or Planar
  • Horizontal  and Vertical Repeats: number of repeats of the image over the surface (used only in default mapping)
  • Rotation: degrees clockwise by which the map is rotated
  • Repeats per Metre: number of repeats of the image per in-world meter of the surface (used only in planar mapping)
  • Horizontal and Vertical Offset: distance in meters the image is shifted right (horizontal) or up (vertical) on the surface.
Options to be used by normal and specular maps as well as by textures

This obviously increases the amount of control content creators will have over the additional maps once the new capabilities are live, but it does open up more issues around incorporating the capabilities into the build floater. Thus, it was the build floater which once again became the focus of the conversation during the meeting.

How the build tools are presented to users has already been the subject of much broader consideration within the CCIIUG, although that discussion appears to have stalled for the time being. The materials processing process, however, requires a more focused examination of the build floater in terms of enabling the additional controls without either making the existing floater too large or overly complicated.

As such, two ideas were briefly discussed at the meeting, and further input to them both will doubtless be sought. The first involved having the additional options contained within the existing Texture tab as sub-tab options, while the second involved having all of the mapping options (Texture/diffuse, normal and specular) and their associated positioning and sizing options moved to a dedicated floater of their own.

Of the two options, both have merit and pitfalls. Sub-tabs mean keeping everything together on a single floater, but could lead to things becoming cramped or possibly confusing. Splitting between two floaters would provide more space with which to present options and controls, but could lead to a reduced in-world view should people find they need to work with both floaters open.

Given the small number of attendees at the meeting, neither option was discussed in-depth, and so, as mentioned above, this is liable to be a subject which is returned to in future meetings.

Rendering Pipeline Changes

As a part of this project there will be changes to the viewer rendering pipeline. While the project is still some way off in terms of delivery, Oz Linden used the TPV/Dev meeting of September 7th to advise TPV developers that they will need to ensure they are current with the 3.3.4 rendering code, which will form the basis for implementing the materials processing system changes.

Oz also indicated that while it would be “quite a bit of time” before the project reaches a development or beta viewer because the overall specification is not yet frozen (but is, in his words, “Very, very slushy”), it is hoped that a project viewer would soon be available to allow the new materials processing capabilities to be seen and tested.

In referencing the release of a project viewer, Oz advised against anyone trying to pull the code and using it in any viewer intended for wide distribution. This is because it is possible the material processing capabilities may change in very significant ways before they are ready for more general release, leaving the code presented in any project viewer as limited in both value and function.

Accounting System Costs

It is still unclear whether the new materials processing system will fall under the new land accounting system in terms of server and rendering costs. While questions have been asked in this regard, no definitive answers have yet been furnished by LL. This again is potentially due to the matter still being under consideration and the specification itself still being revised as impact and changes are considered.

Discussions on the project will doubtless resume at the next CCIIUG meeting.

Related Links

Recent SL viewer activities

Posted on by Inara Pey

It’s been a while since I’ve reviewed any of the official SL viewers from LL, so here’s a quick round-up of recent releases.

New Log-in / Account Creation Prompt

The new account creation prompt, displayed if the viewer does not locate any user settings files on a computer, and which first appeared in the 3.4.1.263582 release (August 16th), now looks to be the default option for all development / project viewers. It is part of both the most recent Mesh Deformer project viewer (3.4.1.264215, August 31st), and the new HTTP Group Services project viewer (3.4.1.264495, September 7th). However, it has yet to filter through to either the Beta or release versions of the Viewer.

Account creation prompt: now standard on all development / project releases of the SL viewer released since August 16th (click to enlarge)

Mesh Deformer Project

August 31st saw a new release of the Mesh Deformer (3.4.1.264215), which includes a revised mesh uploader floater with deformation options for the male and female shape.

New deformation options

According to Nalates Urriah, the new options invalidate all test items so far provided for the project, and new samples are now required, although no comments to this effect appear to have been made on the JIRA or elsewhere, so they may have been confined to a user group meeting. Details on how to provide test items can be found in Oz’s forum post on the matter. The JIRA (STORM-1716) for this project is still open for viewing and comment.

Group Services Project Viewer

As noted this week, there is now a Group Services (group management) project viewer available for testing the new HTTP group management service. The server-side of this project has yet to be rolled-out to Aditi, so it cannot be tested as yet. However, Baker Linden, who is developing the service, is apparently updating the JIRA, SVC-4968 (which is still publicly viewable) with the project status, and has indicated he’ll post when the server-side elements are available for testing.

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

HTTP Libraries Viewer

The HTTP Libraries project viewer (3.3.3.262585) appeared on July 27th. This project, which Monty Linden is driving, is currently aimed at improving texture downloading and rezzing as a part of the Shining project.

HTTP Libraries project viewer: improved texture loading and rezzing

Texture loading / rezzing would appear to be significantly faster on this viewer compared with other offerings, although there also appear to be what might be placebo effects associated with it. Some people have reported that floaters, etc., seem to load more slowly, and some have reported various performance improvements outside of the HTTP library changes.

Beta Viewer and Release Viewers

The Beta viewer (3.4.0.264445 at the time of writing) continues to be focused on pathfinding, with fixes and updates going into it on a weekly basis – which is why the pathfinding tools have yet to release a release version of the viewer.  The removal of JIRA numbers from the release notes now means that tracking issues previously being watched is that much harder (even if the JIRA themselves are no longer accessible, having the JIRA numbers still visible facilities easier identification of issues being specifically tracked).

Similarly, the release viewer (3.3.4.264214) appears to be focused on bug fixes and general improvements, with the release notes currently benefiting from the retention of JIRA numbers, making scanning for specific fixes easier.

Performance

I carried out basic performance tests on the viewers listed above using Dimrill Dale as my sample sim, during a period when there were the same number of avatars in the region (5, including myself). Tests were carried out in the same location on the region, looking in the same direction and with the same viewer settings (e.g. Graphics on high, Draw Distance set to 260m, using default time-of-day, with deferred disabled / with deferred enabled and lighting set to Sun/Moon+projectors, etc.). While all such tests are rough-and-ready, these did tend to show that all of the viewers offer the same performance on my default PC (see the sidebar panel on the right of this blog’s home page for system details). My results were:

  • Non-deferred: 18-20fps
  • Deferred with Sun/Moon+ projectors: 8-10fps

Similar figures were also obtained using the current Firestorm and Exodus viewers, although with deferred enabled and Sun/Moon+projectors active, Firestorm was slightly down at an average of 17-18fps, the other viewers being closer to an average of 19-20fps.

Viewer release summary 2012: week 36

Posted on by Inara Pey

This summary is published every Monday and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:

  • It is based on my Viewer Round-up Page, a list of  all Second Life viewers and clients that are in popular use (and of which I am aware) and which are recognised as being in adherence with the TPV Policy
  • By its nature, this summary will always be in arrears
  • The Viewer Round-up Page is updated as soon as I’m aware of any releases / changes to viewers & clients, and should be referred to for more up-to-date information as the week progresses
  • The Viewer Round-up Page also includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog.  

Updates for the week ending: 9 September, 2012

  • SL Viewer updates:
    • Current release rolled to 3.3.4.264214 on September 5 – release notes
    • Beta version rolled to 3.4.0.264445 on September 5 – release notes
    • Development: rolled to 3.3.5.264487 on September 5
    • Group Services project viewer 3.4.1.264495 released on Sept 7, but awaiting server-side roll-out on Aditi
  • Zen Viewer rolled to 3.4.1.1 on September 7 – core updates: Flickr upload option added to snapshots floater; Latest Mesh uploader with avatar shape deformation; whisper/mumble option for OpenSim; performance updates – release notes
  • Cool Viewer:
    • Stable branch rolled to 1.26.4.29, on September 8- core update: Re-reverted to v3.4 latest fixes to llTargetOmega()
    • Experimental release rolled  to 1.26.5.8 also on September 8 – core update: Fixed the bug that caused objects not to be rendered in sims with mesh support disabled (such as in Inworldz)
    • Release notes for both
  • GroupTools rolled to installer release 2.2.10.0 on September 5
  • LittleSight Android client rolled to version 1.3.0 on September 9 – core update: addition of pay-to-teleport function.

Related Links

Group management project viewer released

Posted on by Inara Pey

As I recently noted, Baker Linden has been working on the large group management / editing issues, developing a new HTTP-based service to replace the current UDP service which has significant issues handling groups with more than 10-11K members. At the TPV/Developer meeting on the 24th August, he indicated that a project viewer would be available in the near future.

On Friday September 7th, he updated the JIRA on the issue with notes that the project viewer is now available for Windows, Linux and OSX.

In commenting on the JIRA (SVC-4968), Baker notes that the server-side code for the new service has yet to be deployed to Aditi, where initial testing will take place, and adds that he’ll be providing an update on the status of the server code once the situation has been clarified. He goes on to add:

There may be some issues during testing. When getting the member list of a large group, other info (group title, group info, etc.) may not properly load. This is an issue with the speed of Aditi’s SQL server and shouldn’t occur once live on Agni. To receive the rest of the data, wait for the member list to appear (this can be upwards of a few minutes), go back to the My Groups panel of the people floater and view the group profile again. The query will be cached this time, and the member list will appear quicker than it did before (depending on your connection speed). The rest of the information should be received this time.

If you find any problems while testing, please send me a message in-world (on Agni).

Large group loading: part of the group management problem

As noted in my previous report, in the first implementation, the data will be uncompressed. This means there will still be some delays in group loading (Baker previously estimated that a 40K member group is around 5Mb in size and could take up to a few minutes to download, depending on someone’s connection speed). Data compression is being looked at for a future release, although as noted in the comments on my last article, some are wondering why paging group data isn’t being implemented (does the viewer API support it?).

Another point of note is that the new service is not compatible with V1 code, so adoption by V1-based viewers is liable to require some backporting. This is important, as once the new HTTP service is rolled out, the older, more limited UDP service will be capped at groups containing 10,000 members – larger groups will not function.

There is still no definitive time scale for the roll-out of the new service. However, it seems likely that once available on Aditi, the server code will remain there for testing for at least a couple of weeks prior to it being added to a RC channel on the main grid. How long the testing period across both will be is open to question, and a lot will depend on feedback as to how well the new service performs.

Firestorm’s 2 and 1: celebrating the highs and lows of a TPV

Posted on by Inara Pey

Firestorm achieved a number of significant milestones recently, all of which are worthy of note.

  • On Sunday September 2nd, the viewer was officially two years old
  • On Tuesday September 4th, version 4.2.2.29837 officially achieved the lowest crash rate for any V2/V3-based TPV at just 8.54%. This is even lower than LL’s own 1.23.5 viewer, which although long in the tooth and increasingly out-dated, is still regarded as very stable.
Extract from the Third-party Viewer directory listing, showing the most stable viewers at this time

Also on Tuesday 4th September, the team received official notification from LL that Firestorm has taken over from Phoenix as the most popular viewer in use in Second Life. This was marked by Oz Linden putting out an e-mail through the open-source development mailing list:

“On behalf of Linden Lab, I’d like to extend congratulations to the Firestorm Viewer team.

Last week, Firestorm took over the #1 spot on the list of Second Life viewers in terms of total user time, surpassing its elder cousin, Phoenix. The Phoenix viewer still has a slight lead in number of sessions, but Firestorm viewer sessions are on average significantly
longer – which may in turn be due in part to its substantially better stability.

“The Firestorm team has worked long and hard to support users who want both the latest Second Life features being developed by Linden Lab and the additional capabilities you provide, and this achievement is one you can all be proud of.

“Thank you.“

Congratulations to everyone at Firestorm for all the time and effort devoted to the project.