Several things are coming together. First is my slow FPS rate. I’m looking for a solution. I can’t find my processing bottle neck. The research is taking me far outside Second Life ®. Complaints about slow or poor performance in OpenGL based games are not limited to Second Life. So, I’m not accepting it is solely poor programming on the Lab’s part.
As one moves through the technology world in such a search it is obvious that we are becoming highly dependent on computer technology. OMG! At my favorite bar they did a BBQ event and brought in a company to do the BBQ food. Patrons pay the caterer direct for the food. The cash register was an iPad with an app.
Leaving all our tech at work or home on a desktop is a problem. Everything is moving toward portable devices. Size is an issue. The human form creates some limits. The ease with which we can carry and use things creates a sizing dichotomy. Devices need to be big enough so we can easily see detail and use our fingers. They need to be small enough to fit in a pocket or somehow be carried and leave our hands free.
Google Glasses or holographic displays… the energy requirement for visible-in-daylight-holograms is prohibitive for now. So, Google Glasses may be the immediate winner in the dilemma.
Whatever wins and people find useful, the supporting technologies of rendering 3D things is seen as a major factor. We know these underlying technologies as DirectX/Direct3D and OpenGL. We know DirectX is a Microsoft patented process. Few realize much of the underlying OpenGL technology is patented too, or so says the Wikipedia. See the references there if you’re curious about that.
The new WebGL and HTML5 are to provide ever better graphics within our browsers. All that technology comes back to Direct3D and OpenGL. Browser makers like Chrome and Firefox are using an intermediate program (ANGLE) to translate requests for 3D imagery into something the DirectX9-Direct3D can understand and paint on your screen. It seems DirectX9 is the most common 3D drawing technology across all computers.
Both Direct3D and OpenGL run in smart phones and small portable devices. The support is getting better. So, it seems that it won’t be long until such devices can support Second Life. Well, at least Second Life’s rendering engine, the part that paints the picture on the screen.
However, the current support gap is in bandwidth, being able to get all the 3D data needed to paint the picture. The current state of technology is such that it is like having a paint by number kit. There is no problem with paint and brushes, those are there as Direct3D and OpenGL. The problem is getting the outlines (geometry in 3D parlance) and color list – which number is which color (the textures in 3D parlance) to the device. Even 4G units have a problem collecting all this information fast enough to create the real time experience we have in Second Life. Let’s not even talk about the cost of that data transfer.
The bandwidth issue reveals the current technology bottleneck.
When one is following Second Life bits and pieces turn up in various social media. For instance Hamlet writing about Glass Door employee reviews of Linden Lab®. One of the pro’s listed is that development in the Lab is web and tablet oriented.
Since we know the various sources touched on above, that graphics 3D imaging is less and less a problem the technical obstacles of data transfer are the areas for innovation. Linden Lab had to overcome these problems when SL started. High speed Internet was not a common Internet connection then. Now as we move to the tablet based devices we run into it again.
Providing the terabytes of data that make up SL is not going to be feasible in the near term. So, the new applications the Lab is working on are likely to be far less bandwidth intense.
Also, many of the changes we would like to see in Second Life are prevented by legacy factors. Changing the avatar is one of those. Over the last couple of months I’ve come to realize what a problem avatar 1.0 is (well, the current avatar is the only one I’ve ever known, so I’ll label it 1.0). The actual mesh and the vertex weighting both have problems. These cause additional problems as we move toward using more mesh clothes.
By moving to new products, the Lab has a chance to correct legacy problems. But, abandoning the rich resources available in Second Life seems foolish. I am left wondering if the new products will leverage the rich resources from SL for use with a web or tablet oriented application.
We see Unreal SDK providing support for a game based in Wii, Xbox, PC, and smart devices. The base 3D models can be used for whatever device is being targeted. Is the Lab thinking of a similar strategy? In time we’ll have an answer. For now it seems a reasonable speculation the Lab will come out with collaborative creative tools that are far less data, or at least bandwidth, intense.
and until all that, nirans viewer!
I’ve run Second Life happily on a 1GB link on a desktop PC and regularly on a 2GB link on a netbook – the bandwidth used is not very much once the textures are loaded, and if you are always at just a few sims you can make sure they are cached the first few times and then data loads are reduced. LTE is rolled out already in Japan and is being tested in UK, Australia and other countries – this will provide mobile broadband at better than fixed line or cable speeds for many.
The big challenge I see at present is the processing power of mobile devices – but this should change very soon, and Windows 8 will also promote a surge in developments as manufacturers go after this growing market. Second Life will need a new viewer or web interface for mobile devices but that is not a big deal and should be popular, but I also see a lot of competitors going after the social 3D space.
“First is my slow FPS rate. I’m looking for a solution. I can’t find my processing bottle neck.”
It’s likely at the processor level: if you got one core at 100% (or two cores at 50%, or 4 cores at 25%) while running second life and the “Render” -> “Swap” fast timer (or “GL finish” for the Cool VL Viewer) is below 2ms, then this is clearly the case.
For old hardware, the bottleneck will be the graphics card and/or the bus it’s plugged on (with a “Swap”/”GL finish” fast timer rocketing at several dozens of ms), with, for mesh-viewers (which are SSE2 optimized), a CPU load that will be less than 100% (or less than 100% of one core for multi-core CPUs).
Modern GPUs can take all what the viewer can throw at them (even with shadows and everything maxed out) without a problem.
The problem with the viewer as it is currently coded is that it can only use one CPU core for its render pipeline (the OS can then spread the load via time-slicing over several cores, but it doesn’t change the fact that at any given time, only one core is executing the render pipeline code).
“Complaints about slow or poor performance in OpenGL based games are not limited to Second Life”
OpenGL is no better and no worst than DirectX, performance-wise, but some OpenGL implementations are notably slower than their DirectX counterparts. This is especially the case with ATI drivers that got a very poor OpenGL implementation. NVidia’s, on the other hand, performs pretty much the same as their DirectX drivers.
There’s also the OS issue: ATI’s OpenGL is notably faster when ran under Linux than under Windows (saw that on a notebook with a Mobility Radeon 9700: under Linux the FPS rate is twice what I get under Windows XP with it, while on my desktop PC with a NVidia card and drivers the viewer performs the same under both Linux and Windows).
LOL