The Lab’s had a number of well-publicised (and some rather less publicised) feature and technology development projects that haven’t come to fruition. Where are they at? Or, in other cases, what happened to them?
Expressive Puppeteering
This project was a system to allow the parts of an avatar to be moved on the fly, with the possibility of creating animations in-world in real-time. Unofficially cancelled in mid-2007 due to a company-wide focus on reducing crashes and lag. Officially cancelled in 2008.
Physical Avatars (AKA: Avatar 2.0)
This project was to place the avatar in the same 3D space as the rest of the environment (rather than in its own loosely-coupled coordinate-space. It was partly in support of Expressive Puppeteering, and partly to allow avatars to hug, kiss, shake-hands and so on. It suffered the same fate as Expressive Puppeteering, and at the same time. Officially cancelled.
Script Limits
Script Limits involve finer per-parcel and per-agent allocation of scripting runtime resources. It’s a very tricky thing to implement properly, and it isn’t known if any of the staff involved with the project remain with the Lab. Given the potential benefits to Linden Lab, I’m not sure that the project is entirely dead. Status unknown.
Project Firefly
Project Firefly was hinted to be a client-side scripting project, that is making the Second Life viewer itself scriptable. Exactly what the scope of that might be remains unknown. It might allow for very simple alterations of the user-interface, or might extend to the capacity for full-blown automation of a viewer. No more has been heard about it, and the status of employees who might have been associated with it is uncertain. Status unknown, but pay attention to Oz and Esbee at SLCC. This could be integrated with new viewer development strategies.
C# Scripting
The possibility of adding support for other scripting languages in addition to LSL has been raised by the Lab on a number of occasions, though the integration effort isn’t without some hitches, including the possibility that other languages will have significantly larger runtime overheads than LSL scripts, and may require scripters to use some relatively arcane interface libraries to shoehorn additional languages into the execution/event model that the grid uses.
I believe the talent relating to this project has largely been let go, and there doesn’t seem to be any particular benefit to Linden Lab other than a marketing bullet-point. Status unknown, but not likely. Not officially cancelled.
Second Life Enterprise
Dead according to Lab management. There have been hints and suspicions of this for a while, but Philip Rosedale confirmed it in comments at the Q&A after he took over from Mark Kingdon, and this was confirmed the following week by a Lab spokesperson.
Face recognition/hands-free interface via Webcam
This was a technology from one of Mitch Kapor’s other businesses. While it’s been reported in the media as a Second Life/Linden Lab project, it doesn’t appear to have ever been taken on-board at the Lab. Not in progress; not planned; never started.
Mesh uploads
Server-side mesh-handling seems to be fine. Viewer-side mesh-handling also appears to be fine. The grid (or at least some simulators) appear to be able to deliver mesh objects now (as of about server version 1.40), only viewers (other than the closed-beta mesh-viewer) don’t know how to signal support for them or to ask for those meshes.
The Lab says this isn’t cancelled, and I’m inclined to believe it. If it was cancelled, the closed-beta would likely be terminated, and so far, that beta seems to be not just operational, but actually active.
Mobile viewer
Word is that the Lab is or has been working on a mobile/lightweight Second Life viewer, possibly for the iPad/iPhone. The project has dropped out of sight, and it is logical to assume that it has been cancelled, though there’s no official word on it at this time.
Did I miss any projects while I was rummaging through my notes? Do you have solid information about one of these projects that is different to what I have? Let me know.
Added:
SpeedTree
Linden Lab looked into SpeedTree middleware back in 2005, which would have replaced all of the stock vegetation with high-quality, procedurally-generated models. This was abandoned in late 2005 (and officially cancelled in 2006), due to a number of probable issues. Firstly, as Linden Lab explained, it would put anyone in the existing SL virtual-vegetation industry out of business overnight. Second, costs associated with licensing the technology out in every viewer probably put the kibosh in things pretty quickly.
The reliable inventory service
Inventory loss comes in two classes. The rarer case is when the servers themselves have lost the inventory items. The more common is where the viewer does not receive a complete copy of inventory data from the servers. Inventory loading is a bit slow and balky because of the protocol used, and information can certainly be lost in transit.
By conversion to a TCP-based service, inventory loading was to be vastly accelerated and cases where the viewer received incomplete inventory data would drop to zero. This was scheduled to roll out in January 2009 after some considerable time in development. It apparently did not, and nothing has been heard about it since.
HTTP textures
The same sorts of problems that plague inventory data transfers also affect texture transfers to some degree. The protocol used is slow and occasionally prone to pathological behaviour. Allowing textures to be loaded as a TCP-based Web-service was conceived of about 2-3 years ago, and viewers have had the (well-hidden) option to make use of it for about that long.
The servers, however, didn’t really support it, except for occasional testing. Now, however, it looks as if that project is about to reach fruition. Testing is going ahead at the moment, and – barring show-stopping issues – it looks like this project will roll out within a month, delivering faster and more reliable texture loading.
| The Lab’s had a number of well-publicised (and some rather less publicised) feature and technology development projects that haven’t come to fruition. Where are they at? Or, in other cases, what happened to them?
Expressive Puppeteering
This project was a system to allow the parts of an avatar to be moved on the fly, with the possibility of creating animations in-world in real-time. Unofficially cancelled in mid-2007 due to a company-wide focus on reducing crashes and lag. Officially cancelled in 2008.
Physical Avatars (AKA: Avatar 2.0)
This project was to place the avatar in the same 3D space as the rest of the environment (rather than in its own loosely-coupled coordinate-space. It was partly in support of Expressive Puppeteering, and partly to allow avatars to hug, kiss, shake-hands and so on. It suffered the same fate as Expressive Puppeteering, and at the same time. Officially cancelled.
Script Limits
Script Limits involve finer per-parcel and per-agent allocation of scripting runtime resources. It’s a very tricky thing to implement properly, and it isn’t known if any of the staff involved with the project remain with the Lab. Given the potential benefits to Linden Lab, I’m not sure that the project is entirely dead. Status unknown.
Project Firefly
Project Firefly was hinted to be a client-side scripting project, that is making the Second Life viewer itself scriptable. Exactly what the scope of that might be remains unknown. It might allow for very simple alterations of the user-interface, or might extend to the capacity for full-blown automation of a viewer. No more has been heard about it, and the status of employees who might have been associated with it is uncertain. Status unknown, but pay attention to Oz and Esbee at SLCC. This could be integrated with new viewer development strategies.
C# Scripting
The possibility of adding support for other scripting languages in addition to LSL has been raised by the Lab on a number of occasions, though the integration effort isn’t without some hitches, including the possibility that other languages will have significantly larger runtime overheads than LSL scripts, and may require scripters to use some relatively arcane interface libraries to shoehorn additional languages into the execution/event model that the grid uses.
I believe the talent relating to this project has largely been let go, and there doesn’t seem to be any particular benefit to Linden Lab other than a marketing bullet-point. Status unknown, but not likely. Not officially cancelled.
Second Life Enterprise
Dead according to Lab management. There have been hints and suspicions of this for a while, but Philip Rosedale confirmed it in comments at the Q&A after he took over from Mark Kingdon, and this was confirmed the following week by a Lab spokesperson.
Face recognition/hands-free interface via Webcam
This was a technology from one of Mitch Kapor’s other businesses. While it’s been reported in the media as a Second Life/Linden Lab project, it doesn’t appear to have ever been taken on-board at the Lab. Not in progress; not planned; never started.
Mesh uploads
Server-side mesh-handling seems to be fine. Viewer-side mesh-handling also appears to be fine. The grid (or at least some simulators) appear to be able to deliver mesh objects now (as of about server version 1.40), only viewers (other than the closed-beta mesh-viewer) don’t know how to signal support for them or to ask for those meshes.
The Lab says this isn’t cancelled, and I’m inclined to believe it. If it was cancelled, the closed-beta would likely be terminated, and so far, that beta seems to be not just operational, but actually active.
Mobile viewer
Word is that the Lab is or has been working on a mobile/lightweight Second Life viewer, possibly for the iPad/iPhone. The project has dropped out of sight, and it is logical to assume that it has been cancelled, though there's no official word on it at this time.
Did I miss any projects while I was rummaging through my notes? Do you have solid information about one of these projects that is different to what I have? Let me know.
Added:
SpeedTree
Linden Lab looked into SpeedTree middleware back in 2005, which would have replaced all of the stock vegetation with high-quality, procedurally-generated models. This was abandoned in late 2005 (and officially cancelled in 2006), due to a number of probable issues. Firstly, as Linden Lab explained, it would put anyone in the existing SL virtual-vegetation industry out of business overnight. Second, costs associated with licensing the technology out in every viewer probably put the kibosh in things pretty quickly.
The reliable inventory service
Inventory loss comes in two classes. The rarer case is when the servers themselves have lost the inventory items. The more common is where the viewer does not receive a complete copy of inventory data from the servers. Inventory loading is a bit slow and balky because of the protocol used, and information can certainly be lost in transit.
By conversion to a TCP-based service, inventory loading was to be vastly accelerated and cases where the viewer received incomplete inventory data would drop to zero. This was scheduled to roll out in January 2009 after some considerable time in development. It apparently did not, and nothing has been heard about it since.
HTTP textures
The same sorts of problems that plague inventory data transfers also affect texture transfers to some degree. The protocol used is slow and occasionally prone to pathological behaviour. Allowing textures to be loaded as a TCP-based Web-service was conceived of about 2-3 years ago, and viewers have had the (well-hidden) option to make use of it for about that long.
The servers, however, didn’t really support it, except for occasional testing. Now, however, it looks as if that project is about to reach fruition. Testing is going ahead at the moment, and – barring show-stopping issues – it looks like this project will roll out within a month, delivering faster and more reliable texture loading. | |  | |
This entry was posted
on Tuesday, 10th August, 2010.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Possibly related posts
InWorldz, LLC and CariNet Inc. To Power Virtual World Technology and Hosting Through Joint Venture, Consensual technology, Status of the Linden Endowment for the Arts, Illnesses, work and projects, Disruptive technology
[...] This post was mentioned on Twitter by Tateru Nino and slfeed.net, Skate Foss. Skate Foss said: RT @taterunino: Second Life technology projects status « Dwell On It http://bit.ly/d1UJDN [...]
Where I _think_ the lab will go on these:
* Expressive puppeteering, Physical avatars: an awesome technology which will be dropped. The benefits are all intangible and impossible to sell. Unfortunately a dead end (until someone proves it on another platform.)
* Script limits, Project Firefly, C#: LSL must be replaced at some time, and it’ll be easier to build onto an existing framework than to re-design from scratch. Mono got half way, so LSL will end up being interpreted, and “true” scripting sit in a bunch of APIs talking to the sim and client. Development of this will be very slow as the APIs need to be tuned to ensure little malice gets through to the server. A loooong term project.
* Face recognition: Half way to face recognition is feature recognition. Long before realtime face recognition we’ll get a texture mapping tool to photomap us to our avatars. Hardware/software is too different (outside the console space) to allow for optimized realtime facial expression recognition for a few years. Photomapping an av from video (in non-real-time) could be done today.
* Mesh Uploads: an absolute requirement for any kind of progress… and iI’ve seen it demonstrated working fine in beta. Policy issues are the only thing holding this up right now, ie. how to avoid mesh griefing or abuse. Meshes are done, mesh policy not.
* Mobile viewer: this requires a different way of looking at SL content at a sub sim level. Mobile viewers won’t be able to give the full SL experience for some years. Unity demonstrations howerver have shown that chunks of SL translate fine into a mobile experience. Perhaps isolating parcels as windows into SL space is the key. That can be done easily.
MISSED:
* Foliage [*cough* speedtree *ahem*] which will never get done (as it competes with residents and is largely replaced by meshes).
* Avatar 2 bones and IK: which may follow meshes via collada import.
* Materials system: ie. (mostly) normal and specular maps…. which I anticipate probably after meshes go live.
1. Windlight Sim based windlight settings so everyone can see what you do?
2. That SL external Chat messenger thingy
@Pavig: Ah… I’d forgotten speedtree. That was shelved in late 2005, from memory. The IK got officially cancelled when expressive puppeteering and physical avatars did. My understanding is that none of the code that got written for any of it is now able to be integrated with the viewers/servers as-is. The projects would have to be started from scratch.
@Loki: SLim was very visibly cancelled, but it wasn’t a Lab project, technically. It was an incomplete Vivox thingy.
Ah! Shared Windlight settings! Yes! This was referred to as Windlight 2.0 for a while, and it was just one of several Windlight-related features that were also shelved indefinitely to focus on crashes and lag.
@Tateru perhaps your next dwell could be focused on what on earth the lab has REALLY been focusing on since 2007 cos id like to know.
@Loki According to the Lab, the primary focus from 2007 to 2010 was on making things simpler, faster more ‘delightful’ and reducing crashes and lag. Not much to tell.
llNet.
Frank Ambrose was brought in to overhaul LL’s network, but it’s probably worse than it’s ever been.
@Tateru but is this actually what they focused on? or did they focus on things like changing openspaces to Homesteads and pushing adult content to Zindra? Playing with new viewer UI skins, messing about with their Logos and corporate identity… ect.
@Loki It’s hard to say whether the time was actually spent, but I think it was.
There was the focus on crashes and lag that aborted feature-development and new-technologies projects in 2007, followed by most of the rest of the stuff that happened (everything up to and including SL Enterprise) seemed to be done in the name of, well, let’s call it ‘fast. easy. fun.’ – since that’s essentially what the targets and tests were.
Which goes to show that a motto and simple set of litmus tests for ideas doesn’t necessarily help you meet the goals. It is necessary to understand where you’re going, and how you intend to actually get there.
When it comes to the lab and lag reduction, I gotta sorta stick up for them just a tiny lil bit here. I do remember seeing periodic posts on the official blog about serious changes to networking infrastructure that took place over a period of about a year or so. Whether it made a big difference or not… well.
But they did try something, anyway. Too bad they didn’t address server side design issues too.
Totally agree with others that Windlight is *not* finished. Without server side support to send environment settings for a parcel/region to a viewer, it’s effectively useless. Manually swapping XML files or having to ask visitors to select a preset is completely antithetical to Phil’s whole immersion thing.
VWRAP (previously known as Open Grid Protocol) is another thing that is effectively dead. It still has had a few people doggedly working on it (John Hurliman of Intel is notable there) but LL’s support has evaporated. At this point, it’s very likely that anyone still interested in this will switch to OpenSim’s HyperGrid protocol.
I’m also a bit curious about shadows and lighting. I’ve been told the 2.* viewer renders these much better (or at least faster) than 1.23 did, but I’ve heard nothing official from the lab about whether or not they care about it much.
Philip said at the community meeting that web and mobile clients were a couple of years away but there were a couple of R&D people looking at how they would do it. Focus for now on main viewer experience.
The OpenSim grid Meta 7 uses something called Lightshare that allows sim owners to choose their Windlight settings and have visitors see these, they even smoothly translate between settings when walking between sims. I believe the functionality is mostly implemented client-side on their official viewer, branched from Emerald.
Demo video here: http://www.youtube.com/watch?v=YBco1wbPZdQ
I’ve seen Lightshare. The concept is sound, and the code is fine, but the design of the data-exchange is, frankly, bollocks (I believe that’s the appropriate technical term)
It’s… what… a 140 or so bytes of anonymous, unversioned, binary data, mapped by a struct pointer? Feels like a disaster waiting to happen – especially if any additional Windlight variables should ever need to be handled. A new version would automatically break compatibility with any old version.
Fix that, though, and it would be a very cool thing indeed.
@Marcus Yes, the Lab appears to have pulled out of all the interoperability efforts. Some ex-Lindens are continuing with them, but to the best of my knowledge, notions of driving or complying with interoperability proceedings have been abandoned at the Lab.
Surely the barrier to mesh imports is economic rather than technical? Allowing an influx of high-quality mesh-based items would destabilise the prim-based economy and put most if not all of the current producers out of business – http://wp.me/p4QUI-o4
@Tateru, Re: Lightshare … True, you want LL implementing something that’s well designed. But how likely is Windlight to change anytime soon? And by soon, I mean… well, within maybe 5 years? Not likely at all, by my reckoning.
Lightshare’s merits or warts aside, this just highlights one of my beefs with the way LL sometimes seems to handle potential contributions. They literally “what if?” them to death. “What if this changes?” or “What if we go another direction?” And you know what? It rarely changes, and they rarely do go another way, unless not doing anything at all counts. It’s hard to innovate if you’re doing nothing but asking yourself why you shouldn’t do it.
Did anyone mention Nimble? That was supposed to be finished before the end of 2008. It’s the volumetric cloud system that pairs with WindLight.
How about a Web-based viewer? Wasn’t that recently floated as a possible direction for development?
– Maria
http://www.digimi.com owned by DAZ3D who are in the Mesh beta
http://www.daz3d.com/i/3d-models/-/daz-studio-game?item=10675&_m=d Your face from a passport or other photo built onto a pro mesh avatar base, importable into games through API.
Digimi offers developers the ultimate platform for generating personalized avatars, if Linden Labs goes for a Facebook webclient, we really should have this because 5-6 starter avatars wont cut it with the Facebook crowd.
I have heard on a video when Philip Linden was explaining Second Life, someone commented after joining it that he looks and feels like a refugee, I believe the question referenced how to find clothes or something along the lines and how to improve his look.
But to be fair Facebook are overly reliant on photos, so I see no sense in not pursuing a simplified pro avatar from an uploaded or image from their profiles to get the avatar they want.
As we all know Facebook is primarily all about showing who you are, so to approach such a site with only 5-6 crappy avatars would be a total failure, but with Digimi we can offer great starter avatars with low lag poly mesh of themselves. http://developers.digimi.com
@Maria Speculatively. My understanding is that the initial investigative and feasibility assessments for that aren’t due to begin until next year, earliest. So, as yet, it isn’t even at the stage where the Lab’s actually sat down around a table and talked about whether to put the project on the schedule at any point.