Month: May 2012

Lumiya Android client adds in-world rendering

Posted on by Inara Pey

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 13th May: 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.

Related Links

Local Textures: coming to a Viewer near you

Posted on by Inara Pey

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. 

Return to Alpha and Omega

Posted on by Inara Pey

Update: Both Alpha and Omega Points have closed.

In October last year, I wrote about Alpha and Omega Points in SL. Operated by Masoon Ringo and Sweetlemon Jewell, these two sims are home to incredible builds that straddle the sci-fi / fantasy divide and offer visitors much to see and do, as I reported at the time.

I dropped in on the sims at the end of April to find they were under reconstruction. What I saw then intrigued me, so I decided to wait a couple of weeks and pop back over and see what has happened.

The “ground level” build has changed extensively, although there are still strong echoes with the previous build: the same lowering skies, the lightning, and so on, while elements of the build itself carry echoes of the last: similar hanging walkways, elegant stairways, ornate sculptures and hidden surprises. But there is also much that has changed, and elements that give this build something of a “darker” feel – at least on the outside.

The “Village To Heaven” appears to remain unchanged  – and is still as magnificent as on my last visit, and the Fall Pods are still available for those wishing to take a ride back down to the lower builds.

 

SL9B: Ten sims by the residents, for the residents

Posted on by Inara Pey

Saffia Widdershins, over at the Prim Perfect blog has just issued news that there will be ten sims available for centralised events during SL9B.

A formal announcement will be made on Monday May 14th, but Saffia notes:

There will be stages, resident plots, art plots, and there are plans to link to other community events across the grid.

There will be a birthday cake and a time capsule.

But there will be no involvement by Linden Lab. This a 100% resident event (which is being organised by some of the volunteers behind past Birthday and Burn events).

This is excellent news indeed, and congrat in advance to all involved for pulling this together.

For Saffia’s full piece, please go to the Prim Perfect blog, and make sure you keep an eye on it Monday!

With thanks to Saffia & Prim Perfect

Exodus and Niran’s Viewer appear on the TPV Directory

Posted on by Inara Pey

I received a short note from Oz earlier this evening:

Both Nirans and Exodus added to the directory this morning… thought you’d like to know.

Running a quick check on the TPVD page reveals both are indeed there, tucked in below Firestorm:

Exodus and Niran’s now TPVD listed

Niran’s Viewer had been accepted for TPVD listing with release 1.33. A new release of Exodus is in development and should be available in the future.

Congratulations to both Viewers.

What is Linden Lab’s role?

Posted on by Inara Pey

On May 4th, there was a lively Twitter discussion about many things SL, during which, Tateru Nino asked the following question:

@InaraPey @isfullofcrap Question. Should Linden Lab Rule, or should it Protect and Serve? Where do you see it on that continuum now?

This lead to a further discussion on just what people felt LL’s role should be. Given that the company itself has seemingly been trying to move itself more into the realm of service provider more than anything else, I suggested that Provide and Inform might be a better means of describing LL’s role.

I’m uncomfortable with the idea of “ruling” – although that is at times how LL appears to be operating (and outside of questions of ToS and arbitration*) – as that implies an autocratic approach completely devoid of any form of interaction with the user community, and if we’re honest, that’s actually far from the case. Yes, LL frequently suck in the manner in which they go about things, and they may not do things quite as we would like; but they are not entirely autocratic in nature. Were this otherwise, it’s doubtful we’d have the likes of third-party Viewers, nor would we have the likes of sim “donations” to the likes of the Linden Endowment of the Arts.

Similarly, I don’t think Protect and Serve entirely fits the bill because “protection” is something Linden Lab should be doing (and is, for the most part) as part and parcel of providing the Second Life platform, while “serve”, while warranted in terms of customer service potentially puts the shoe a little too much on the other foot when compared to Rule. Again, I’m not saying that Linden Lab has got either “protection” or “service” right, rather that both should be intrinsic to how they go about running Second Life.

Which brings me to Provide and Inform. I settled on these because to me, they are pretty much the two foundations upon which and service-oriented company should establish itself. “Provide” in this regards is pretty much self-explanatory; “Inform” brings us back to the issue of communications, which as we’ve again see this week is an area where Linden Lab pretty much sinks itself once again.

Much has been said in the intervening time between Tateru posed her question and I gave my initial response; some of it – such as today’s Metareality podcast for example, covers much of what I’ve been slowly cogitating over the last week and slowly forming into words for this post (so much so that I’ve actually thrown a large part of this post into the bin).

However, I’m not intending to turn this into another post on LL’s failure in communications (that may well come later, depending on what happens through today). What I am aware of is that even provide and inform is not entirely sufficient in defining what the Lab should be about, as both tend to perhaps point to an outward flow, rather than something more bi-directional in nature.

So, at the risk of appearing to be jumping on Tateru’s bandwagon with her recent, and excellent post / question relating to Linden’s Lab’s message, I’m going to throw this question out to the wind and see what comes back:

How do you – as succinctly as possible – see the Lab’s role, and how would you sum it up into a suitable expression?

*ETA as I totally forgot to ensure that remained after editing this piece. Mea culpa.