This is a weekly summary of changes to all SL Viewers / clients of which I’m aware and which are in popular use across the grid / listed in the TPVD. Detailed links to said Viewers / clients can be found in my Viewer Round-up Page. The links supplied in this summary are either to change logs or to reviews within this blog.
Updates for week ending: 14 May, 2012
No changes to the official release of the SL Viewer
Further update, 13th May: Alina Lyvette, Lumiya’s creator, passed word to me on the “long touch” issue with objects in the 3D view: “Yes, it’s not 100% reliable at the moment, it uses a makeshift solution of reading back the frame buffer instead of true collision test, and it’s known to fail unpredictably on so many phones. I’ll do a true collision test for the next release and it will be rock-solid, just need time to do that (and a few interesting tricks to make it work within Android limitations ^.^
Updated 13thMay: Susie Bagley and Lirusaito have both commented that object information can be displayed in the 3D view; something I was unable to do on my own phone. This article has therefore been updated to reflect the capability.
Lumiya, the SL client for Android, developed by Alina Lyvette follows Radegast in becoming the second text-based SL client to offer a 3D rendering capability – and is the first to offer such a capability to mobile devices running the Android Os, with the release of version 2.0.0.
There are limitations at present – but this is an initial release, so please bear that in mind. The release notes describe them thus:
No true avatar rendering (yet), avatars are displayed as default faceless figures.
Terrain and sky are not textured.
“Mesh” is not supported. Sculpted objects are (mostly) supported.
Particle systems, local lighting and other fancy features are not supported.
I took the new version for a quick spin using my CTA (Crash Test Alt), after Latif Khalifa tickled my ribs about the release via Twitter.
Accessing the 3D renderer is simple and straightforward: simply tap the 3D View button at the top left of the screen after logging-in to SL via Lumiya. This will take you directly to the in-world view (which may take a little time to load, depending on your phone / connection). The view itself has two further buttons in the lower right corner, with up (move forward) and down (move backwards) arrow icons.
Once rendered, the View delivers a lot of detail, and managed to capture my PrimPossible piano perfectly, as well as other sculpts without problem, despite the caveat given against sculptie rendering in the limitations. You can pan left / right by dragging a finger across the screen; your avatar will also turn as you pan around (circular panning) – and your avatar will be seen to turn by Viewer users around you. The scene doesn’t currently pan up / down at present, but this doesn’t limit use. Avatar movement is a simple glide, rather than having any form of animation at present, but again, that in no way impacts on things.
Lumiya 3D View on a Samsung Galaxy S2
As one would expect, rotating the phone will cause the scene to rotate as well, so for those with large screen sizes, the 3D view can be used in landscape mode, providing a wider field of view. About the only disconcerting thing some may find with the 3D View is that the default avatar form is a grey male – although we can expect this to improve as the capability is enhanced.
An in-world scene captured by Lumiya (click to enlarge)
The view isn’t interactive, so there’s no actual touching of in-world objects to obtain menus, etc; for this you have to use the existing touch option, which does mean a certain amount of screen swapping, but again, nothing that is in any way problematic (although I did have a habit of tapping my ‘phone’s Back button once too often and ending up back in an apps window – but that was operator error, nothing to do with Lumiya!).
However, pressing on an object displayed in the view for a few seconds should display information about the object across the top of the screen (my thanks to Susie Bagley and Lirusaito for pointing this out, as the feature has not been working on my Galaxy S2).
Tapping your ‘phone’s Menu button will display options to open Lumiya’s settings screen (where you can alter your Draw Distance, for example), and to log-out of Second Life & Lumiya.
Performance
The Lumiya website notes:
On modern phones and tablets with Tegra 2 chips and comparable hardware, it will give you around 5-10 FPS in quiet locations. Initial world generation takes a few seconds.
On older generation phones with CPU frequencies in 300 MHz range, it will give you around 1 FPS at best, and initial world generation takes tens of seconds. It may still be useful to give you a brief idea of your surroundings.
Draw distance can be reduced to improve performance, but not much.
I found that the 3D View ran very smoothly on my Galaxy i9100 S2 over my home wireless connection, with no lag or delay in processing. When running via 3G, things were obviously slower, with both initial rendering and actual movement showing lag, which leading to some amusement as my CTA, when seen through a Viewer, appeared to shoot across a room and proceed to repeatedly wallop a wall while still standing still in the Lumiya display. Light taps on the movement keys recommended to give the network a chance!
Bandwidth-wise I ran Lumiya on 3G with the 3D view enabled for 5 minutes while wandering around, which totted-up 2Mb of data usage. Hardly an intensive test, I know, but it gave a rough feel for things.
System Requirements
The Lumiya website notes the following on system requirements for running the 3D view option:
It can work with plain old OpenGL-ES 1.0 without VBO support, but the performance will suffer a lot. Modern phones usually have VBO support, and Lumiya will use it when it is available.
The native code parts are compiled for ARM processors (Alina notes that if people have Android ‘phones using other processors and would like to see the 3D rendering option on their ‘phone, they should contact her directly).
Opinion
It is early days for this aspect of Lumiya, and I’m curious to see where it goes and what else can be included (and added to the client as a whole). As it is, Alina is to be commended for what she has achieved; this is really quite a remarkable client capability to have, and really shows huge potential and promise.
Update 14th May: My thanks to Oz Linden for pointing out that if you apply a Local Texture in-world, and then modify the original image file in a suitable editing tool and save it again, the viewer picks up the change and automatically applies it in-world (see Comments). I’ve also clarified that Local Textures can be used for clothing and skins within the text of this article.
Local Textures is a means by which textures stored on your computer can be applied to in-world objects on a temporary basis, allowing you to judge their suitability for use prior to uploading.
In this, it combines functionality currently found in many third-party Viewers (TPVs) in the form of the Local Bitmap Browser, with the added capability of being able to apply a selected texture directly to an object in-world within your own world-View.
The option, contributed by Vaalith Jinn, the originator of the Local Textures Bitmap, has been available within a number of recent Development builds of the official Viewer, and is now available in the latest Beta release (255742), so expect to see it in a mainstream release very shortly. (It should also be noted that the option is already available in both Dolphin and Niran’s Viewer.)
Using Local Textures
Local Textures is accessed from the Texture tab of the Build floater:
Texture picker: note the Local radio button (circled)
Note that there are now two new radio buttons on the Texture Picker itself – Inventory and Local. The former will, naturally, allow you to browse the textures within your SL inventory as we’re all familiar to doing.
Clicking on the Local option, however will change the Picker to display the following:
Local texture panel
This contains three new buttons, described below.
Add: Opens a window allowing you to browse your hard drive(s) to find textures.
An individual texture can be selected by double left-clicking on it or by left-clicking once on it and then clicking OPEN
Multiple textures within a folder can be selected using either SHIFT-left-click or CTRL-left-click (which can also be used to de-select individual items from a multiple selection
Selected items are added to the list panel to the right of the buttons
You can browse as many folders as you wish and add items to your list, but you cannot select folders themselves
Remove: (only available if a texture is selected in the list panel) removes an unwanted texture from the list
Upload: (only available if a texture is selected in the list panel) will open the usual texture upload panel, allowing you to upload the selected texture to your inventory with the usual L$10 fee and use it from there. Note that bulk uploads are not supported from the button.
When you have added one or more textures to the list panel, clicking on an individual texture within the list will apply it to the selected object / object face. Note that as these are only local file associations, the applied texture will only be visible to you; no-one else will see the texture (the object/face will remain untextured in their view).
Applying a local texture – only visible in your own world view
Textures added to the list panel will remain available to you until such time as you log-out of Second Life, at which point this list will be emptied.
Note that clothing and skins can be tested in the same way – just use the Edit Appearance floater and the New Clothes / New Skins options.
Local Textures and Temporary Textures
Local Textures might also sound like the Temporary Textures upload capability also found in many TPVs, but there are notable differences:
Temporary textures appear in your inventory, usually with the prefix “temp” for the duration of your current session in SL, then they are lost
Temporary textures can be see in-world by people other than yourself; this makes it ideal for things like collaborative building, where joint decisions need to be made prior to the selection and upload of textures
There have been rumours that LL are looking to “break” temporary texture uploads with the release of Local Textures. This does not appear to be the case at present; LL have so far given TPV developers no indication that they expect to see Temporary Textures removed from Viewers. Certainly, Dolphin is running with both Temporary Texture uploads and Local Texture; providing LL do not indicate they have a problem with this, it is likely that other TPVs will opt to do the same.
However, it might be worth noting that Temporary Textures do rely on using a feature in a manner in which it is not intended to be used, and which is specifically related to avatar baking. LL are currently looking into ways in which to make avatar baking more robust and less prone to problems such as bake fail (when your avatar fails to rez correctly). One of the options being considered in this regard is moving the bake process server-side.
If this does indeed happen in the future (and it is not a trivial change), then it may result in Temporary Texture uploads being “broken”; but again it is important to emphasise that no actually decision on how to deal with avatar bake issues has yet been taken.
In the meantime, expect to see Local Textures in your preferred Viewer in the near future!
With thanks to Innula Zenovka for raising my awareness that Local Textures had reached the Beta Viewer (forum post), and to Latif Khalifa and Trinity Dejavu for input to this piece)
ETA contributor’s detail, supplied by Mobius Ryba.
This is a weekly summary of changes to all SL Viewers / clients of which I’m aware and which are in popular use across the grid / listed in the TPVD. Detailed links to said Viewers / clients can be found in my Viewer Round-up Page. The links supplied in this summary are either to change logs or to reviews within this blog.
Updates for week ending: 6 May, 2012
Several updates occurred this week, with Dolphin, Niran’s and Zen in particular all making two releases apiece.
No changes to the official release or Beta of the SL Viewer
The SL Development Viewer rolled to 3.3.3.255742 on May 4th
The SL Mesh Deformer Project Viewer received and update (blog post) on May 3rd
Dolphin went through two rapid-fire releases, with 3.3.6.23776 appearing on May 1st, followed by 3.3.7.23790 on May 4th
Niran’s Viewer rolled to version 1.34 on May 3rd, and then version 1.35 as this update was being prepared overnight on the 6th/7th
Zen Viewer released versions 3.3.3.1 and 3.3.3.2 in short order on May 3rd and 5th respectively, change logs for both here
Cool VL Viewer rolled to 1.26.4.11 on 1st May, with change log here
There have been questions and comments on Exodus floating around in various places, with people wondering what is happening and when the next release might come out. As an Exodus user myself, I fired-off an e-mail to Clix and the team recently to see if they’d be willing to shed a little light on what’s going on.
While the reply was a little shorter than I’d hoped – but then I did ask a couple of questions on releases that the team may not want to commit to, date-wise – Clix did provide a little update:
The team has been busy with personal projects and real life commitments. Naturally this has slowed down production. In addition we have been submitting code upstream to Linden Lab that has been accepted and rolled out in the most recent official viewer release.
Exodus is being actively worked on and will feature a wide range of fixes, performance improvements as well as some neat new features. Our next release will address any and all license concerns. We will continue to produce the best TPV for gamers and visual artists in Second Life. Stay tuned for new feature announcements!
The license concerns mentioned potentially refer to J2C / KDU usage issues. Whether or not this is the case, it is fairly clear from comments passed elsewhere that there has been strong cooperation between LL and the Exodus team in sorting any problems out, which has to be seen as being a good indicator when it comes to LL / TPV cooperation in general, something that has been grumbled about by some commentators following changes to the TPV Policy recently.
One thing is very certain: given the popularity of Exodus amongst users, that the Viewer is being actively worked on will come a good news to many, so keep an eye on the Exodus blog page.
Inara Pey: Living in a Modemworld 