SL Beta Viewer
There have been some rendering issues with the last release of the beta viewer (3.4.4.268497, December 20, 2012) which had caused the Lab a slight headache in that not all tests are giving the same results. However, a further 3.4.4 release is anticipated for either Monday 7th or Tuesday 8th January, 2013, which includes various fixes. Whether these are related to the rendering issues is unclear. However, they have not as yet been merged into the Sunshine Project (Avatar baking – see below).
CHUI – Communications Hub User Interface
As reported over the holiday period, the CHUI project is moving forward, with a further update of the project viewer and several updates to the development version of the viewer, possibly the result of code refactoring work which had been indicated as being required prior to the holidays. However, as of the TPV Developer Meeting of Friday 4th January, 2013, it was unclear as to whether this refactoring work has been completed.
Currently, the code has yet to be made available to TPVs, and concerns have been raised by some TPV developers that integrating the CHUI code could be as much a headache as the Avatar Baking code. Given the work some have put into the communications elements of their own viewers, it is also possible that some might opt to cherry-pick which elements of the CHUI code they will adopt. Whether CHUI is liable to be deployed before or after the Avatar Baking project remains to be seen, as the Lab has yet to make a decision either way.
Server-side Avatar Baking
Project Sunshine, the work to implement a new server-side baking process, kicked-off (as far as TPVs are concerned) just before Christmas. This represents a substantial code merge for TPVs, and one which is going to take TPVs a while to handle as a result, hence the reason why LL have given TPVs a long lead-time on the project, with around an eight-week window available for them to work on the code, provide feedback and assist with testing.
As mentioned in my detailed look at the new service (see link above), any deployment of the server code will be dependant upon further and significant load tests, which are viewed as essential in ensuring the new compositing service has sufficient hardware for it to support avatar baking across the entire grid. At the time that article was written, Nyx indicated that details on how the load tests would be handed had not been finalised.
Speaking at the TPV Developer Meeting, Oz indicated that these tests are still under consideration, and as such, much in the project is still up in the air in terms of unknowns. Obviously, on way in which load tests can be carried out is to have more test / development viewers available to enable greater testing of the server-side code, so overall implementation of the new service is somewhat symbiotic, and it is unlikely there will be a large-scale deployment of the service prior to TPVs being sufficiently comfortable / up-to-speed with integrating the code into their viewers.
As such, it is unlikely that there will be any major move on the Lab’s part to push the project forward much before the end of February. With regards to this, Oz commented, “Obviously, what we’d like to know is that we’ve got at least one version of all the third-party viewers that are prepared to cope with it, and that certainly getting an affirmative on as many of those as possible before we make a final call on what our target dates are would be really great. So that’s why we’re keeping the pressure on you to do that testing, as we’d rather you were ready before we were.”
Materials Processing
The materials processing project continues to move forward, although there are growing concerns over the fact that the viewer will be required to run in deferred mode (i.e. with shadows & lighting active) in order for the new capabilities to be properly rendered. This means that computers which do not have sufficient processing capabilities to run in deferred mode will not be able to render the effects of normal and specular maps, and so will not see the effects of materials processing.
However, this does not mean that those unable to run SL reliably or reasonably with deferred rendering enabled will have their SL experience negatively impacted. The expectation is that users on such system will continue to see SL as we all see it today, regardless as to whether or not in-world objects and avatar attachments (prim, sculpt or mesh) are using the new materials capabilities.
However, this is also conditional on content creators understanding how to correctly make use of materials process as it will apply to Second Life (especially those trying to leverage the new capabilities, but who may not themselves be able to run the viewer in deferred mode), and ensuring they use underpinning diffuse maps (textures) of a suitable quality. To help ensure this, Oz Linden has stated he will give those at the Lab responsible for the Good Building Practices guide on the wiki a nudge so that it is expanded to cover materials processing.
That materials processing does require running the viewer in deferred mode has given rise to concerns as to how widely the capability will be adopted. However, the Lab has no plans to try to implement materials processing in a way which does not require deferred rendering (assuming this could be done). This is not to exclude anyone from experiencing it, but rather because the capability simply requires deferred rendering to be enabled. Whether or not the capability will introduce an additional overheads to running in deferred has yet to be fully determined.
In the meantime, the repro for the viewer-side code required for materials processing will be officially made available (it was accidentally exposed just before Christmas), some time in the next two weeks or so, and a project viewer should appear shortly thereafter. The server-side code is thought to be in, “Pretty good shape.”
Rendering Changes and GPU Table Updates
With reference to viewer rendering as a whole, Runitai Linden has been working on the viewer’s rendering system for some time now. This work has included improvements to GPU support within the viewer, with both further graphics cards added to the GPU table (which is used to define the default graphics setting for a viewer when you first run it) and the removal some of the generic “catch-all” options from the table (such as all unrecognised nVidia cards being detected as nVidia Ion GPUs), and so on. Additionally, the graphic settings with the viewer preferences have been updated to allow a greater granularity of settings.
The aim of this work is to try to better tune the viewer to a GPU’s capabilities by basing default settings on the actual frame rates experienced using specific graphics systems. People are still free to adjust their settings if they so wish, although this can obviously have a detrimental impact on performance / in-world rendering depending upon which way the slider is adjusted.
One outcome of this work is that some users may find that their viewer starts running with deferred mode enabled by default, where previously it may not have, and experience a potential performance degradation over what they’ve previously experienced, leading them to assume the more recent viewer release is “broken” or has performance issues. Should this happen, it is worth taking a moment to open Graphics -> Preferences and checking the Quality & Speed slider to see if the update has adjusted it from an expected default, and then perhaps adjusting it accordingly.
These changes mean that those TPVs which have not already incorporated them will likely be doing so in future releases, which may in turn see the default settings change for users on updating, depending on decisions made within the dev teams themselves (i.e. whether to use LL’s defaults or stay with their own).
Viewer Text Font
The SL viewer, together with some TPVs use Free Type for text rendering in the viewer UI. It’s been noted that the version of Free Type in use in the SL viewer varies according to OS build and that, more particularly an issue of text not rendering consistently as white in the viewer has been added to with something of a degradation in rendering quality, particularly on the Windows build, since an updated to Free Type 2.4. As a result, Firestorm has / will be reverting to 2.3.9, which provides better rendering quality.
HTTP Project Work
Monty Linden has been working on the server-side HTTP communications service updates. As so many SL services are transiting over from UDP to HTTP (such as the texture fetch library, the Group Services project, the upcoming new server-side baking process, etc.), Monty has been concerned over the overall robustness of the server-side code in terms of failover and fall backs should problems occur within the service itself, and that while the primary work on the server code for the HTTP libraries is now complete, he’s been focused on these issues – which he refers to as “defensive actions”.
At the same time, he’s also looking at the question of metrics. He’s been building an analysis system to gather metrics on the new services. Once the core work has cleared QA, his plan is to put up a number of different server-side configurations on Aditi and have people come in and test them in order to gather metrics on which configurations offer the best options for wider implementation.
There is no overall timescale for this work, which should see Monty return to focusing on the viewer side of the HTTP equation once it has been rolled out, and he describes it as being in something of a “race” with the avatar baking service although schedules have yet to be decided.
In the longer term, and once he is confident that the new HTTP libraries are offering a better, more reliable service for the majority of users than their older UDP counterparts, Monty hopes to be able to gradually remove the UDP code from the platform. However, this is liable to be a protracted process as he commented at the Friday TPV Developer meeting that, “The UDP assumption is baked into a lot of failover paths and hidden mechanisms, it’s all over the place. So I’m always nervous about removing it blindly; but, when the opportunity arises, yup, we’re going to look at that question.”
An interesting side point to this work is that as he started on it, Monty carried out a number of investigations into routers opening multiple parallel http requests, and found that on certain older routers, the firmware will lock you out of the router for up to 5 minutes, simply as a result of this (he specifically mentioned older Belkin Wireless G routers in this regard and the Linksys WRT router was also mentioned back in July as falling into the same category). Overall, the problem primarily resides in low-cost, slightly older routers from the likes of Belkin and Linksys. So, if you are experiencing issues with “SL crashing your router” when running the viewer with HTTP enabled and are using an older model from the likes of Belkin or Linksys, the issue may actually reside within the router’s firmware.
Related Links
- Good Building Practices guide – SL wiki
Inara Pey: Living in a Modemworld 
Maybe if people understood that materials rendering is a means to save a great many prims or significantly reduce LI while still getting lots of realistic detail it would seem less foreign or forced upon them. Also, I’m not sure that I see deferred mode or Lighting and shadows as an impediment to their adoption. Lighting and Shadows (even though I have shadows off for the most part) is simply much prettier, perhaps not the difference between windlight and not, but a big improvement on how the world looks. If people are not using it because they find it overtaxes their systems, then deferred rendering should be a canary in the coal mine type warning for them that they are missing out and that some upgrading may be required to keep them from missing out on still more to come.
Anyway, I for one can see the potential (at least in the transition phase) for offering 2 versions of some products – a version with normal and specularity maps applied and resulting LI as low as I can possibly go, and a higher poly, no materials version which would perhaps show about half as much detail as that used to render the maps, but probably at much higher LI, and slower render time for any system viewing it.
Since on some level we’ve always been trying to realize the maximum aesthetic from the minimum LI and render cost, materials are just one more way to tip the balance in favor of aesthetics. I can’t see any reason not to welcome them. And if all people have to do is enable a setting that also happens to greatly improve the quality and clarity of light, well, flip the switch already.
LikeLike
I think the concerns raised in the TPV meeting were, to a degree, misplaced – if entirely understandable when looking at things from a support point-of-view. However, if SL is going to maintain broad-based appeal and present new users with something that reasonably meets expectations in terms of in-world looks, it is important the platform moves ahead.
LL are constantly getting hammered over the appearance of SL, and materials processing could work more wonders (in time) to the overall look and feel of SL than mesh has perhaps achieved. If nothing else, materials should be far more accessible to a wider audience of content creators simply because it offers a broader spectrum of uses, particularly where existing / new prim builds are concerned, as it would seem to naturally lend itself to being supplied in “builders packs” for those without the knowledge / time / whatever to produce maps for themselves, thus allowing for easier adoption and use.
Like you, I run in deferred. I’m lucky as I have a set-up which allows me to do so – but it is hardly cutting-edge. I’t pass 5 years old this year, it has a pre-Ivy range CPU (although admittedly a Q6600 quad-core) and a moderately good older GPU – the Ge9800 GT (which I actually upgraded to after digging around to find out what worked with SL anf fitted my personal upgrade budget of £60-£70 ($96-$112)). However, not everyone is in the same boat as even that, hardware-wise. Hence why LL are doing more with the “back-end” as well to try and improve things through the work on the rendering engine, the GPU tables and so on – they are trying to offer everyone a middle ground, and full kudos for them for doing so.
There’s also the fact that – as I’ve reported – providing the underpinning textures used with the materials capability are of a good quality (and there is no inherent reason to assume that when materials goes live, texture quality is going to nosedive), then SL’s look and feel shouldn’t be in any way degraded compared to what people are seeing today, whether running in deferred or not.
So I am, as you are, looking forward to materials arriving – and am also looking forward to other enhancements LL is apparently working on with the Exodus team as well (such as the improvement such Shiny I mentioned back in a week 51 project report).
LikeLike
Oh wow. I had no idea that materials had been launched! 😦
In truth, I wouldn’t have noticed it… my old iMac has a partially-melted graphics card (yes, really!) which lost the ability to even show Windlight. Which is a pity, really — before the meltdown, even though the iMac is now entering its 7th year of continuous operation, I was able to fully see shadows in deferred mode in SL 3.3, and even got enough FPS to be able to move around, which has been, for me, the most dramatic improvement that LL had done to their renderer in 2012 🙂 (for years I’ve pined for shadows to work correctly).
This is just to pipe in that even very ancient hardware (assuming it is still working!) may be be to run in deferred mode, thanks to the incredible improvements that LL has been doing since SL 3.3…
LikeLike
Ummm… it hasn’t :).
There has been debate about the fact it requires the viewer to run in deferred mode, and the code repro was accidentally revealed prior to Xmas, but if you check the last para, the official release of the viewer-side repro to TPVs is still a couple of weeks away. Currently, there is still no official “launch date” for materials processing.
LikeLike