Update: In further tests of the FIRE-9097 “fix” at lower resolutions (e.g. 2650 pixels across), I found it can re-introduce the tiling artefacts in snapshots.
General Viewer News
Materials Processing
The release of an update to the materials beta viewer on Wednesday June 5th (3.6.0.276961) was followed at the weekend by the arrival of a further beta version – 3.6.0.277049 – with accompanying release notes. Commenting on the rapid-fire releases, Oz linden said at the Content Creation User Group meeting on Monday June 10th, “We’re getting close to the end of its beta cycle (or put another way… report your bugs now).”
Snapshot Issues
We’re all aware of the snapshot tiling issue which plagued SL photographers for a good while, which would leave “tiling” artefacts on images taken at higher resolutions than the user’s monitor resolution when running in deferred mode (now known as Advanced Lighting Model). A fix for this issue (MAINT-628) finally reached the public in late 2012, but brought with it some additional issues. On of the most notable of these was the appearance of black rectangles in very high resolution images.
This latter problem most recently caused an additional outcry when the LL “tiling” fix was finally incorporated in Firestorm viewer earlier in 2013, with many users incorrectly blaming the Firestorm team for the problem.
Well, for all and sundry, Firestorm users or otherwise, there is some potentially good news on the horizon.
Commenting on the broader issues reported with snapshots duing the Open-source Dev meeting on Monday June 10th, Oz Linden said:
It looks like there are fixes in the MAINT pipeline for those. I don’t know how soon those will be out… I can try to find out if they have a project build ready.
Additionally, there is further news specifically for Firestosm users. While it is somewhat outside the scope of “SL project news”, it is neverthless reporting here.
Nicky Dasmijn has been working on the problem, and has implemented a fix for the issue (see Firestorm JIRA FIRE-9097), which should correct matters for snaps of up to 4096×4096 pixels without any “rectangle” artefacts appearing or with any regression to issues of tiling, and which may work at high resolutions than that for some.
I tried a very rough-and-ready test of the fix. I found that capturing images up to 5,000-5,600 pixels across with the aspect ratio maintained worked OK for me. Anything around 6,000 pixels across saw JPG images save OK, but rectangle artefacts begin to appear when saving in PNG (see both images on the right)
However, as I’ve recently been experiencing other GPU issues, I’ve been unable to ascertain if the rectangles are down to an issue with the code or simply a matter of my GPU running out of resources when processing PNG images above 5600 pixels across.
The fix is currently in a recent Firestorm pre-release, and will hopefully make the cut for the next formal release. It is currently unclear whether the code has been / will be contributed to LL, and if so, whether they will adopt it or opt to go with their own forthcoming updates (as indicated by Oz in his statement above) or opt to combine it with their own fixes (depending on the nature & scope of the latter).
Future “STORM Project Viewer” Release
There are a number of code contributions which have come via the Snowstorm route which have been queued awaiting a suitable release. These cover a range of additions to the viewer, and example of which is STORM-68 (As a Builder, I want that ability to set default permissions on creation of objects, clothing, scripts, notecards, etc.).
Commenting on STORM contributions in general, and in light of the forthcoming changes to the viewer release process, Oz said, “I’m trying to get all the storm issues merged up so that I can be ready to put out a project viewer as soon as the new viewer version manager is deployed.” Whether STORM-68 (which is apparently seen as “largely good to go”, although it may also require a server-side change), or the fixes for snapshot issues mentioned above will be among them remains to be seen. However, a “STORM” project viewer could well be adding even more features to the SL viewer in the near future.
Mesh Deformer
There is actually not a lot to report here, other than that at the Content Creation User Group meeting on Monday June 10th, Mona Eberhardt asked, “What’s the current status of the mesh deformer? What features have been requested by content creators? Of these features, which are the most important and which could be omitted or postponed?”
Attending the meeting, Oz Linden replied:
The deformer is waiting for LL resources to evaluate how well it works and what its performance impact is. I have not been able to get the required people on it yet. I’m optimistic that will happen, but can’t offer any timeline. Sorry… I know that’s not a great answer, but consider that it could be worse.
Commenting on the deformer’s functionality and the wide-ranging discussion around it, including additional JIRAs which might impact it, such as STORM-1800 (The vertex weights of the default character mesh could be better), Oz went on to observe:
The target functionality is, I think, clearly described in the Description of the JIRA issue [STORM-1716]. Note that I did not say “and the comments”. That having been said, I personally have some doubts as to the total workflow – the confidence that the avatar bases being used are actually consistent. But I’m not really the right person to answer that question, just someone asking it. Note for example that if we accepted any of the changes offered in STORM-1800, we’d be changing some aspects of that base.
The concern here that accepting changes in STORM-1800 might result in content breakage if things are not thoroughly tested beforehand, if they were to be accepted.
So at the moment, it remains the case that the Lab isn’t purposefully delaying the deformer, but rather that resources are still stretched, and the focus is on other projects. It is more than likely that resources will not be available prior to SSB/A being deployed across the main grid and the materials viewer reaching a release status.
Server-side Baking / Appearance
SUN-38 / Z-offset
Concerns continue about the loss of on-the-fly avatar height offset adjustments within TPVs as a result of the SSB/A changes to the viewer code. As previously reported in this blog, The initial resolution for matters as released by the Lab only addressed one aspect of the z-offset issue, which was fair enough in some respects, as it addressed a problem which had been defined to them. However, it fails to address on-the-fly height adjustments which some users find particularly beneficial when dealing with a range of issues, as covered by SUN-38.
Again, as reported previously reported, the broader issues of avatar height adjustment will not be addressed prior to SSB/A going live across the main grid, as Nyx Linden explained at the Content Creation User Group meeting when asked specifically about SUN-38, “[There’s] no real progress on this one, it’s not considered a blocker for the initial rollout.”
When asked if the matter might be fixed after deployment and if so, what priority it might be given, Nyx refused to be drawn, saying, “We’re focused on the first release for now. I’m not going to guarantee any priorities after that.” It was also suggested that a fix would be a “trivial” matter to implement, although Nyx did not agree this to be the case, noting that, “It’s more complex than you think.”
Again, this does not mean the Lab is ignoring the issue; Nyx has previously indicated the matter continues to be looked into. However,given that the problem isn’t seen as a showstopper by the Lab, it’s just that the Lab’s focus and resources are being directed elsewhere in trying to get the service deployed. Nevertheless, as has been noted here, Cinder Roxley is working on a possible fix for TPVs, and I hope to have an update on that in the near future.
SUN-74
The issue occurring within some non-maintained viewers which do not have SSB/A support and which might result in some worn assets (skin, hairbase and eyes) being corrupted – see here for details – was finally repro’d successfully by the Lab in week 23. Since then, investigations have been ongoing.
However, the fact still remains that the easiest way for users to avoid any such issues from occurring is to update to one of the available supported viewers which are already updated to support SSB/A (the SL viewer, Cool VL Firestorm, Kokua, Niran’s, RLV, Sinuglarity) or one of the maintained viewers which should hopefully be updated to support SSB/A shortly (Catzip, Dolphin, Exodus).
Given that those still on the non-maintained viewers / viewer versin strings will have tp update / swap to an SSB/A-enabled viewer to avoid seeing a world of grey avatars, it would appear to make sense for them to update sooner rather than later.
COF Corruption
In April, I reported on corruption issues affecting the Current Outfit Folder, noting the particular experience of AngusGraham Ceawlin in February 2012 (see JIRA SVC-7653), but which has raised considerable concerns should it occur following the SSB/A deployment, as the issue can result in the affected account being unable to log-in to SL, and the current Lab-side fix will only be applied if said account is Premium. What is worse is that should a user experience the problem, the accepted “non-Premium” workaround for the problem (see the blog link above for details) won’t work.
Commenting on the situation, Nyx Linden said, “We don’t have reason to believe that COF failures will be more prevalent than in pre-SSA regions, and we’re looking into ways at making the relevant inventory operations more reliable.” As such, it is again unlikely that COF concerns will be seen as a reason to delay SSB/A further.
That the SSB/A team are working on improving inventory reliability has been previously indicated by Oz Linden, and it is likely that more of this work will see the light of day with the viewer update which is expected to be deployed shortly after SSB/A has been enabled across the grid.
Inara Pey: Living in a Modemworld 