An interesting post by a bloger made me……

OK, so Linden want Second Life to become the HTML of virtual worlds, the standard that everyone uses, but how best to get there? Is the choice between open-source and proprietary code, which often is the difference between evolution and revolution? Open-source is an amazing way to evolve code, many minds making light work of debugging and securing. Proprietary code is usually much more driven by innovation – you need to achieve what others have not in order to have/keep the advantage.

Second Life has been proprietary up till now and it’s got us this far. I know there’s a huge contingent of code-heads baying for the server code to go open-source too but do we pander to them and risk losing the momentum? Or is it now so bad that SL will fall without their help to stabilise and optimise the current system?

As far as shadows and light-fall effects go, there must be a middle way – surely it has to be about appropriate technology? The only objects that need live-rendered shadows are the moving ones, everything static like buildings would be equally effective with baked shadows – maybe rendered once in-world as i suggested before. Maybe we could have the best of both worlds that way?

Now if this were true, I wonder if then it might make sense to allow better shadowing because the server can optionally spend less time loading up assets, or can control that loading a bit better.

RealXtend has shading as part of their basic architecture. And it doesn’t seem to cause lag, although it’s hard to tell since the platform is still fairly new and has other issues.

Having said all that, none of this matters if they can’t keep a basic grid up and running. These asset server issues have gone beyond a nuisance, in my opinion, and are fundamentally undermining SL as a platform. Glitches are one thing, but Philip spent a lot of time preaching how their number one priority was grid stability.

They’ve either made the wrong technology choices, don’t have the requisite sense of urgency, or, well, just don’t have a clue. For education institutes, corporations and in-world entrepreneurs (not to mention casual users, the lifeblood), to find the grid LESS stable after all the preaching about needing stability instills negative confidence.

Let’s remember that it was 9 months ago that Philip gave his keynote at the SLCC, and I’ll quote from a live blog of it:

One of the things we can do to start improving quality is publishing our internal metrics the same way we’ve been pushing economic metrics out there. This line [of stability] has been fairly flat since March. We’d like to have it go down, but it’s also stable. You can’t pick out the big releases that some people think are causing problems. We’re not actively screwing things up as much as you may think. By tracking and getting very serious about inventory loss, and there’s 20 different equally weighted ways to lose inventory, we can do better.

Um. I sort of take exception to that. But maybe he’s right “We’re not actively screwing things up as much as you might think”……BUT GIVE US TIME WE’LL GET THERE!

I’ve found myself often wishing for a ‘bake-shadow’ option within SL itself. So that when u finish a build or object you could right-click and choose ‘Add Shadows’ and the SL client would take a minute or two to render and ‘bake’ your object’s textures with light and shadows appropriate to SL’s lighting model.

It could be done client-side, avoiding server lag, and would then deliver you a set of baked textures specific to your object. If everyone had access to an inworld option for doing this there would be some visual continuity across SL and it could make things look that bit more ‘real’ without the huge overheads of rendering live shadows.

It’ll never happen of course – we appear to have had THREE failures of Asset Servers last night – so first things first.