Apologies for taking so long to get this up. We’re looking into more efficient ways to get transcripts produced.
Download the transcript here or view the entire podcast transcript after the jump.
Miss the podcast? Read more (and download it) here.
Inside the Lab – Joe Miller Jan 08
Catherine Smith: Hi, my name is Catherine Smith, Director of Marketing at Linden Lab, and I have Joe Miller, VP of Platform and Technology Development. For those who don’t already know you, Joe, could you tell us a little bit about yourself and what you do at Linden Lab?
Joe Miller: Sure, Catherine, thanks. As you point out, I am the Vice President of Platform and Technology Development. I joined the company in that capacity almost two years ago. Quite frankly, what I have been doing for the last couple of years is focused inwardly on building a team and extending a team around the various challenges we have on the technology front.
Some of that involves some outside partnerships, such as what we did with the voice integration. But largely I have been focused internally on building, rolling out our teams, and growing our capabilities, inside the company.
Catherine: From a technical standpoint, what are Linden Lab’s priorities this quarter and what can residents expect to see in the coming months?
Joe: Sure. I think it’s been said several times in different ways, but I would really like to make it clear today, that our focus right now continues to be on the elements of the stability and predictability of the platform broadly, for all of our stakeholders, and we have many different kinds of customers, as you know.
But we have lots of work to do to create a predictable environment so that when you come in to a region on a Wednesday afternoon that it will behave pretty much the same way as it might be if you came in to the same region on Friday, regardless of how many avatars might be there with you.
So there are a number of projects we have underway inside the company, many of which have been long term projects which are coming to conclusion now, which will really help us address the primary issues around perceived variability in the performance lag, certainly cutting our downtime. We have done several things already. I think our listeners will know that the Wednesday downtimes have been reduced to the bare minimum.
We no longer take the grid down when we push new versions of the simulator software. We try to do that on a rolling update basis, so that we can do that with the least disruption to most of our customers as possible. We no longer require mandatory viewer updates unless there is a very good reason to do. That was also disruptive to most folks; they have to download a new viewer when we would update the simulator.
So those are some things we have already rolled out, that have helped us create a more predictable environment. One that doesn’t require thinking about what day of the week it is, or what the hour might be, and is the grid going to be there for you to use it in the way you wish. But we are doing a number of other things, number of other projects I would be happy to talk about more, here today.
Catherine: Great, I would love to hear some specifics.
Joe: Sure. I think, again, the Havok project has been bandied about a bit, and our primary goal with the move to re-factor the primary physics engine in the simulator code from the original Havok engine, which was really Havok one — it was one of the first versions of Havok that was shipped commercially — to what is now Havok 4.6, which is the latest version of the code that we began working with quite some time ago. The purpose in updating that engine isn’t to introduce any new features at all.
The primary purpose in investing almost a year of effort now in this project has been to significantly modernize the way the simulator deals with physics. The Havok engine is used for vehicle motion, for friction, for the interaction of objects to themselves; and certainly the way the avatars interact with the world is all controlled and sort of governed by the physics engine.
One of the biggest challenges we have had with stability is, there are many states that a resident could get in to, either perhaps by accident or in some cases on purpose, that would cause the physics engine to go into a compute intensive mode that would ultimately lock it up and require the sim to crash, or to take itself down, to terminate. That in turn, caused not only loss of connectivity for the users who were on that sim, but could cause content loss in some cases.
It has been a high priority for us to remove the possibility that any activity the users with respect to the physics engine can actually cause the sim to crash. The good news is, after almost a year’s worth of effort in refactoring this low level functionality in the simulator, we are now, this month, at a stage where we are going to bring up 200 regions on the main grid.
To people who would like to put this new engine to use, the new physics code to use on their regions, there will be a lot more news about that and a lot more information posted on the blog. That is something that both Andrew Linden, and Sidewinder Linden, are hosting in world office hours about, be a lot more about that.
Then, based on what we learned through this roll out process over the course of the remainder of this month, in early February we will begin to install the Havok four code grid-wide. We think this will have a very significant effect, measurable effect, not only in reducing the frequency of sim crashes, but because the physics engine itself is, frankly, much more optimized and modern, it will free up compute cycles on those regions for lots of other things, including execution of scripts and other activities that avatars are undertaking on a given region.
Catherine: So, can you tell me a little bit about Mono?
Joe: So Mono is another project, probably on a similar vein. We have been operating with the original scripting engine, actually it is the second version of the scripting engine; LSL two has been in use now for five years.
Quite frankly, one of the challenges with Second Life, as a technology platform, is because we are driven by user-generated content, the kinds of experiences that people create, the kinds of interactions that people can create with the system, are largely governed by the flexibility and the performance characteristics of our scripting engine. People have gotten very good at living within the boundaries of LSL, the Linden Scripting Language.
But we are at a stage now, where we want to provide a much more efficient scripting engine, or a much more efficient way of executing scripts. So Mono is a refactoring of the interpreter, the interpreter approach to actually executing scripts, moving to a compiler. So no longer a script is interpreted in real-time, which is inherently not as efficient — byte code interpreter — as pre-compiling scripts and executing them on the simulator at a much higher rate.
The primary advantage of Mono is, it will not have some of the memory limitations that you have today, that require scripts to be perhaps split up into multiple scripts and running in different objects and create some complexity and some load associated with a simple function that you might be able to create with less of a memory constraint. But the other value is that the scripting engine will run much faster. We think, once it is completely deployed and in full use across the grid, it will actually execute 100 to 150 times faster than the existing engine today.
Again, the net effect on our residents will be that, not so much new features, but the performance of simulators, when scripts are being executed, when many scripts are being executed, should be much more predictable. You will be able to walk into a region that is heavily scripted; it has many scripted objects, and not see a noticeable performance hit as you might see today with the existing scripting engine.
That’s a rather deep, and unfortunately maybe too deep a dive into the bowels of Mono, but we can come back up here and perhaps talk about something more interesting.
Catherine: OK. So, Havok and Mono sound like great backend projects. Do you have any projects in the works to addres viewer stability?
Joe: We do, Catherine. Certainly the frequency of unplanned interruptions, let’s just say crashes, of the viewer is way, way too high. It has been for many quarters, and indeed is as much a priority for us as the backend improvements that I just described. But frankly, one of the first challenges we have had are improving the ways that we can see all the primary sources of these crashes, because as you can imagine, we have a wide range of users running a wide variety of computer configurations, many, many different combinations of graphics cards, and so on and so forth.
Frankly, the crash reporter has not been as helpful to us as we would like, to really be able to identify the primary source of the major problems there. So we spent the last quarter, the fourth quarter of 2007, rewriting completely the crash reporter function, within the viewer. That has now been shipped as part of the release candidate viewer that has been up for some time.
We are now able to see with much more clarity, the actual causes, the root causes, of the top ten sources of our crash problems, and we can deploy our viewer experts, our engineers associated with viewer functionality, directly where they need to be, to significantly address the crash rate in the viewer.
So, quite frankly, I don’t have enough data to be able to tell you that we have made a big difference yet, but we have the infrastructure in place for Q1, to be able to significantly reduce the frequency of crashes. I hope to be able to say at the end of Q1, we have reduced the crash rates by at least 50% over where we are today. We publish that data monthly. So you will be able to see how well we have done against this goal of actually cutting that number at least in half.
But we are doing some other things though, on the viewer. We have established much more closer fruitful dialog with the graphics card manufacturers themselves. We are in much tighter relationships with the engineers who are responsible for the drivers from ATI, from NVidia. We are working very closely with Apple as they begin to work on improving the level of functionality for 3-D graphics applications broadly on their platform.
We believe, this will actually finally allow us to identify the source of problems that we couldn’t control in the viewer that are inherent in graphics drivers. But again, none of that is going to happen without the assistance of the crash reporter as I have described, but also the dedicated team of engineers we have focused on the viewer stability project.
We have some other things we are doing with the viewer that I will mention, and this won’t be surprises to listeners of this podcast. The Windlight project has been in first look has actually been in first look now for well over a month. It is nearing the point of reaching a stage where we are going to begin to transition that functionality into the mainline viewer. It will show up as a release candidate here, in the next several weeks.
One of the interesting aspects of the Windlight technology is that the ability for users to dial the level of functionality that they want to try to achieve with their computer is made much easier. There is a simple slider now, a single slider that you can control, that trades off performance versus visual quality. We think that will go a long way to help people tune the performance of the viewer to their machine in a way that will allow them a much more predictable and stable environment for the viewer.
And we intend to head this direction with additional sort of streamlined user interface elements, simply to make it easier for people to set the viewer to a state that is much more appropriate for the equipment and the graphics capabilities they have. But some of that is visible in the Windlight trial.
The other thing that we are about ready to release is a project that we internally codenamed Dazzle. Dazzle is simply a project to modernize the look, feel, color, and the overall visual experience of the viewer that we think is long overdue. And again, it has been a project that several of our engineers and user interface professionals here at Linden Lab have been working on for some time. That will actually appear in a first look viewer in the next several weeks, probably three weeks from now.
Catherine: That’s great. To close on a personal note, it is 2008, what aspect of Second Life are you most excited about?
Joe: [laughs] Wow, interesting question, tough one, because I think, if I am not mistaken, Philip already took the education angle. I am very passionate about the educational uses of Second Life, both for formal learning and informal learning. But I think I am most excited about 2008 really being the year that the unique uses of 3-D worlds for true collaboration, whether it is learning, or building, or playing, become more self-evident.
That the ability to truly collaborate with either a shared experience that you can’t receive in a traditional 2-D web environment; or for that matter, technical improvements in the platform that allow true application sharing – the ability to bring up a document and work with 10 people around the world on reshaping a script or a story, or for that matter, a simple Word document. It is a truly shared environment. It is something that we will certainly see in 2008.
I think for me, the excitement for this year is really leveraging the unique aspects of the platform in ways that are going to be surprising, and will delight people who choose to sample what 3-D virtual worlds are all about. Certainly going to be an exciting year for us, because I think now the question of value of virtual worlds has been answered, now it is a matter of how rapidly can we move this forward to deliver on some of the bigger pieces of the promise.
Catherine: Great. Thank you for your time. I really appreciate it.
Joe: I look forward to doing this again.
Catherine: Yes, I think everybody will like that. Thank you everybody for listening and we will talk again next month.