The majority of the following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, February 21st, 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.
SL Viewer Updates
The BugSplat RC viewer, version 6.1.0.524670, was promoted to de facto release status on Thursday, February 28th.
The EEP viewer was promoted to RC status with the release of version 6.0.2.524683 on Wednesday, February 27th.
Projects
Animesh Follow-on
No update; Vir is still working on the clean-up following the inventory issues users experienced over the weekend of February 9th /10th.
Bakes on Mesh
Again, no update, other than a back-end Bake Service update is due (presumably to fix the “black skirt issue”. Once this is deployed, it should allow a resumption in progress with the viewer.
ARCTan
This is the project to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. It has been stalled for some time and may remain so for a while.
The overall aim for this work to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints.
In Brief
BUG-226427 “Root bone is not centred on avatar”: some content rigged to mRoot may appear broken in Animesh-enabled viewers. This appears to be a variation of an issue initially seen in Bento, and had been thought to have been fixed. Vir has pulled this issue into his current viewer workload.
Animesh on the Marketplace: it is becoming difficult to locate genuine Animesh within the Marketplace Animated Objects category (which is being used for assorted items). A request has been informally made for a new, more Animesh-focused category / sub-category to be added, although this is more a request for the Web User Group.
It has also been noted that Animesh is becoming subject to keyword spamming.
Custom Pivot Points (BUG-37617): this had been awaiting further information, Vir to review.
Date of Next Meeting: The next CCUG meeting will most likely be in three weeks, on Thursday, March 21st, 2019.
There was no deployment to the SLS (Main) channel on Tuesday, February 26th, leaving it on server maintenance package 19#19.01.25.523656. As regions on the channel were restarted in week #8, there was no restart this week.
The planned deployment was cancelled due to a list minute issue being found, and also led to the planned RC deployment(s) being postponed.
No deployments are planned for Wednesday, February 27th, 2019, leaving the RCs on the following simulator versions:
BlueSteel and LeTigre: server maintenance package 19#19.02.16.524516 EEP).
Magnum: server maintenance package 19#19.02.16.524515, comprising further internal fixes.
Simon indicated at the SUG meeting that regions on the RC channels might be restarted, although this is unclear, as the channels have not hit the 14-day restart barrier.
SL Viewer
There have been two recent RC viewer updates:
On Tuesday, February 26th, the BugSplat RC viewer updated to version 6.1.0.524670.
On Friday, February 22nd, the Estate Access Management (EAM) RC viewer updated to version 6.1.0.524240.
The rest of the viewer pipeline remains as follows:
Current Release version 6.0.1.522263, dated December 5th, promoted December 13th. Formerly the Spotykach Maintenance RC viewer – No Change.
BugSplat RC viewer, version 6.1.0.524348, February 13th. This viewer is functionally identical to the current release viewer, but uses BugSplat for crash reporting, rather than the Lab’s own Breakpad based crash reporting tools.
Love Me Render RC viewer, version 6.0.2.523177, January 16th.
Project viewers:
Environmental Enhancement Project (EEP) viewer, version 6.0.2.524476, February 19th.
Bakes on Mesh project viewer, version 6.0.2.524367, February 15th.
Linux Spur viewer, version 5.0.9.329906, dated November 17th, 2017 and promoted to release status 29th November – offered pending a Linux version of the Alex Ivy viewer code.
Obsolete platform viewer, version 3.7.28.300847, May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.
Inventory UDP Messaging Deprecation
The planned deployment to Magnum (cancelled for this week) should include the updated simulator code that removes all asset fetching UDP messaging from the simulator code. Once deployed, this will mean anyone using really old viewers that do not have HTTP asset fetching on regions running on the Magnum RC channel will no longer be able to obtain responses to asset requests – and this will increase as the code is deployed to the remaining channels.
It’s not clear yet if the two “legacy” viewers currently offered by the Lab (the Linux Spur viewer and Obsolete Platform viewer) will remain available after the update has been fully deployed, as both will be unable to fetch assets. Those wishing to test older versions of viewers against the updated simulator code can do so on Mesh Sandbox 3 on Aditi.
The Question of Script Load
The core of the SUG meeting revolved around the question of scripts and simulator loads. The discussion started with a request to make scripts run % data accessible to SLS, so scripters might coder periodic, intensive scripts hold off loops of execution if they can see a region is busy.
This spun out to a discussion of making information on scripts (as seen at the region level via Top Scripts) available at parcel level. However, a concern here is the risk of unnecessary drama: if X on parcel Y can see top scripts across the region, and sees A’s scripts on another parcel gobbling script time, it could lead to an assumption (right or wrong) it is the scripts that are responsible for all issues X is experiencing, resulting in potential local drama.
Another idea put forward is to make script use tied to parcel size (as is the case with land capacity / impact) in an effort to make script usage fairer within a region (see BUG-225391). While potentially good in theory, such a “fair use” approach has some potential issues:
Script usage isn’t balanced by parcel within a region. It is possible to have multiple parcels using little or no script time, and one using more than its “fair share”. Currently, this means things can balance out within a region, but with a capped script use, the “high use” parcel could be penalised when there is no need. As Oz Linden noted, “We could do that, but suppose we did. In many places people would see a big script performance drop even though the region had lots of idle time.”
Scripts are the only thing that can impact local performance: Physics Time, for example, can be over-used and impact performance, leaving very little script time per frame.
There is a difference between in-world scripts and attached scripts, so there is a question of how would the latter be accounted for? Making them part of the parcel allowance isn’t necessarily fair, as the parcel owner has no direct control over others without something of a draconian approach (depending on parcel size) – upping the potential for drama / upset.
Simon Linden also pointed out that there is pretty significant overhead moving between the scripts versus running actual bytecode (that is figuring out what to run against actually running it), so monitoring everything could add more of an overhead than actually letting scripts run – although there have been discussions on how to improve this. But, he also cautioned that adding further checks would have to be a “real clear win”.
There are some reports that the percentage scripts run seems to be falling across Mainland, without a noticeable increase in script count, which if true, would indicate something is going wrong. But as pointed out at the meeting, without data, it is hard to tell what is going on. Is a slow-down a case of having too much useful stuff going on for the available resources, or is it a case of someone going compute-bound in their script, lagging a region.
This is likely to be a discussion that will continue.
The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, February 21st, 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.
Animesh Follow-On
Vir has been assisting with the clean-up following the inventory issues users experienced over the weekend of February 9th /10th. These apparently impacted a number of SL’s back-end services and are still being worked on.
A planned change for Animesh designed to throttle the number of complexity updates for avatars and Animesh objects actually never made it into a release viewer. This will now likely get pulled into the (non-public) viewer repository where Vir is experimenting with Animesh follow-on work.
The lack of this throttle has meant that some TPVs have implemented their own throttles on these complexity updates to reduce their potential impact.
Will there be attachment points for Animesh? Currently unknown. Vir will be investigating options; attachments to Animesh won’t function in quite the same way as avatar attachments, so the optimal mechanism needs to be determined, if possible.
One option might be to have attachments behave as part of the Animesh linkset, but have a flag set for them that forces them to be displayed in the required location when used.
This doesn’t allow the full range of capabilities seen with avatar attachments, but it would allow the attachment to be made, and the Animesh complexity calculations to be properly updated.
Environment Enhancement Project
Project Summary
A set of environmental enhancements allowing the environment (sky, sun, moon, clouds, water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day), and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.
Due to performance issues, the initial implementation of EEP will not include certain atmospherics such as crepuscular rays (“God rays”).
It is hoped that the current project viewer version of the EEP viewer (version 6.0.2.524476, dated Tuesday, February 19th) will be the last before EEP moves to viewer release candidate status.
There are still a couple of bugs to be hunted down which may impact the promotion.
Rider hopes to see the viewer go to RC status before the sider code for EEP moves beyond the LeTigre and BlueSteel simulator RC channels, to allow more widespread testing of the viewer once it is in RC without the risk of bugs impacting other simulator updates.
People using the EEP viewer (project or RC, once it has been promoted) should see no difference in behaviour when using it on non-EEP regions.
Bakes On Mesh
Project Summary
Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves viewer and server-side changes, including updating the baking service to support 1024×1024 textures, but does not include normal or specular map support, as these are not part of the existing Bake Service, nor are they recognised as system wearables. Adding materials support may be considered in the future.
A further appearance server update is required to fix the “black skirt” issue that can result in an avatar appearing to wear a long, jet black “skirt” when seen in the BoM viewer.
Multiple Texture Uploads
BUG-226352 requests multiple suitable image resolutions are made available when uploading textures. Image courtesy of Beq Janus
As noted in my previous Content Creation UG meeting notes, there was some discussion on textures and uploads, during which, Beq Janus suggested making it possible for users to select more than one image resolution when uploading textures to the viewer.
The idea here is to encourage people to experiment and see how the different resolutions work on surfaces, rather than always automatically opting for the highest resolution (e.g. 1024×1024), which might not always be required.
A feature request was subsequently submitted for this – see BUG-226352– which has been accepted.
It’s not clear if / when this might be implemented, although it is acknowledged as being “a nice thing to have” (particularly given the different resolution mipmaps are generated at upload anyway, but only the selected resolution is made available).
It is not clear how much would be involved in the necessary back-end updates required to support the idea.
Also, the usual caveat: “accepted” means the idea is something the Lab is interested in tracking / possibly investigating. It doesn’t automatically mean a feature request will be implemented.
On Tuesday, February 19th, there was no deployment to the SLS (Main) channel, leaving it on server maintenance package 19#19.01.25.523656; however, region on the channel were restarted. The planned update for the channel was again postponed due to a late-breaking bug.
On Wednesday, February 20th, 2019 the RCs are likely to be updated as follows:
BlueSteel and LeTigre should receive EEP update server maintenance package 19#19.02.16.524516, comprising the following fixes:
BUG-226252 [EEP] Please create an internal error code for llReplaceAgentEnvironment() & llSetAgentEnvironment() that distinguishes whether an agent does not have the experience allowed and if the experience is not allowed at their location.
BUG-226246 [EEP] llGetEnvironment() reports SKY_LIGHT fade_color as a rotation instead of a vector. (SKY_LIGHT only returns vector light_direction and vector total_ambient. fade_color is removed https://wiki.secondlife.com/wiki/LlGetEnvironment)
Magnum should receive server maintenance package 19#19.02.16.524515, comprising further internal fixes.
SL Viewer
The EEP Project viewer updated to version 6.0.2.524476 on Tuesday, February 19th. The remaining viewer pipelines remain as follows:
Current Release version 6.0.1.522263, dated December 5th, promoted December 13th, 2018. Formerly the Spotykach Maintenance RC viewer – No Change.
BugSplat RC viewer, version 6.1.0.524348, dated February 13th. This viewer is functionally identical to the current release viewer, but uses BugSplat for crash reporting, rather than the Lab’s own Breakpad based crash reporting tools.
Estate Access Management (EAM) RC viewer, version 6.1.0.523351, dated January 23rd.
Love Me Render RC viewer, version 6.0.2.523177, dated January 16th.
Project viewers:
Bakes on Mesh project viewer, version 6.0.2.524367, dated February 15th.
Linux Spur viewer, version 5.0.9.329906, dated November 17th, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
Obsolete platform viewer, version 3.7.28.300847, dated May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.
EEP Deployment Oddities
There are some oddities being witnessed while EEP is being deployed. These should all go away once the code is fully deployed on the servers and the viewer code has reached all release versions of viewers.
Day / Night Cycle Differences
With the EEP updates currently on around 20% of the main grid, it is possible for very different values to be returned to the viewer when travelling between adjacent EEP and non-EEP regions, and this has been causing some confusion. Rider explains it thus:
EEP changes how the time is calculated. llGetSunPosition is dependent on the environment. It was not before. Legacy regions determine the beginning of the day differently than EEP regions. So until [they] have been [updated] there will be some disruption.
The way the start of the day has changed. It is now GMT-8, this [also] may not align with neighbouring legacy regions.
Other Oddities
There are also reports of jarring region crossing transitions that can sometimes occur when moving between regions with different EEP settings – see BUG-225689.
Stars on EEP regions will appear black against the daytime sky when seen on a non-EEP viewer with Advanced Lighting Model (ALM) enabled, or as white stars with ALM disabled.
Marketplace Gifting
There is an issue with the redelivery of gifts made via the Marketplace that (depending on the age of the original gift delivery) might result in the redelivery going to the sender, rather than the intended recipient – see BUG-226124. If you encounter this, please raise a support ticket.
The following notes are taken from the TPV Developer meeting held on Friday, February 15th, 2019. A video of the meeting is embedded below, my thanks as always to North for recording and providing it. Time stamps are provided to the major topics of discussion, which will open the video in a new tab for ease of reference.
The Bakes On Mesh project viewer updated to version 6.0.2.524367 on Friday, February 15th. The rest of the current viewer pipelines remain as per earlier in the week:
Current Release version 6.0.1.522263, dated December 5, promoted December 13. Formerly the Spotykach Maintenance RC viewer – No Change.
BugSplat RC viewer, version 6.1.0.524348, February 13. This viewer is functionally identical to the current release viewer, but uses BugSplat for crash reporting, rather than the Lab’s own Breakpad based crash reporting tools.
Estate Access Management (EAM) RC viewer, version 6.1.0.523351, January 23.
Love Me Render RC viewer, version 6.0.2.523177, January 16.
Project viewers:
Environmental Enhancement Project (EEP) viewer, version 6.0.2.524123, February 6.
Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7. This viewer will remain available for as long as reasonable, but will not be updated with new features or bug fixes.
It is hoped that one of the current RC viewers will gain promotion to de facto release status, although there is one further issue in the Love Me Render viewer to be seen to. Also, the EEP viewer could see promotion to RC status in the very near future.
Viewer-Related Web Changes
Release Notes
[16:35-18:20] The Lab will be introducing a new system for release notes. In short:
It will use a new website for publishing release notes, and not the currently SL wiki pages.
Those release notes currently on the wiki will remain there for archival purposes.
Once visible, any issues should be reported via Jira.
User Profiles – Viewer and Web
[18:23-24:35] The current user profiles seen in the viewer, on the web, via various feeds, etc., are all powered by a single application. There is an upcoming system upgrade in the pipeline that might result in some breakage within this app. The Lab will therefore be moving viewer profiles back to using floater-style user profiles, as is seen with the like of Firestorm.
Upcoming changes will impact the current means of providing profile information. In particular, this means the official viewer will, in the future cease using the web format for displaying profile information (l) and will revert to a more “legacy” style, as seen in various TPVs (like Firestorm, shown r).
It is not currently clear what will happen to the current web profiles and feeds. It is hoped these will be able to continue to work, but the Lab is also contemplating a “worst-case” scenario that they may be retained for historical purposes (so snapshots uploaded to feeds are preserved and remain viewable, for example), but will no longer work as they do now – but this is not what the Lab is hoping to achieve.
This will not be an immediate change, as there may be issues along the way the Lab need to work through.
Weekend Issues
[5:27-6:31] The weekend of February 9th /10th saw some significant issues with Second Life, and extended periods of unscheduled maintenance. The problems that contributed to the issues are still being investigated, ut the Lab is close to understanding exactly what went wrong, and how to respond should a similar issue occur.
As an aside, the weekend issues result in inventory problem that caused some uses to see the “cannot remove protected categories” error. If you are still seeing this message, and have not already done so, file a support ticket.
In Brief
[1:20-1:46] Visual Studio 2017 Build Process Update: work on this is progressing well, but will like pause in the coming week, due to the project lead being on vacation.
[2:09-2:40] EPP: As per my SUG meeting and CCUG meeting notes, the simulator EEP code is now on BlueSteel and LeTigre. This will not get a further promotion in week #8, as there is a fix for another issue the Lab wants to see get wider exposure on the grid.
[6:50-10:18] Avatar attachment issues: there have been reports of attachments belonging to other avatars randomly appearing to be attached to your screen when logging-in to / teleporting to busy regions. The underlying problem appears to be a race condition in which the object data for the attachment is received by the viewer ahead of the avatar / attachment point data (and should correct when the latter is received).
In the meeting, the issue is specifically reported as occurring with “jellydolled” avatars, but this appears to be purely coincidental.
[10:39-11:28] New EEP Assets causing log-in freezes: a default set of new EEP object types were added to the asset library recently for use with the EEP viewer. However, if pulled into a non-EEP viewer, they can cause log-in freezes, as the viewer repeatedly generates an error message for each individual asset it encounters in loading inventory, rather than simply throwing a single message of the asset type, and simply ignoring the rest of the individual assets. There is a fix for this, but it has yet to reach the current release viewer code base.
[11:37-14:10] Landmark assets getting fetched twice at log-in: this appears to be a new(ish) issue. Although landmark assets only appear once in inventory, the viewer appears to be fetching them twice; once around mid-way through the log-in process, and then again at the end. The cause is unknown at present, but it has been noted by the Lab.
An intermediate workaround if your logins are being delayed unduly is to delete you landmarks.
This can might cause the degraded performance message (see below).
[13:07-15:33] Degraded performance message: “Linden Lab has detected degraded performance on your connection”, with a suggestion you relog, is a message users might receive when the viewer is failing to acknowledge enough of the UDP messages exchanged with the simulator.
This can be the result of your router being overloaded by whatever else it might be doing, so responses from the viewer fail to reach the simulator.
It might also be the result of issues being experienced in the simulator.
While a lot of asset-related UDP messaging has been removed from simulator / viewer communications, there is still much that does require / well suited to UDP, particularly where information is changing, and the viewer needs the latest update, not a re-send of a now outdated updated (e.g. object updates), as would be the case using something like TCP, which attempts to re-send the data it has, rather than any new data.
BUG-226352 requests allowing users to define more than a single resolution when uploading a texture
[30:21-31:37] In-Viewer Animation Creation: This is a project based on contributions from NiranV Dean (Black Dragon viewer). Vir and Nat Linden had been working on elements of the project, but are both also busy with other viewer-related projects (e.g. Animesh follow-on investigations for Vir, working on the VS 2017 update for Nat). Resources are also being swallowed by the under-the-hood work required for the transition to the cloud, which is also impacting assorted projects.
[32:18-32:35] Texture resampling & mipmap availability: this has been the subject of extensive blog and forum discussions – see my week #7 CCUG summary) One outcome of this is Beq Janus has filed a feature request so users can define more than a single resolution when uploading a texture (see the dummy uploader floater design, right). The hope is this might encourage more people to make better choices about texture resolution use (very high resolutions aren’t always required, depending on how / where they are used, but can result in unnecessary texture memory use if unwisely employed).
[32:39-32:50] Asset UDP messaging deprecation: Aura Linden is now engaged in this work. This will include removal of the GrantUserRights message (found in LL PropertiesProcessor::sendfriendrights() ), which has been completely disconnected in the viewer since 2.0 days.TPVs are asked to check their code to confirm removal of the message path will not cause them problems.
[34:37-35:19] Does SL use multi-threading: yes, in parts of the viewer and the simulator code, but not as extensively as the Lab would like.
Updated, February 16th: the suggestion to make suitable mipmaps available to users when uploading textures (see the end of this summary) has been translated into a feature request by Beq Janus, allowing users to select multiple image resolutions when uploading a texture – see BUG-226352.
The majority of following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, February 14th, 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.
SL Viewer Updates
The Bugsplat RC viewer updated to Wednesday, February 13th, to version 6.1.0.524348.
Bakes On Mesh
Project Summary
Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves viewer and server-side changes, including updating the baking service to support 1024×1024 textures, but does not include normal or specular map support, as these are not part of the existing Bake Service, nor are they recognised as system wearables. Adding materials support may be considered in the future.
Anchor Linden has pinned down a couple of further bugs.
The hope is that BoM will progress to viewer release candidate (RC) status in the near future, although this is down to internal testing at the Lab.
Environment Enhancement Project
Project Summary
A set of environmental enhancements allowing the environment (sky, sun, moon, clouds, water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day), and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.
Due to performance issues, the initial implementation of EEP will not include certain atmospherics such as crepuscular rays (“God rays”).
On the simulator side, EEP is now on the BlueSteel and LeTigre channels (representing roughly 20% of the main grid).
There is “one last” major issue with the current viewer code to be resolved. This is related to experiences, and Rider Linden believes he has a fix for the problem.
It is therefore hoped the EEP viewer will move to RC status very soon.
The next update to the viewer should include fixes for BUG-226249.
There have been some changes to the data returns by llGetenvironment, and further changes will be made in the coming week. These changes will be reflected in the wiki documentation.
There is also a bug that can cause avatar tags to be corrupted in certain EEP environments, as demonstrated by Whirly Fizzle (below).
Whirly Fizzle demonstrates the corrupt avatar tags that can occur under certain EEP environments. Credit: Whirly Fizzle
This pass of EEP will not, as previously reported, include Godrays at this point in time. It is hoped these will be added in the future – although when in the future is not clear.
Animesh Follow-On
Vir has some prototype hooks in the code that allow body parts in the inventory of an Animesh to be used to customise the skeleton of the Animesh. This doesn’t (as yet) include any communications from the viewer to the simulator, which s the next thing Vir will be examining.
This next part of the work may possibly hampered by the fact there is an “embarrassingly large” number of ways to transmitting object information between the viewer and the simulator. None of them are particularly comprehensive, making it harder to determine how best to add messaging specific to Animesh.
As a result Vir is also looking at a means of rationalising things to make it easier to add object information communications to the system beyond Animesh.
There have been requests to provide a means to obtain things like the tri count for Animesh. Vir believes it might be easier to add the means to obtain streaming cost, etc., (as this information is already supplied for in-world objects), and / or to give a more straightforward means of indicating whether something can be linked into an Aminesh object or not.
Tri counts are being required so creators can check whether or not linking objects together for an Animesh will take them over the tri count limit for Animesh.
A problem here is that the simulator doesn’t have the full tri count information for any mesh object, only an estimate to assist in making LI calculations; so using LSL to extract the information could require more in the way of back-end work to expose the required information obtained from the viewer.
There is also a risk that as time goes on, the rules regarding what is allowed for Animesh might change – including the tri count. Any such change could therefore invalidate the accuracy of scripts with a hard-coded tri count limit.
A request as also been made to enable / disable Animesh via LSL. This is currently not on the cards, unless a compelling use-case can be defined.
A suggestion has been that using LSL to disable Animesh could help reduce LI when Animesh objects don’t need to be animated. However, due to the fact Animesh is rendered differently to static objects, this would likely not work in the way people imagine.
Vir still hopes to re-work Reset Skeleton a system command so that anyone triggering a reset of their avatar skeleton when they see it deformed can send that update to all other viewers in the scene perform a reset for that skeleton, rather than users having to manually select and reset the affected avatar.
If this is done, it is unlikely to include any LSL support, due to the risk of it being over-used in scripts, with the potential for performance hits.
Another request is to have a viewer-side option to reset Animesh skeletons. This is viewed as a good idea, as there is already a debug setting (DebugAnimatedObject – set to True) for this, which could be better exposed, although it doesn’t work with Animesh objects attached to avatars.
As Beq correctly points out, there is no “magic” debug setting to improve the resolution or quality of all textures, and Second Life cannot displayed textures with a resolution greater than 1024×1024.
What Beq did confirm is (as per their descriptions) the referenced debugs can be used to upload textures much larger than 1024×1024 Second Life. However, such textures will be resampled to 1024×1024. The particularly interesting thing here is that in resizing such images, the viewer uses bilinear resampling which – contrary to perceived wisdom pointing to bicubic resampling – can actually result in far better quality in the finished 1024×1024 texture.
Beq’s forum post and (particularly) her blog post explains what appears to be happening – and how direct resizing very high-resolution images using bilinear resampling to 1024×1204 prior to upload will also result in better quality textures with viewed in-world.
Does this mean that the upload texture size limit should be increased? Well, no. The crucial part of this is that the different is only seen with 1024×1024 textures – which have issues in terms of the amount of memory they eat, and in the fact they are already drastically over-used. As such, increasing the allowed upload resolution prior to resampling might further elevate the use of 1024×1024 textures.
In the meantime, the forum post has triggered some interesting discussion around bilinear and bicubic resampling, and where each might be preferable to use, and how bilinear could benefit the production of seamless normal maps.
A further suggestion resulting from these discussions (or the resurgence of a suggestion) is to make all the mipmaps for an uploaded textures available, rather than the just the level selected at upload (so, for a 1024×1024, the 512×512, 256×26 and 128×128 mipmaps are also made available to the user, allowing them to experiment and see how the different resolutions work on surfaces. A feature request Jira has been requested for this idea.
Two Loons, Calas Galadhon – blog post
Inara Pey: Living in a Modemworld 