The Firestorm Viewer Team is thinking. Their recent April Fool’s Joke about the Dynamic User Interface (DUI), the detachable control panels, has been the goal of many developers for some time. Now Firestorm Team member Nicky Dasmijn has built a proof of concept version of the viewer with those detachable panels. In this version window and panel layouts can be saved for later use.
There is no release version of this viewer, beta or otherwise. But the team is releasing the code some other developers can work on the project. The Firestorm Team is hoping the code will inspire developers to come up with new innovations for the Second Life viewer.
See the official announcement here: The real joke… DUI is no joke!
My thinking
Maybe we are seeing the Lab’s fast paced viewer development discouraging third-party developers. Some may find they spend all her time keeping up rather than being able to innovate.
In some cases, like the Dolphin Viewer, the developer’s RL got busy. But, whatever the reasons we have fewer third-party developers moving viewer technology forward. I like being on the cutting edge and when third-party viewers were the cutting edge I used them much more than the official Second Life release viewer and betas. Now it’s the other way around.
However, the recent Firestorm Viewer release is one that I use for a portion of my time in Second Life. It has features that I enjoy using. But, the SL Viewer is updating its technology and generally providing better performance, at least on my hardware.
With the recent announcement from OpenGL that games using OpenGL can perform 15 times faster than they are now, I would be much more excited to see those changes being integrated into a viewer. And that is 15 times faster not 15% faster. Or said another way: 1500% faster.
I suspect changing to the new OpenGL would be a significant task. So I would expect only CtrlAltStudio or Exodus to be the only viewers that would attempt that task. I expect the lab to put the task in their priority list, but I don’t know that we will hear anything about it if they do.
Whatever the case, I’m just happy to still see new stuff coming to viewers.
I have been told that the thing holding LL back from updating to the latest OpenGL is backward compatibility. There are simply too many people with older graphics cards who would not be able to use SL at all! Not being a programer I have to take the word of others about such things so I could of course be full of hewie. It sure would be nice if I was wrong.
It isn’t so much ‘updating’ to a newer OpenGL as it is using the new features in OpenGL. We update OpenGL whenever we update our video drivers. But, whatever the case, it is hard to know what can or cannot be done with SL’s render engine.
However, you have to consider that both AMD and NVidia limit driver support to “legacy” releases for certain older hardware with outdated chipsets.
As I understand, it’s a network of several factors, not just a simple update to a driver component. I imagine that the chipsets in certain hardware will simply lack the cues to execute a new OpenGL version and that’s where Shug’s example would come in.
If there was a proper chart showing how many people still use a Radeon 4xxx or a GeForce 4xx or even the really crappiest onboard graphics to connect, it would give an idea how many people would be lost if SL progresses.
There’s a lot people can blame on LL. But failure to support a huge range of different hardware config certainly isn’t part of it. A blessing for those on low budgets and/or outdated hardware and a hinderance for those with capable hardware.
“Shared experience” Linden’s mandate that we all see the same — please !! my invis prim shoes were broken in the newer viewers , I have to block people at crowded events because their rigged mesh fills my screen as it smears out to the sims 0 point.
Apple development is stopped or slowed — so things for people using macs will keep getting worse.
Instead of Linden trying to control things they should let inventors invent. UNLESS the Lab will make everything appear the same themselves they should butt out.
Ego wise / control wise the Lab wants to be the one viewer — but the TPVs provide a much richer experience.
I have two issues with the SL viewer, there is no native AO, and I have trouble getting it as light as the Firestorm.
\New OpenGL\ nVidia spoke of in the presentation is not a cross-vendor standard to begin with, it’s a set of techniques, which, in part, can be implemented with established OpenGL features, and in other, new sets of extensions to OpenGL, which do not match neither in nomenclature nor in semantics between nVidia and AMD, and i didn’t even begin the research apropos Intel and Apple OpenGL yet. So this is the scope of the project that is best handled by LL, simply because none of the teams, even though i would be comfortable modifying the engine in this regard, we simply don’t have a sufficient stash of test gear in-house and i’m afraid testing this by community will go wrong.
The path advocated by nVidia is basically a temporary vendor performance lock-in, that is, high-performance mode which currently only works on nVidia, and a waterfall of low-performance fallbacks for all other units, with some hand-waving that eventually, these extensions should become universal as nVidia is promoting its vision of low-overhead OpenGL to standard, and the others will catch up eventually and use the non-fallback path. In practice, the extensions would be implemented by others next week if it was an AAA title, but if small studios and SL viewer will be the only ones to use them, then you can expect 5-10 years till they become universal. Lack of OpenGL AAA titles in development is obviously an issue. AMD has released Mantle API, which bound their attention, driver developer resources, and developer support resources, and further down the road, Intel and AMD will be promoting DirectX12 for low-overhead drawing. Further issue is Apple covering 6% of our target, with its quality negligence towards OpenGL, impossibility of driver updates on older OSes, and unwillingness of most users to update whole OS for the fear of breaking other software.
The purpose of these techniques is to reduce the CPU overhead, and the 15-fold performance increase claimed corresponds to an (at least) 15-fold decrease of CPU overhead compared to trivial code, because in their demos the software doesn’t do anything but draw some geometry. It is to be kept in mind, that the viewer’s case does not correspond to trivial code, it already uses some advanced techniques in this regard, that, at least on wide multitexturing-capable GPUs, should in theory lead to almost 16-fold reduction of CPU overhead, compared to trivial draw code. What GPUs does this currently work with? Well, shaders must be enabled, and then look at this table:
http://feedback.wildfiregames.com/report/opengl/feature/GL_MAX_TEXTURE_IMAGE_UNITS_ARB
The ones which have the GL_MAX_TEXTURE_IMAGE_UNITS_ARB value of at least 16 draw the maximum advantage out today’s SL engine. Plus all the newer GPUs which didn’t land on this table yet. You can say, any GPU that is anywhere near relevant supports that.
It is possible, that some of the techniques shown by nVidia can have further advantage than indicated by the simplistic benchmark, since the bottleneck is moved, but it won’t be nearly as radical as you appear to expect. As well, you can expect that the SL viewer texture-index technique does not reach its full potential, so there is a possibility of gain from new techniques.
A significant complication is complexity explosion in the engine, because we would not be content with low-performance fallbacks, we need as high-performance fallbacks as possible.
Thanks for the explanation.
I guess you missed the link to download the viewer Nalates. Yes, there is a viewer to test this feature and is publicly accesible. The feature is very buggy tho as expected and the viewer seems to be a bit slower.
I noticed there was a proof-of-concept viewer. As a proof-of-concept viewer I don’t consider it a usable viewer. Software that is pre-Alpha version is usually unusable or just barely usable, which you seem to confirm.
My take on the FS article is that they are not recommending people download and try it.
I wonder when it became unpopular to run your SL viewer in fullscreen mode.
For many it is a performance issue. A smaller SL Viewer window means less work for the viewer and GPU.
For others the small window means easier multi-tasking. I’m one of those people.
I doubt we have any stats on how many run full screen verses window. So, I would not make the assumption full screen mode is becoming unpopular.
I think being able to undock panels and move them outside the render area would likely encourage people to run the viewer as a window.I would certainly like to see the feature developed. It would work well for my style of use.
I would assume that any statistics would be heavily in favor of windowed mode since the official viewer doesnt even offer fullscreen mode anymore.
I didnt know that windowed mode is less performance heavy though, thanks for that bit of knowledge!
o.O The SL Viewer runs full screen…