On a platform where every object needs to be rezzed from the point of viewing, Second Life has had to make trade-offs to the appearance of the world. On gaming platforms, these trade-offs are handled through things like texture baking, polygon counts, and distribution of content on CD.
Platforms like Blue Mars are throwing caution to the wind and assuming that computer power will continue to grow exponentially, to the point where the world will catch up to THEM rather than them catch up to the world. The difference in the visual appearance can be astonishing. Blue Mars will run off the Crysis engine. In the meantime, Second Life has scrambled to manage the visual display of the world while trying not to leave too many users in the dust, unable to access the Grid (or at least see it in all its full glory) if they don’t keep their graphics cards and processor speed up-to-date.
One of the major issues with how the world looks is shadows. Windlight gave us sky and water - a major step forward in how the world looks. While Windlight adds a lot, it was also, um, watered down in my opinion. Earlier release versions of Windlight had more punch, and until Linden releases the ability to control the environment settings at the region level, it will never have the full impact it could have.
But it’s not just wind and water that a world of beauty makes - it’s also shadows. And ambient occlusion is one piece of the puzzle being worked on in a cubbyhole somewhere at the Lab. Dave has been running tests of ambient occlusion which is defined according to Wikipedia:
Ambient occlusion is a shading method used in 3D computer graphics which helps add realism to local reflection models by taking into account attenuation of light due to occlusion. Unlike local methods like Phong shading, ambient occlusion is a global method, meaning the illumination at each point is a function of other geometry in the scene. However, it is a very crude approximation to full global illumination. The soft appearance achieved by ambient occlusion alone is similar to the way an object appears on an overcast day.
Dave has posted some tests of ambient occlusion, or as he calls it deferred rendering. The screen shots are encouraging:
I doubt that live-rendered shadows will arrive in SL anytime soon but there could be worthwhile compromises while we wait…
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.
Interesting idea Eris. I don’t have enough insight into where SL is headed, but I understand that one idea is to move objects closer to source (i.e. embed objects within the sim architecture rather than a central asset server). If this is a prelude to opening up the architecture in order to allow individuals and groups to host their own servers it might make some sense - host not only the sim but also the object repository. If this were true, I wonder if it would then be possible to pre-load objects? Either distribute on a CD or otherwise make the user wait while a sim preloads before entering, sort of giving more control over the experience.
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!
You’re right about current performance in SL, we’re way past the annoyance stage and now we’re going to start haemorrhaging the less committed users - and those that are left should probably be committed immediately.
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?
Virtual Cd 9.0…
An interesting post by a bloger made me……
A fantastic site, and brilliant effort. A great piece of work.l