Category: SL Tech

Beta mesh

Posted on by Inara Pey

Jack Linden posts today that the Mesh beta import programme opens today. As previously posted, Mesh offers the potential to revolutionise the appearance of objects into-world, and also avatars, clothing and the rest, and has been a long time coming to SL.

As one would expect, the Beta is active on the Beta grid and requires the use of a dedicated version of Viewer 2 in order to upload and import Meshes. The former is understandable – there is still much to be understood about Mesh without further screwing up the main grid; the latter decision, while unexpected, may yet see some howls from people not that enamoured of Viewer 2. BUT…in keeping with their promises at SLCC 10, and providing people have a little patience, the howls should be short-lived as the code base for the Mesh imports is targeted for release via Project Snowstorm wiki, so that Third Party Viewer developer can incorporate it into their own code.

It’s going to be interesting reading-up on feedback on the project and seeing how well LL respond to the feedback, particularly with reference to improving the Viewer side of things, which, as with everything else, is “still in development”. If we’re brutally honest here, LL haven’t responded overly positively when listening to valid concerns about Viewer 2 and its associated tools so far…

Nevertheless, this move should be welcomed; one still has concerns about the overall impact of Mesh on businesses across the grid; there is a potential for mesh to be more revolutionary than evolutionary in that regard – and many may not be able to easily adapt. Personally, I hope that we see the two types of content creation also meshing – with traditional builders who cannot manage Mesh creation able to work alongside those with Mesh skills who don’t have the desire to work with the older tools. But – time will tell.

Mesh-ing around with Second Life

Posted on by Inara Pey

Jack Linden has announced the next steps in the scheme of things to establish “full” Mesh imports into Second Life.

Mesh has been something of an elusive Holy Grail for many when it comes to content creation in Second Life; it’s been promised for years and various You Tube videos demonstrating it have been around for almost as long, yet it has always remained tantalisingly over the horizon, leaving those wanting it faced with gazing at tea leaves in an effort to guess when it would actually arrive.

For those unfamiliar, Mesh is the system used to create our avatars, using a complex series of polygons to render highly detailed forms. Mesh is common through the gaming world, and is alive and kicking in “rivals” to Second Life such as Blue Mars.

Unlike the current system of primitives, Mesh constructs are created using graphics rendering programs that provide a complexity of detail far beyond anything that can be achieved in-world – as the images and videos accompanying the announcement show. They could, quite simply revolutionise and revitalise Second Life.

Mesh properly entered the SL roadmap earlier this year, with Mark Kingdon and others indicating that it would be entering a beta phase around now, with a potential roll-out by the end of the year. However, following Kingdon’s departure and Philip Rosedale’s “return”, things on the Mesh front went quiet – almost ominously so, with barely a mention being given in various addresses, prompting some to wonder if the entire idea was once again vanishing over the horizon. It was not until SLCC 10 in July that Philip confirmed the plans were still moving ahead, although on a revised timetable.

Now Jack’s blog provides further – if sketchy – insight to further moves.

There is little doubt that given the capabilities presented by Mesh, that it could very well revolutionise the appearance  – and possibly the appeal – of Second Life; as such, its arrival should be largely welcomed; but that is not to say there are still concerns surrounding its eventual use. Question such as how it will be placed alongside the “traditional” means of prim-based design and construction of objects and what Mesh means to those who are proficient in prim building, but who are unable to move to 3D rendering for whatever reason. There are even questions around how it could impact in-world “building for pleasure” activities. Beyond this, as N, a good friend with considerable knowledge of 3D rendering, there is also the question of intellectual property and ripped content; there are already masses of rendered material out there, much of it in breach of established copyrights and IP rights: what mechanisms will be put in place to prevent such material flooding into SL?

It’s good to know Mesh is coming; but I think it far to say there are many who are as anxious about the answers to some of these questions as they are enthusiastic about the arrival of Mesh.

The Green goes

Posted on by Inara Pey

Linden Lab have sounded the death knell for Emerald.

Well done, Phox (I wonder if that was an infantile play on “pox”). I sincerely hope a real lifetime ban follows for you, and Fractured Crystal. Not that I begrudge you anything, you understand, its just that – well, SL will be a lot more savoury without you.

For those panicking about their favourite Emerald features – fear not and look here. The future is bright. The future is winged….

Phoenix has now cleared self-certification (and do I ever wish some people would understand that term does not mean “approved by Linden Lab” or even “approved”!), and is now listed on the entirely voluntary TPV Directory.

So – onwards and forwards!

Addendum

Within 12 hours of appearing on the TPV Directory listing, Phoenix had achieved some 50,000 unique logins to Second Life. While a portion of these are going to be people running alts and potentially “bots”, the vast majority are going to have been unique users. As such, this is an extraordinary figure to hit in a so short a period. And without wishing to stir the Viewer 1.23.5 vs Viewer 2.x debated, one has to admit that it does show how loyal established users (who are the most likely to be aware of the entire Emerald debacle) remain to the older Viewer, despite LL’s best efforts at enticement, cajoling and denial.

Rising from the ashes

Posted on by Inara Pey

As Phox/Fractured leads those who listen into self-immolation, a new Viewer rises from the ashes in the form of Phoenix.

As Jessica Lyon announced:

My name is Jessica Lyon. My goal during my time with the Emerald Project, was always to give the users what they want. That goal has never and will never change. I’m very happy to announce, it continues…

A few days ago, I assembled a team of developers to work on a new viewer. Some who were originally Emerald developers, some who were not. All are respected reputable residents in the SecondLife Community. The goal was simple, to provide users with what they want and do it transparently.

I’m am very proud to announce the launch of the Phoenix Viewer. This project, has started off simple, with it’s initial release of a safe clone of the Emerald viewer. Users want Emerald features, you shall have them. We have big plans to expand to the Snowstorm project as well. We have already applied for the TPVD, to which we have no doubt we will be accepted in a timely fashion. We have already started making in world groups for support, (Phoenix Viewer Support), beta testing etc. There is much more to do… however…

This Viewer is ready for use by you, right now!

For this project, I insist on, and everyone on this team insists on 100% public transparency in EVERYTHING we do. We have already established a public IRC Dev chat, public repo and are working on much much more.

Our developers are; (in alphabetical order), Dakun Flux, Dimentox Travanti, Jessica Lyon, Kitty Barnett, LordGregGreg Back, Techwolf Lupindo, Tonya Souther, Vortex Saito, Wickman Gibbs, with more to come.

Our Lead Developers are: Dimentox Travanti, LordGregGreg Back, Techwolf Lupindo, Tonya Souther.

Ed Merryman will be leading our support team: Aleia Sapphire, bee Baroque,  Damian Zhaoying, Ed Merryman,  Marybeth Oceanlane,  Mindy Spiritor,  Nisa Maverick, PixelProphet Lane,  Toy LaFollette, Vortex Saito, Whirly Fizzle, Wolfspirit Magic.

Our website is still in progress, however we have up the required links.
Downloads.
I am very pleased and excited about this project, and I hope that you will be too.

Sincerely,

Jessica Lyon and the Phoenix Viewer Development Team.
My personal blog: http://jessicalyons.wordpress.com

This is potentially momentous news. Phoenix looks to incorporate some worthy individuals: Jessica, LordGregGreg Back and Kitty Barnett of RLVa fame.

As Jessica’s note explains, this is an initial release, based on “safe” Emerald code. The current iteration lacks many of the options that can already be found in LGG’s Emergence, but doubtless these will come in time as Jessica states. Most interestingly, the group are stating they’ll be looking to work with the Snowstorm project.

Currently, Phoenix is not on the TPV List, but the paperwork has been submitted and there are also some issues around the code repository that need to be resolved – the links don’t currently work (20:00 BST, 3rd Sept). However, for all those worrying about the future – given that, despite what has happened, Emerald did have a highly-effective list of functions – it would appear a Viewer of equal capability is now available.

I, for one, wish it every success and a drama-free future!

Out with the globe, in with the storm

Posted on by Inara Pey

Note: Following this post being published, Esbee Linden made a formal blog on the subject on August 17th

In his address at SLCC 2010, Philip made mention of “standardising” the viewer platform. At the time I was curious as to what this might mean and asked a speculative question or two. Later, during SLCC 2010, Q Linden (whom I hope makes a full recovery from his stroke) and others gave more insight into what is going to be happening, and Oz Linden posted an announcement on the opensource dev list (thanks to Argent Stonecutter for the link).

Q’s opening of the SLCC presentation was somewhat enlightening, in that it confirmed many people’s views that Viewer 2.x proceeded along a development path that was simply far too rapid. In fact he candidly admits that it was developed and rolled out to meet a given schedule, rather than when it was “ready” (in November, for example, a meeting was held in which the “to do” list of outstanding work on the Viewer was cut down to a list of things that could be done in the remaining time frame prior to the release of the Viewer.

He also admits that Linden Lab erred when preparing the ground for Viewer 2, in that they didn’t create sufficient use cases to reflect how the Viewer is actually used in-world (that LL needed to “invent” user types in order to build the use cases in the first place also surprised me. After all, what are we out here, if not users?). The upshot of this is an admission that the overall capabilities of Viewer 2 are too narrowly focused.

This may sound like a “well, duh!” statement – but I think it fair to say that such an admission from the development team is somewhat refreshing. It’s not often the Lab or its employees own up to mistakes, and Q’s comments do add up to a strong admission of  having erred, and a hint that the lesson has been learned internally, “For marketing reasons we felt we wanted to keep it secret and we wanted to release it in a kind-of ‘ta-da!’…I think you won’t be seeing any more of that sort of behaviour from us any more! Yes, I hear the applause, thank you!”

Following this, Esbee went over the new methodology for Viewer development – Project Snowstorm, which has the core aim of rapid, effective deployment of new features and functionality. Essentially, and as hinted at by Philip, this will be achieved through meeting three goals:

  • Weekly, visible progress on the Viewer – which not so much is focused on weekly releases per se (although that is something Philip indicated he’d like to see), but more a case of making the development process more visible too all, including users being able to attend development meetings
  • Improving the user experience – hitting Philip’s requirements of Fast, Easy, Fun (a slogan I *still* loathe, but there you go)
  • Revitalising the open-source community

It is this last point that is the most interesting and – if carried through  – marks a radical change in Viewer development; one that would seem to have many potential benefits – and not just for Linden Lab.

The core of this new approach is that Viewer development will be somewhat streamlined, with LL themselves working on specific elements of the Viewer while leaving things open so that third-party developers can engage directly with the LL team and take on development of a given aspect or function within the Viewer, and developers with existing fixes or functions that could benefit the Viewer can deposit their work with the team for potential integration into the Viewer.

This effectively means the end of Snowglobe, the open source “version” of the Viewer code.  To quote Oz Linden, “The main Linden Viewer is now completely open source…the source code is available on a public repository…NOW!” What is more is that this repository is to be the central “integration repository” where all code from Linden Labs will go prior to integration into the Viewer.

Alongside of this is the re-licensing of the code from GPL to LGPL – which, if I am understanding things correctly, means that it will be both easier to incorporate the Viewer code into other Viewers (I assume those that can be used on OSGrids and the like) and – particularly from LL’s point of view – will make the licensing of the code for use in “closed” third-party Viewers significantly easier, potentially attracting other professional organisations towards developing their own Viewer systems without the “stigma” of being associated with open source code. Again, given LL’s stated desire to drive SL onto more mobile platforms – tools such as the iPhone, Droid, the iPad, etc. – this would seem to be a good move, as it will allow third-party organisations with the expertise LL lacks to develop the kind of functionality such tools will require if people are to use to them to access SL and use it for more than just chat and IM.

It’s not just developers who have the chance to be more directly engaged with Viewer development either. AS Esbee said, users will be able to get involved as well: iterative releases will be available bi-weekly or us to use and feed back upon, and even daily releases, or “project releases” covering specific features under development will be made available and user feedback encouraged.

From a non-technical perspective, this does seem to be a logical approach, and in some respects, it is a shame that, when they opened the Viewer code to the community, LL didn’t show foresight and put these measures in place then. Of course, the devil will be in the details – and there is much that will serve as either proof of the pudding or still needs to be addressed  / clarified. In listening to the presentation, a number of points occurred to me, some of which were echoed by others in the Q&A session.

One issue that springs to mind is who will, in the final analysis, determine what is “right” for integration into the Viewer, and will other agendas overrule the core goals – such as making SL Fast, Easy, Fun? “Linden knows best” has been very much a part of the Lab’s culture and has been seen time and again, particularly with the arbitrary closure of JIRAs or the turning of a deaf ear to valid user requests.  With the best will in the world, cultural behaviour is the hardest thing to fix in an organisation.

An extension of this concern comes down to user input actually being heard and acted upon. Q openly admitted at the start of the presentation that LL erred with Viewer 2 in not creating enough user cases on which to model the viewer. Now they seem to be swinging to the opposition end of the pendulum swing: seeking too much user input. There are – as Q and Esbee acknowledge – many diverse uses for SL, and as such diverse sets of users have diverse needs. Some are going to apposite in their aims, others opposite. How are filters going to be applied to stop all these calls simply swamping Snowstorm with the result that the individual internal dev teams beyond them simply cherry-pick or (again) turn a deaf ear?

So where does this leave the current crop of TPVs? Oz was pretty unequivocal on the matter: the Viewer 1 code base will not be developed any further by Linden Lab (Q also touched on the need to depreciate 1.23 in the future, simply due to security issues). Therefore, with the Viewer 2 code base becoming publicly accessible, the view seems to be that TPVs will be encouraged to continue – as well as give input to the new project – but will be expected to migrate to the Viewer 2 code base.  Certainly, there doesn’t seem a move on hand to proactively “shut down”  TPV development, but it is going to be interesting to see how this moves forward and who engages through Snowstorm as is intended, and who simply continue to work on their own Viewers utilising the now-available Viewer 2 code.

Overall, this move strikes me as positive. *IF* LL can carry through on this with the necessary internal cultural changes and if we all, developers and interested residents alike, engage with Snowstorm and LL constructively, positively and openly on our own part, then there is no reason why this project should give birth to something very worthwhile and which benefits us all.

Emerald: unfortunate developments

Posted on by Inara Pey

I’ve supported Emerald. I’ve been happy to use it for around 18 months. In that time a lot has been made about it being a malicious viewer, with many, many claims going around that it does everything from raiding your L$ balance to spying on your granny while she’s having a bath…and they all remain pretty unsubstantiated. Emerald has also come in for more than its share of people misrepresenting its capabilities (such as making your avatar “invisible” allows you to run around griefing people. If you’ve ever used the “invisible” function, you’ll appreciate how ludicrous these claims are).

However, there comes a time when one is forced to sit up and take notice of what is being said – and that time is when it is being said by one of the Emerald developers.

LordGregGreg Back is not someone I classify as an SL friend or even an acquaintance. Our dealings have always been at a distance, via IMs usually. BUT…throughout the time I’ve been using Emerald, I’ve never found him to be anything less than honest in his dealings with people. It has been because of his involvement (alongside that of Chalice Yao) that I’ve remained an Emerald user. Yes, both at times have had to do *some* verbal acrobatics when being pushed to defend the antics of others, and in doing so have potentially harmed their standing in the eyes of others. But just because they have, does not, and has not meant their efforts and work with regards to Emerald have been anything less than honest.

So when Greg up and publishes his own misgivings about Emerald, I admit I sit up and take notice.

The crux of the matter is the manner in which a .dll is being used – in this case emkdu.dll – which is related to texture loading and which allowed a viewer’s title bar and executable path to be broadcast in an obfuscated manner (and possibly recorded by other in-world devices). Despite promises the issue had been fixed, made to both Greg and Emerald support manager, Jessica Lyon, it wasn’t. Instead, encryption was used to further obfuscate what was going on, and further requests for the code to be cleaned up only increased the degree of encryption being applied.

The worrying this here is that the encryption meant that the code could not longer be properly vetted and verified – Greg’s role in the Emerald team. This, as Greg explains, undermines trust. Encryption  / obfuscation is suggestive of malign intent, whether or not it is in fact the case. So why do it? Probably because the individual responsible cannot help but jerk an immature middle finger at his detractors at the thought of them scrabbling around trying to prove the code is in fact malicious, then giggling himself to sleep at night.

But in doing so, the individual concerned pretty much jabs a finger vertically at the rest of the Emerald team with the result that those with a conscience feel they have no option but to gradually bow out. And this is a shame, as it lessens the value of Emerald while simultaneously enabling a further round of accusations and drama.

More than this, it leads to an undermining of faith in Emerald as held by existing users. After all, one developer is actively seeking to mask what the code is doing from his fellow developer and placing active barriers in the way of ensuring the code is properly verified as “clean” – so why on Earth should any of us continue to trust and use Emerald?