Category: SL Tech

SL projects update week 42 / 1

Posted on by Inara Pey

Server Updates

The main channel deployment took place as planned on Tuesday 16th October. As previously indicated, this was the code deployed to the BlueSteel RC channel in week 41 (essentially an improved database query that should help with the back-end system load).

Of the Release Candidate channels, these are due to be updated on Wednesday 17th October as follows:

  • Magnum – will not receive an update, but will continue to run with the code deployed in week 41, probably in the same configuration
  • BlueSteel – will get code that’s almost the same as the main channel, with some OS-level configuration changes that shouldn’t be visible to anyone
  • LeTigre – will be getting a minor update to the Havok library which is mostly about getting our servers to build under Visual Studio 2010 on Windows and autobuild on Linux.

The LeTigre update will use “slightly newer” versions of the Havok libraries, so concerns were raised at the Server  / Sim meeting on Tuesday 16th October as to whether this may lead to a resumption of the problem with mesh vehicles being unable to travel between regions running different versions of Havok.Andrew Linden confirmed this might well be the case for mesh vehicles moving between LeTigre regions and other regions following the deployment.

To help reduce issues with situations like this arise, it was suggested that areas such as the Blake Sea regions are either removed from the RC channels, or placed on the same channel. While this would not solve the problem grid-wide, it would reduce the impact somewhat for people using mesh vehicles in these regions. A query was put to the LL deployment team on this by Andrew Linden, and they  agreed to try to make the Blake Sea regions more homogenous by ensuring they are all on the same channel.

SL Viewer

A further stability test build for the beta viewer was made on Friday October 12th, and reached the download page on Tuesday 16th (3.4.1.265898 – release notes) after being cleared by QA. This should be the last stability test release and should see the OK for code merges to resume. Merges and release priorities are still being looked at, and speaking at the Open Dev meeting on Monday 15th October, Oz indicated that there are “a few open source contributions in the pipeline that are in the mix”, as well as the anticipated LL merges such as the Steam code, Monty Linden’s HTTP library updates, Baker Linden’s Group Services project code, Apple OSX Mountain Lion support (including gatekeeper compatibility), etc.

Kelly Linden reports fixing SVC-7870 (Edit Linked Parts isn’t returning creator/owner), but given the current backlog, it may be a while before this makes it through to a beta  / release viewer.

Avatar Baking

The aim of this work (Project Sunshine) is to improve issues around avatar baking and to eliminate bake fail issues. It will primarily focus on moving the emphasis for the baking process from the viewer to a new Texture Compositing server. The viewer will retain some elements involved in avatar baking – the actual baking of the avatar shape (i.e. shape values and IDs) will still take place on the viewer side, for example.

As of Monday 15th October, no major news. Commenting at the Content Creation / Mesh Import meeting, Nyx Linden said, “Still plugging along at it :). It’s a complex project with many moving pieces, we’ll let you know when there are updates, and I will definitely be asking for beta testers here when we’re ready for feedback”.

Interest Lists and Object Caching

The focus of this project is to optimise the data being sent to the viewer, information already cached on the viewer and the manner in which that data is used in order to ensure it is used more efficiently so that things rez both faster and in a more orderly manner than is currently the case.

Interest lists and object rezzing: ironing-out the bugs, wherever they are

Andrew Linden continues to iron-out the bugs in the interests lists project, including one in the main viewer codebase wherein after crossing a region boundary the connection to the region you were just in will get reset after about 60 seconds. This is impacting the interest lists work and requires resolving, so Andrew is currently focused on trying to sort it out. A problem has also been reported with objects rezzing in the test regions on Aditi (e.g. Ahern) when moving through them in a vehicle, and will be looked into.

Pathfinding

A question was raised at the Content Creation / Mesh Import meeting on the 15th October as to why a 1-prim pathfinding character  has a land impact of 15. The reason for this is due to the increase physics load on the character. As previously covered, while this may seem harsh, it actually means that characters with a much higher prim count will also have a land impact of 15 (for example, a 30-prim character will still only have a land impact of 15), unless other factors (such as streaming cost) come into effect.

There are a couple of other issues with pathfinding characters which are being (or are about to be) looking at:

  • A bug whereby copies of single-prim characters only have a land impact of one (not 15). This problem is being addressed under PATHBUG-194.
  • A problem wherebypathfinding characters suddenly appear to “fly away” when adjusting your camera position, almost as if they are suffering from lag, and then reappearing there they should actually be (I gather this tends to happen when looking at a pathfinding character, which is following a set path then turning the camera away and then back again). Andrew Linden believes the problem is related to interest list updates, and will be looking into it.

Mesh

The patch to enhance the mesh uploader when dealing with rigged mesh items was discussed at the Content Creation Mesh Import group meeting on October 15th, with Nyx expressing interest in the idea, and agreeing with a suggestion that the patch needs to be formally submitted to LL’s bit bucket repo applied to a cloned version of the development viewer, supported by a JIRA outlining the patch and with a link to the repro.

Mesh uploda enhancement: suggested that it is submitted as a patch to LL

SH-3055 is a bug relating to mesh uploads which has been around for a while, but which appears to be affecting more people of late. With it, mesh uploads fail without any error message or warning on clicking CALCULATE or UPLOAD on the mesh upload floater. The issue is hard to track down (or even reproduce) as it doesn’t occur with any consistency. Either the upload works, or it simply sits as if waiting for something – whether it is waiting for data to be returned by the server, or whether it is receiving information and failing to action upon it.

Darien Caldwell and Nicky Dasmijn have been working with a debug viewer in an attempt to pin the problem down, but so far without success. One school of thought they are pursuing is that it is a problem with the viewer’s cURL wrapper (which is also thought to have been responsible for the recent crash issues being experienced in the beta viewer). The thinking behind this is that the problem appeared to come about with the introduction of a multi-threaded cURL in v3.2.5 of the viewer – with 3.2.4 having exhibited no major issues with uploading.Nyx Linden has stated he’ll take the problem to the team work on cURL to see if they can identify anything.

Materials Processing

No further updates. When talking to Geenz Spad and Oz Linden on Tuesday 16th October, Geenz could only say, “There’s not much to really report on materials for the time being unfortunately, but when there is something I’ll be more than happy to tell everyone.” Oz then added, “We’ll do more than tell you – we’ll give you something to play with :-)”.

Network Pile-on Test Update

Commenting on the thread for the pile-on test, Oskar Linden said: “All of the tests passed and the code will be going to RC next week. Thank you all for your help!”

With thanks to Baz deSantis for information on the Sim / server Group meeting.

Viewer release summary 2012: week 41

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: 14 October, 2012

  • SL Viewer updates:
      • Beta version rolled to 3.4.1.265642 on October 8 – core updates: stabilisation / crash fix test version with tcmalloc removed(download page; release notes)
      • Development version rolled to 3.4.2.265762 on October 11
  • Dolphin rolled to 3.3.22.24794 on October 11 – core updates: Autoplay button and Network statistics bars hide properly in mouselook; A new setting in Preferences->Dolphin Viewer 3->UI that allows the user to disable the avatar name in the window title
  • Niran’s viewer rolled to 2.0.2107 on October 12 – core updates: fix for shadows incorrectly rendering at 140m+; fix for the scripting editor
  • Cool VL updates:
    • Stable branch rolled to 1.26.4.33 on October 13 – core updates:Incorporation of Group Services code; removal of tcmalloc from Linux version; improved texture memory usage throttling algorithm; private memory pools now off by default; initial backport of Media on a Prim (currently disabled pending further work); new “Media Updates” fast timer implemented; backport of latest bugfixes from viewer-development and viewer-beta; minor code changes and optimizations
    • Experimental branch rolled to 1.26.5.13 also on October 13 – core updates: removal of tcmalloc from both Linux and Windows versions; otherwise as for Stable branch
    • Release notes
  • Mobile Grid Client updated to version 1.19.1173 – support for Android v3 (Honeycomb) and v4 (Ice Cream Sandwich)
  • Group Tools release version 2.2.14.0 on October 14. No details on updates or fixes
  • Libretto – removed from round-up page due to website being unavailable for a month and no response from creator on status (also removed from the SL Third-party Viewer Directory)

Related Links

Piling it on: the network optimisation tests

Posted on by Inara Pey

Thursday October 11th saw a huge response to Oskar Linden’s request for assistance with network optimisation tests, with many people logging-in to Aditi to join is Beta User Group meeting (I actually made it for the first time myself, the time of his meeting is generally a little awkward for me). More were available on the IRC channel established for the test as well.

Oskar’s meeting place at Morris on Aditi.

Things got off to a rocky start; mid-way through the Beta UG meeting everyone received the royal order of the boot, and problems occurred attempting to log back in. It transpired that an SSL certificate had expired at LL’s end and had to be renewed (through until 2015). Even so, not everyone appeared to make it back (or at least, not with their primary accounts!). Maestro Linden did make it back with the rest of us, and immediately sought protection in a state-of-the-art anti-crash system from Ordinal Malaprop* created (or is that crated?). No amount of coaxing could get him out, either:

Darien Caldwell: you can come out of the box now Maestro. Crash is over ;p

Mæstro Linden (maestro.linden): I’ll come out when I feel safe 🙂

People getting back after the crash and finding we have a Maestro Linden-in the-box

The meeting also had some disruption from an unhappy camper or two complaining about bans. One of them made it back following the initial forced log-out, and as final preparations were made for the test, appeared to successfully crash the region. Shortly before this happened, concerns were raised that this individual may have been trying to disrupt the IRC test channel, as they appeared to be passing commands aimed at IRC in local chat (at one point a little later, a similar command appeared in the IRC channel, and I and a number of others were, coincidentally or otherwise, disconnected).

The testing itself proceeded pretty much as planned, with everyone logging-in to a specified region at more-or-less the same time, testing the network capabilities in handling a large number of log-in updates in a single region. From my perspective, this went well, and as one of the initial people to log-in, I didn’t appear to suffer from the kind of lag usually associated with moving around in a region where there are a large number of people arriving.

Following the en-masse arrival, we dispersed to two regions for a group chat load test. I cannot actually say how this went, as I arrived at my designated region, only to take three steps and crash (an issue at my end of the SL equation rather than anything else).

I made it back to participate in the IM tests, which comprised piling-on a mass of IMs to targeted avatars and then awaiting their reply. I think I was one of the first to IM and one of the last to get a reply, Again, not through any failure in the system, but simply because Pey’s Law affected the tester I was IMing – he replied on receiving my first message, but forgot to press ENTER to send :).

The final part of the test was a mass teleport to a specified region, again presumably to test how the network handled a large number of arrivials within a region. While this may have been a placebo effect from being on Aditi, the teleport itself seemed to me to be somewhat faster than is usual, with the progress bar merely flicking up on the screen and then vanishing as I arrived. Once, there I also found walking around with people people teleporting-in also did seem to be as prone to mini-freezes or stutters as can be the case. However, the load on the target region (selected at the last-minute due to problems with the intended destination) may have been lighter than hoped, as it had a cap of 21 on the number of avatars allowed into it, and a number of people did report they were unable to teleport-in as a result (there were probably around 40-50 listed on the IRC chat page).

Pile-on Test Medal

Overall the tests made for a fun social gathering, with a lot of good humour all around, and Oskar and his team apparently gathering the data they wanted.

Hopefully, there will be further follow-up on the overall intent of the tests and the results in an upcoming Sim / Server UG meeting. Oskar certainly appeared pleased with the outcome, and was on the main grid after the tests to hand out medals to the participants (providing they knew the sekrit password! 🙂 ).

 * With thanks to DD Ra for pointing this out; I missed checking the creator details earlier.

SL projects update week 41 / 2

Posted on by Inara Pey

This item is a follow-on from part one, published earlier this week.

More Server News

At the Thursday Beta Grid User Group meeting (Thursday October 11th), and prior to the network optimisation tests, Oskar gave further news in the  serve deploys for week 41. On Tuesday 9th October, the main channel received code previously on BlueSteel, which in keeping with Simon Linden’s comments at the Monday Sim / Server UG meeting, Oskar referred to as being, “A pretty small release, just some server crash mode fixes; stability ++.”

On Wednesday October 10th, BlueSteel and LeTigre received a fix to some database queries that were really slow when accessing really large groups (note these were not Baker Linden’s Group Services code, that is being looked at as a deployment in week 42).

Monday 16th October may see some restarts on the grid in order to shuffle some regions onto new hardware, with the servers having more and faster CPU cores, which will increase the number of simulators running on the new servers, but they’ll be running on faster CPU cores.

Interest Lists and Object Caching

The short-version update for this comes from Andrew Linden, speaking at the Server Group meeting on Friday 12th October, “I thought I’d have something working this week… it isn’t quite working right. You can see it not working on Ahern on Aditi…” (!)

Interest list changes: easing the pain of random rezzing

He went on more seriously to explain that while the new code is working correctly for the most part, and that rezzing orders should be improved / faster, there are some problems with objects which should be in view of an avatar not showing up and a major issue around teleporting into high ground.

When the latter happens, you effectively arrive “underground” (presumably at the default “ground level” for the simulator  – 21 metres in the case of unterraformed land). The simulator then calculates where you should be and moves your avatar appropriately. With the new code, this has the effect of breaking the server’s notion of the camera – where it is and what it can see – which is used to figure out what objects to send to the viewer. This means that the camera itself cannot be moved or updated.

There have been some performance tests on an older version of the code, which have been mixed, as Andrew also explained, “here were two performance tests run on an earlier version. One test (mostly empty region with about 30 avatars running around) showed a slight decrease in performance… about 5% worse. Another test (crowd of avatars NOT looking at a pile of dynamic objects behind them) showed about 40% improvement (less time spent running the interest list). So I went back to the code to try to fix the first test, and I think I’ve got something that will be as good or better all around.”

The code will also see changes as to how the camera behaves and in the resultant level of detail. Andrew is currently working on limiting the distance the camera cam be moved away from the avatar. Note this is not limiting Draw Distance, but limiting the distance the camera can be freely moved independently of the avatar. He’s considering 128 metres to be the likely range. There are two reasons for this.One is to prevent the camera wandering into regions which are more than one neighbouring region away, the other is because as the camera moves laterally, detail levels degrade, because object detail is tied to the avatar’s position (hence why, when you zoom a great distance, buildings and objects may only appear to partially rez, etc.). Under the new system, object detail will be tied to the camera, so that little degradation is experienced. However, in order for this to work, the camera must be kept within a reasonable distance of the avatar; if it is moved too far, the detail will start to degrade once more (presumably because of the volume of data the viewer is trying to handle).

Mesh Deformer

On Thursday 11th October at the Open/Dev meeting, Darien Caldwell outlined her ideas for using base shape info exported from Second Life when uploading rigged meshes.

If this works, it will essentially mean that rather than being restricted to using a default base female or male shape when uploading rigged meshes, creators will be able to download a human shape as an XML file (permissions allowing), and then specify this shape when uploading rigged meshes.  The basic code for handling the upload with specific avatar shape information has already been added to the deformer by Qarl Fizz, so Darien is focusing on the best way to use it, her work going into a fork of the existing Mesh Defromer project viewer.

Avatar shapes can currently be exported from a viewer via DEVELOP -> AVATAR -> APPEARANCE TO XML (again subject to the permissions system). This saves the avatar shape data as an XML file, which contains the settings from the appearance sliders, and which is automatically saved to your computer (generally to  C:\Users[USERNAME]\AppData\Roaming\SecondLife\user_settings for Windows).

To associate an avatar shape .XML file with a mesh, Darien is proposing a further revision to the mesh uploader floater, and has provided an early mock-up as to how it might look.

New option to associate an avatar shape XML file with a mesh on upload (image courtesy of Darien Caldwell)

More work is required the flesh-out this idea, including, as Oz noted at the Open/Dev meeting, making the shape export option more obvious for people to use, which will more than likely see it moved out of the Develop menu, wherein it is currently nested. The .XML file itself is not suitable for use directly in most 3D modelling programmes, so how the exported data might be used with these when creating mesh items remains to be seen. nevertheless, if successful, Darien’s approach may offer a more fine-tuned solution to developing mesh clothing to a range of shapes.

Other items

Viewer and FMOD

The use of FMOD has been the subject of much discussion within the TPV/Dev meetings of late. FMOD is used within the sound system for the Viewer, and until now, Linden Lab has provided a script which pulls library files from an FMOD repository for use in viewer builds. However, following what appears to have been a clean-up of their archives, FMOD have removed the some of the legacy files required for this, as reported in JIRA OPEN-150.

Some viewer developers have already started using FMODex within their builds (e.g Singularity 1.7.0+), which also addresses issues with sound quality as well. Other TPVs are looking at possibly integrating this work into their builds.

It currently appears as though Linden Lab themselves are looking to integrate FMODex, as they see this very much as something which needs to be addressed. Speaking at the TPV/Dev meeting on Friday 5th October, Oz Linden stated: “I got around to forwarding the JIRA on that to our engineering manager for Second Life, and he agreed with me that it is something we should definitely do something about. I’m not sure what the time-table on that will be, it’s going to go into the hopper for the next ‘Things we should do something about, what priority are they compared to all the other things we should do something about’ meeting, which happens weekly.” While openAL has also been suggested as an alternative, it does seem more likely that FMODex will be adopted, something which was hinted at by Oz when talking at the Open/Dev meeting on Thursday 11th October.

Teleport Timeouts

Baker Linden has been looking into the issue of teleport timeouts, and has managed to pin down one cause as a reproducible bug. He’s not sure as to whether it can be fixed, and is currently investigating further as to why it is happening.

 

SL projects update week 41 / 1

Posted on by Inara Pey

Server Deploys

The main channel today received the same maintenance release made last week to BlueSteel (and which was used to help fix the LeTigre problems). speaking at the Server / Simulator User Group, Simon Linden described the deployment as, “A very minor change … from one of the RCs. It’s really not any functional change but was needed to go grid-wide before another one goes into RC.”

Following week 40’s issues with LeTigre, the three primary Release Candidate channels will be getting updated as follows:

  • Magnum, which has code to help sims run better on new hardware,  will be getting the same change that went to the main channel
  • BlueSteel and LeTigre will get the same update, which is described as “pretty minor but important”, being a back-end query optimisation designed to assist with database loads.

Currently, the prim accounting issue is still being worked on, which affecting scheduling what will be available in deployments. Passing comment on how deployment packages are put together, Simon explained that, as a rule, bug fixes tend to be put together as far as possible, prior to going to QA and then to an RC channel. He went on to say that what goes into other releases can be variable, “There’s a judgement call on how much gets bundled together, and a bunch of things go into the decision, like how overloaded the QA guys are, how many other things are trying to get to RC, risks of one part blocking it (like now), stuff like that”. In the meantime, LL are actively looking at ways to both prevent a recurrence of this problem and to improve the RC channel deployments as a whole.

SL Viewer

The promised new beta release (3.4.1.265642) reached the release point on Monday October 8th. This release sees tcmalloc disabled once more,  but otherwise appears to be the same code as the previous beta. It is intended to be a further stability testing / confirmation release, and as such will remain available for the next couple of days as Linden Lab gather data on its performance.Tcmalloc has been disabled, rather than removed, as it has apparently been useful in helping to trace issues within the viewer code, and LL wished to retain the ability to re-enable it in case they needed to re-enable it to help identify problems within the viewer in future.

Assuming this release proves stable, and assuming that plans outlined by Oz Linden have not undergone significant change, it should clear the way for the unblocking of various code merges that have been awaiting the stability / memory leak issue to be resolved. As previously reported, the precise order in which code merges will be made / released is unclear, but Linden Lab have a significant amount of updates waiting in the wings, including Steam support changes, Monty Linden’s HTTP library updates, Baker Linden’s Group Services project code, Apple OSX Mountain Lion support (including gatekeeper compatibility), and more.

Steam updates – one of the viewer merges waiting to be released

Under the original plans for the beta viewer, project viewer code was to start merging into the viewer with the 3.4.2 release code. As there was no OpenDev meeting on Monday 8th October, it is assumed this is still the case, however, the precise order of the merges is due for discussion this week within the Lab, and a clearer indication of the order may be available by the Thursday OpenDev meeting, and will be given in part 2 of this report, if that is the case.

Group Services Project

Due to the problems experienced with the leTigre deployment in week 40, Baker Linden’s Group Services code did not receive a proper deployment to a Release Channel. It is not due to be released this week, but should be in an RC deployment aimed at week 42, although as it has been bundled with the LeTigre deployment which had problems, this may be delayed further while the prim accounting error is looked into.

It is currently unclear as to whether the delay with the RC roll-out will influence when the Group Service viewer code (currently available in a dedicated project viewer) will be merged into the development  / beta branches of the SL viewer code; again more should be known on this following Thursday’s OpenDev meeting.

Materials Processing

Continues to progress, with little to report at this time. The feature set for the initial release still has yet to be published, and the wiki page for materials processing is due for further update. Concerns were raised over one statement relating to the use of colour, to whit:

“Color a solid color for the surface; not used if a Texture is also specified.”

The concern was that whereas it is currently possible to specify both a texture and a colour for a given object or object face, the wiki implies that under material processing, it will become either / or. However, this appears to be an error in the wiki, and both options will remain available.

Linkability Bug

As reported in my last update, and while not strictly a project, the bug which is currently allowing prims to be linked over distances greater than 54m has been investigated, and a fix is expected to be rolled-out to the RC channels for this in week 42.

 

Lumiya 2.3.1: avatars, animations, outfits and more!

Posted on by Inara Pey

Alina Lyvette is a miracle worker. There is no other way to describe her. Since its first release, her Lumiya client has developed into a mobile Second Life / OpenSim client which is truly remarkable.

From humble beginnings just seven months ago, Lumiya has quickly grown in both capabilities and stature, just some of the highlights being the addition of in-world rendering (with in-world object interaction quickly following), inventory management, OpenSim support and a whole new look also packed with goodies.

Version 2.3.1 raises the bar even further, adding:

  • Avatar and animation rendering
  • Camera control in 3D view
  • Avatar outfit control
  • Ability to change active group
  • Improved inventory update speed
  • Issue fix for ghost objects.

Avatar and animation rendering

This is the most visible change to Lumiya with this release. Whereas previous versions only generated a greyed-out male avatar form, this version aims to render recognisable avatars and provide them with a decent walk animation. Now, the results aren’t 100% like-for-like with avatar rendering in a full viewer – and in fairness, you shouldn’t expect this to be the case. Even so, what is offered is really remarkable, and adds a huge depth to Lumiya in terms of offering mobile access to SL and OpenSim.

Avatar rendering: Lumiya (l) and an SL viewer (r)

There is a little of the Unity feel to the avatars, particularly in the exaggerated arm length, but overall the results really are impressive. And default walk animation is very good as well, and again adds a lot to the in-world experience; no more gliding ghost-like around.

Camera Control

Camera button

Version 2.3.1 adds camera control to Lumiya’s 3D view. This is accessed using the CAM button located in the bottom left of the in-world view.

Tapping this allows you to alter your camera angle / position simply be dragging your finger across the screen or up / down.
When tapped, the button caption changes to WALK, indicating that the next time you tap it, it will toggle back to WALK mode, allowing you to move your avatar, and the camera will snap back to the default rear view.

You can also use the arrow keys to the right of the in-world view when in CAM mode . The left / right arrow keys will orbit the camera around your avatar, while the up / down keys will zoom your view in / out.

Outfits Folder Support

Alina is working towards providing compatibility with the upcoming new avatar baking service Linden Lab are working on. This work involves support for the Current Outfits folder, and as a first part of that, Lumiya incorporates Outfits Folder support within the 3D view. currently, the functionality doesn’t support sub-folders within outfits, which limits its effectiveness for those who have invested heavily in organising their (My) Outfits folders, but Alina is aware of this, and will be addressing matters in the future.

Change Group

You can now change your active group tag within Lumiya. Simply go to the Chat screen, tap GROUPS, and then long touch the name of the group you wish to set as your active group. A pop-up will be displayed asking you to confirm, and on doing so, your active group will be changed. Simples.

OpenSim Issues

There were reports of crash issues with 2.3.0 on OpenSim, and Alina issued 2.3.1 to fix this. Both 2.3.0 and 2.3.1 functioned very smoothly for me, although I did encounter an issue on Kitely in that the skin and system layer clothes on my avatar would not rez (although her prim hair did) and she remained a white cipher.  Other than this, however, Lumiya worked as well with Kitely as it did for SL, and I had a pleasant several minutes simply camming around and taking a look at Fallingwater, something which hasn’t been easily achievable on Lumiya in the past without a lot of walking aroundand looking over my own shoulder :).

Performance

Lumiya is doing a lot of work for an app designed to run on a mobile device  / tablet. As such, don’t expect performance to match a standard viewer when on a wifi connection. That said, as I’ve commented on my previous Lumiya reviews, this doesn’t mean it is a slouch. While there can be pauses when handling large updates, it still runs more that comfortably on my Galaxy S2, and others have reported it runs at least as well on a number of other modern phones. Rendering is not that slow (avatars can take time to load, and this does admittedly take time in a crowded location), but on a wifi connection, it is still possible to use Lumiya with ease and see people, chat, move around and interact.

When connected to a 3G network (UK O2 network), bandwidth usage was slightly up on previous versions, with 2.3.0 hitting 2.6Mb in five minutes, compared to an average of just on 2 Mb with previous releases. I assume the additional use is down to avatar rendering data – so if you’re using Lumiya on 3G and in a crowded space, you’d best keep more of an eye on bandwidth use.

Having several other avatars in mt draw distance also impacted performance (unsurprisingly – it does on all viewers), so if you are again in a crowded place, you might want to keep DD right down (although a cap on the number of avatars Lumiya will attempt to render might also be a good idea).

Opinion

Alina’s work on Lumiya never ceases to amaze me, and this release really is quite something. The avatar rendering is phenomenal, and the camera movement options are both intuitive and really do improve the in-world experience. There’s still more work to be done around Outfits Folder use, but that’s hardly likely to cause many issues. I’m not actually sure how widespread the use of (My) Outfits is; there are limitations with the implementation in the official viewer, and it can create a fair amount of inventory bloat. While I do tend to use it for NO COPY outfits from a couple of my favourite designers, friends do tend to respond with a “never bothered with it” when discussing using it.

Related Links