SL project updates 51/2: CCUG and viewer

Queen of Dragons? Surrounded by Animesh dragons by Wanders Nowhere and used by Lucia Nightfire as Animesh test models

The following notes are primarily taken from the Content Creation User Group meeting, held on  Thursday, December 21st, 2017 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Medhue Simoni live streamed the meeting, and his video is embedded at the end of this article – thanks to Medhue, as always, for the recording. However, the first part of the meeting is absent the video, so I’ve included two audio extracts of salient points raised, taken from my own audio recording of the meeting. Where the video is referenced, time stamps to the specific point of the video are provided in the text – click on them to open the video in a separate browser tab at that point.

Animesh (Animated Mesh)

“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “Animesh”.

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.

In short, an Animesh object:

  • Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
  • Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
  • Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
  • Can use many existing animations.

However Animated objects will not (initially):

  • Have an avatar shape associated with them
  • Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
  • Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
  • Use the avatar baking service
  • Will not support its own attachments in the initial release.

These are considered options for follow-on work, possibly starting with the notion of a body shape (to help with more fully-formed NPCs).

Resources

Bug Stomping

  • Animation Playback issues: as highlighted at the December 14th meeting, animations already running on an Animesh object don’t necessarily play for those entering the region where they are running, or update correctly when camming to them for the first time. This had been considered a viewer issue, but could equally be a simulator / viewer race condition wherein the viewer is receiving animation information before it knows what to do with it (and so is ignoring it). Vir is still looking into this.
  • Object Selection issues: this isn’t just an Animesh issue per se. Historically, selecting multiple animated objects (or an avatar) so they are displayed as wire frames has been handled “extremely inefficiently”, impacting local frame rates. A fix is in hand for this, and will be in the next update of the Animesh project viewer.

Animesh Release ETA and Limits

There is still no indication of a release date for Animesh. Work still to be completed / carried out includes:

  • Bug fixing, including the two issues noted above.
  • Performance profiling (tri, count, LI, etc., limits evaluation, etc.).
    • It is worth repeating (again) that the current limits of tri count, LI, and number of attachments are purely for the purposes of performance testing, they are not the “final” limits for Animesh, some of which will hopefully be somewhat more relaxed / reflective of server / viewer capabilities when scaling Animesh use within a region.

The initial tri count limit (again, set for testing purposes only) was increased from 20K to 50K with the current project viewer release (version 5.0.10.330058, at the time of writing). As noted in my week #50 update, this increase had been requested for some time – although it appeared to be wanted more for testing proposed Animesh products, rather than testing the basic Animesh capabilities. Zooby’s has since issued a video of one such new product, involving both a wearable cat avatar, and which is also intended to support the avatar being used as an in-world Animesh object, once Animesh is released.

Animesh Use Cases

The focus for Animesh among creators thus far has been for avatars (NPCs), and creatures, pets and things like mechanoids (both free-roaming and wearable). However, there is potential for Animesh to be used for landscaping as well: tree boughs / grass moving in the wind, water features, etc., and the Lab is interested in discovering how much appetite there is among creators to use Animesh in this way, particularly when it comes to profiling performance and limits.

Skeleton Use and Bone Naming Convention / Parenting

An extensive discussion on using the skeleton bones.

[0:00-10:36] When talking in terms of unique Animesh objects, the skeleton can be re-purposed to suit the need, and not all the bones need to be animated. So, for example, in a grouping of plants, the leg, arm, wing, and tail bones could be used to animate individual plants (in principle, individual finger bones could be used).

As with any use of the skeleton, the important aspects are preserving the recognised bone naming and parenting hierarchy (although it is possible to constrain bones  / bone groups for specific uses within Blender, then map this back to the SL skeleton, but it requires care and attention with a thorough understanding of the SL avatar).

This is where Animesh is attachments such as hair is of an advantage over hair that simply uses with avatar’s own skeleton. With the latter, the available bones are limited without potentially impacting the ability to wear animated hair with a Bento head (although there are “spare” ear and eye bones which could potentially be used to create an animated ponytail or pigtails).

Using a separate range of bones in Animesh hair offers greater flexibility – but then the issue becomes keeping the animations in the Animesh hair in sync with the movements of the avatar wearing it.

“Dropping” Animesh / Mesh

[11:50-15:31] Worn mesh cannot be simply “dropped” in-world. It has to be detached to inventory and then rezzed in-world from there. This has been seen as limited with Animesh pets, etc., where ideally people might want to pick a pet up and carry it and then put it down again (drop it). Making it possible to drop mesh is seen by the Lab as “kind of a hassle to do”, but it’s not currently clear how big or small a hassle it might be, as it would involve additional land impact calculations, physics updates, etc., none of which were given support when mesh was introduced. Thus, it could require  an extensive simulator-side overhaul.

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 server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads. The project is in two phases:

  • The current work to update the baking service to support 1024×1024 textures.
  • An intended follow-on project to actually support baking textures onto mesh surfaces. This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Current Progress

Viewer work has paused while some back-end baking service issues are resolved.

Other Items

How the Lab looks at Features

One oft-phrased point-of-view is that the Lab “only” think about features being used in a certain way – and this has at times been voiced for Animesh. Speaking at the meeting, Oz Linden sought to dispel this idea, pointing to the diverse ways capabilities are frequently used in SL.

 

Mesh Uploader

[18:15-22:44] Cost calculation issues: discussion on mesh upload costs noted in the viewer. These have long been an issues, where costs can alter due to the same model being automatically decimated differently with each upload, etc. These are most likely the result of errors in the calculations framework, and they are something the Lab is aware of, and might be the result of the removal of the SLM file from the uploader, which caused problems of its own. Those who wish to test whether the cost calculation issue is reduced by using the SLM file can do so by setting the MeshImportUseSLM debug to True.

[23:32-24:22] Mesh object names: Vir reminded people due to a limitation with Collada .DAE files mesh objects for upload via the official viewer cannot currently have spaces in their names. However, the Lab will be adopting the Firestorm work-around for this by allowing the use of underscores in object file names.

Bone Offsets

[26:44-29:18] Bone offsets: Vir points to an issue he encountered with an avatar model using a 75m offset for the mPelvis bone which, every time the offset was calculated, would cause the object to vanish from his screen until Reset Skeleton was used. This prompted the question whether should bone offsets have a constraint of bone offsets – such as no more than 5 metres, as is the case when offsetting using animations.

SL Viewer

  • The Wolfpack RC viewer (containing no functional changes to the current release viewer) updated to version 5.0.10.330113 on Wednesday Novermber 20th, 2017.
  • Nalewka Maintenance RC updated to version 5.0.10.330123 on Thursday, December 21st, 2017.

These likely mark the last viewer updates for 2017, leaving the rest of the viewer pipeline as follows:

 

Advertisements

SL project updates week #51: server, viewer

Cherishville; Inara Pey, November 2017, on FlickrCherishvilleblog post

Server Deployments

There are no planned deployments for week #51. This will leave the grid running on server release 17#17.12.01.511131 (link to SLS summary page).  However, given the RC channels have not been restarted in the last two weeks, there may be a rolling restart for all three RC channels on Wednesday, December 20th.

SL Viewer

The Nalewka Maintenance RC viewer updated to version 5.0.10.330111 on Tuesday, December 19th. This adds a further 11 fixes and updates to the viewer since the initial release of the viewer RC.

The Project Render Viewer updated to version 5.1.0.511446 on Monday, December 18.

The Alex Ivy 64-bit RC may also get an update during the week. However, at the moment the remainder of the SL viewer pipeline remains as per the end of week #50:

  • Current Release version 5.0.9.329906, dated November 17, promoted November 29th – formerly the “Martini” Maintenance RC – No Change
  • Release channel cohorts:
  • Project viewers:
  • Obsolete platform viewer version 3.7.28.300847, dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

User Group Meeting Dates

With the holiday season on us, users group meeting dates are as follows:

  • Simulator User Group: next meeting: Tuesday, January 2nd, 2018, 12:00 noon.
  • Open-source development group: Wednesday, December 20th; Wednesday, January 3rd, 2018.
  • Server Beta User Group: Aditi, Thursday, December 21st, December 21st; Thursday, January 4th, 2018 – both at 15:00.
  • Content Creation User Group: Aditi, Thursday, December 21st; Thursday, January 4th, 2018 – both at 13:00 SLT
  • Third-Party Developer Meeting: Friday, January 12th, 2018, 12:00 noon SLT.
  • Web User Group: Friday, January 5th, 2018, 14:30 SLT.

SL project updates 50/3: TPV Developer meeting

The Outer Garden; Inara Pey, November 2017, on FlickrThe Outer Gardenblog post

The following notes are taken from the TPV Developer meeting held on Friday, December 15th 2017. The video of that meeting is embedded at the end of this update, my thanks as always to North for recording and providing it.

SL Viewers

[2:35] The Alex Ivy 64-bit RC viewer has one more bug the Lab would like to resolve, this one with the updater within the viewer. The hope is a fix for the issue will be in a further update to the viewer at the start of week #51, commencing Monday, December 18th. If so, the viewer might be promoted to de facto release status before the holiday break.

[6:46] Once the Alex Ivy viewer is promoted to release status, the Lab will move to block versions of their viewer older than the 5.0.6 viewer (the HTTP updates from June 2017).

[4:00] The Voice RC viewer updated to version 5.0.10.330039 on December 12th. This is doing “very well” and is currently being held from promotion due to the wish to promote the Alex Ivy viewer. As a result, the Lab might do a further RC update for it, with a new update from Vivox.

[5:19] A new Maintenance viewer, version 5.0.10.330035, appeared on December 13th. It features a range of fixes, and is code-named Nalewka, in keeping with the Lab’s new habit of naming Maintenance viewers after alcoholic beverages. Nalewka is, according to Wikipedia, a rather interesting beverage mixing alcohol (vodka or neutral spirits) and fruits, herbs, spices, sugar / molasses and which has a liquer-like taste.

[5:43] The anticipated 360-snapshot viewer update has been held while it is integrated with Second Life Place Pages. This will allow 360 images to be uploaded to Place Pages and used in hero images, etc. It is anticipated that these updates will now appear early in the New Year and the viewer should move quickly to RC status thereafter.

[4:43] TPVs attempting to use the viewer updater have encountered issues, often resulting in them disabling it. Oz Linden acknowledges it isn’t easy for TPVs to update it, but has offered to work with them to fix issues once the Alex Ivy viewer (which uses a new version of the updater) reaches release status, coupled with a code refactoring to make updating it easier in the future.

Linux and the Viewer

[20:51-24:28] As per my previous TPV meeting notes, once the Alex Ivy 64-bit viewer (Windows and Mac) goes to release status, the Lab will look to TPV / open-source developers to help move the Linux viewer build to a Debian package without the additional libraries. this will allow TPVs to add the dependencies they require for their flavour of Linux build. If help is given and the project is successful, the Lab will then maintain the Linux build, with the caveat that it will only be subject to cursory QA, and will continue to look to the Linux community for fixes.

A repository for code submissions will be made available, together with a blog post / open-source community notification on the specifics, after the 64-bit viewer has been promoted to release status. Those wishing to support the work will need to sign a contribution agreement with the Lab.

Texture Decoding and Texture Memory Limits

[28:23-29:52] The Lab is making improvements to texture handling (e.g. using raw texture data rather than encoded). Some of this work is in the current rendering project viewer; there is another non-public viewer which uses a new structure for the rendering cache – although this hasn’t been overly successful in testing thus far. Oz is anticipating his team spending more time on rendering in early 2018.

Environment Enhancement Project (EEP)

A set of environmental enhancements, including the ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level; a new environment asset type that can be stored in inventory and traded through the Marketplace / exchanged with others; scripted, experience-based environment functions, an extended day cycle and extended environmental parameters. This work involves both a viewer updates (with a project viewer coming soon) and server-side updates.

[10:01-11:34] “Rider’s been on a power trip since starting this project!” Grumpity joked at the meeting, “Moving these celestial bodies around the sky!” – which Rider admitted was fun.

Progress continues, and it is anticipated that test regions on Aditi and a project viewer will be available “soon after” the new year, although these may not initially support using environment settings and inventory assets.

 

Server-side Reset Skeleton

[30:10-35:25] Bento introduced a reset skeleton option for details with avatar deformations. However, it is viewer-side only – therefore, if someone swaps between skeletons / avatars + attachments and is displayed deformed (e.g. BUG11310) or with attachments wrongly place (or a combination), they, and everyone viewing them has to individually perform a reset skeleton on their avatar to correct how they appear.

A preferred means of handling this might be for a local reset to be sent update the appearance system to ensure everyone gets updated (so if I’m deformed, I can use reset skeleton, and everyone around me gets the update as well, rather than having to also use the reset skeleton option). Oz has requested clear, concise feature request on the idea. Grumpity has indicated she’ll follow-up on the specifics of BUG-11310, which the Lab thought to be resolved through and internal JIRA.

Simulator Resources and Simulator Crashes / Performance Degradation

[43:53-50:20] Discussion on simulator resource use / loading balancing. This proceeds from the false assumption that a region / simulator can be crashed “just” by overloading it via a resource / physics hungry script. While there may still be exploits where this might be the case, the Lab long ago imposed absolute limits on script and physics time per frame. What more usually happens is that excessive script / physics loading on a region as whole as a whole can degrade performance as some script / physics executions are skipped within a frame (so scripted objects are slow in responding / may not respond as anticipated, for example); although it is acknowledged that specific items – intentionally or through bad scripting – can have an undue impact on performance.  Anyone encountering specific objects, which can individually adversely impact region / simulator resources / performance is asked to file a JIRA with details of the object in question, so that the Lab can obtain a copy and poke at it.

Other Items

  • [13:24] Estate access / ban lists: (Estate/Region floater) – work has stalled on this.
    • [14:21] A question was raised on the ability to teleport others home from, or out of, your own parcel, a capability that had been available in the older v1 (and v2?) viewers. Having an ability to remove people at parcel level is something the Lab will likely look at as they continue to work on the land tools.
    • [16:59] the updates to the estate tools will include a log of ban actions taken – who banned whom and when – which will be visible to all Estate Managers (not general group / land users).
  • [35:35-36:20] Semi-automatic viewer tests: Kitty Barnett (Catznip) have a number of semi-automated viewer tests (e.g. checking to see if all UI elements / floaters work in different languages). The Lab have found that as the viewer is updated / changed so often, such tests rarely maintain their value over a period of time. However, Oz is willing to learn more about at Kitty’s framework if it avoids such issues.
  • [36:39-37:53] Viewer support for local meshes: this has been a frequent request, particularly with content creators. It is also something the Lab and Firestorm have looked into. However, supporting multiple mesh formats, dealing with LOD compositing, etc., makes it complex and difficult to implement within the viewer. However, if the Lab can find a way for the viewer to do this, they would consider implementing it.
  • [50:43-55:07] Phishing/ URL link spoofing: a discussion on the use of URL link spoofing – which has affected Second Life and is a general issue on the web as a whole. Short version: always check URLs before clicking whatever you’re doing, and in terms of SL: always treat links receiving (e.g. via dialogue boxes, via unexpected / unknown IM, etc.) with caution, and while it does not eliminate risks, configure your viewer to use an external web browser to open external links. Obviously, and like any other company, the Lab cannot – and will not – every guarantee the safety of accessing URLs which are outside of its control.
While not foolproof, setting your viewer to use an external web browser or to only use the built-in browser for trusted links from LL, might provide some added protection against scam URLs you might obtain through in-world sources
  • Lab No Change window: runs from Thursday, December 21st 2017 through until Tuesday, January 2nd, 2018.
  • Next TPV Developer meeting: Friday, January 12th, 2018.
  • Firestorm release: the next Firestorm release now looks set to go to beta in the week commencing Monday, December 18th, with a release to be made early in the New Year.

 

 

SL project updates 50/2: Content Creation User Group

Queen of Dragons? Surrounded by Animesh dragons by Wanders Nowhere and used by Lucia Nightfire as Animesh test models

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, December 14th, 2017 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Medhue Simoni live streamed the meeting, and his video is embedded at the end of this article – thanks to Medhue, as always, for the recording. Time stamps in the body text will open the video in a separate tab for ease of reference to the relevant parts of the text. However as these notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so some time stamps may appear to be out of sequence.

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 server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads. The project is in two phases:

  • The current work to update the baking service to support 1024×1024 textures.
  • An intended follow-on project to actually support baking textures onto mesh surfaces. This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Current Progress

[1:54-3:40] Testing of the updated baking servers to handle 1024×1024 is now complete. Originally, it had been thought that the Bakes on Mesh would require changes to objects themselves when using 1024×1024 textures, which would have required simulator updates as well.

The approach now being taken is the let the viewer recognise when 1024×1024 textures are being handled via the texture UUID, which should hopefully eliminate any simulator side updates as well in order to get the service running. However, this does raise the question of how to make the system avatar transparent / invisible without continuing to rely on an alpha mask – right now the Lab is looking at a number of possible approaches.

Animesh (Animated Mesh)

“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “Animesh”.

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.

In short, an Animesh object:

  • Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
  • Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
  • Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
  • Can use many existing animations.

However Animated objects will not (initially):

  • Have an avatar shape associated with them
  • Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
  • Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
  • Use the avatar baking service
  • Will not support its own attachments in the initial release.

These are considered options for follow-on work, possibly starting with the notion of a body shape (to help with more fully-formed NPCs).

Resources

Appearance Service Update

[4:28-6:18] The appearance services has to perform a number of calculations based on the mesh attachments an avatar is wearing. For example, these calculations are run to try to ensure an avatar appears to stay reasonably on the ground  when wearing a rigged mesh which might otherwise alter the avatar’s centre position above the ground.

These calculations don’t work particularly well for Animesh attachments, as they have their own skeleton, so the appearance service has been updated so it can differentiate between Animesh and non-Animesh attachments for the purposes of calculating and avatar’s height. The update is being tested on Aditi, and also includes a fix for rigged mesh attachments being incorrectly handled.

Viewer Status

[6:21-8:01] The Animesh project viewer updated to version 5.0.10.330058 on Monday December 11th. This updates includes the following changes:

  • Animesh objects should now display correctly as impostors, using the same rules that avatars do currently.
  • Animesh objects now display animation information for objects you have permission to view.
  • Fix for a crash triggered by unchecking the animated mesh check box for an Animesh attachment.
  • Fix for Animesh attachment getting removed after teleport.
  • Fix for some of the cases where animesh graphics state could get corrupted.
  • Various clean-ups and optimisations.

[6:32-7:30] There is also a forthcoming fix to the mesh uploader – not in the viewer version above – and mesh attachments with spaces in their names (actually a Collada file issue). In short, the Lab is implementing a similar kind of fix to that used by Firestorm to allows objects with underscores in their names, rather than spaces.

Testing Limits: Tri Count Increased to 50K

[8:07-9:03] There has been a lot of feedback that the 20K tri count limit imposed for testing Animesh is insufficient for some creators. In fairness, some of the complaints appear to be more to do with testing completed Animesh products rather than testing the Animesh capabilities to ensure they work as expected; however, the Lab has relented and increased the testing limit on tri counts to 50K. Again, this isn’t the final limit – it is purely for testing. Final limits – hard or soft, tri, number of attachment, LI, etc., – won’t be addressed until actual load testing and scaling takes place as one of the final steps in the project.

Avatar Animesh Attachments

[12:27-19:40] (with lengthy silences)] Other limits, such as the number of Animesh attachments an avatar can wear (set to one for testing) remain unchanged at this point.

Attahments are seen as an interesting use-case with suggestions that as well as pets, it could be used for further animating hair (as rigged mesh hair can already be somewhat animated with head movements, etc). The latter is something that it was suggested Bento might further achieve (bones allowing). Using Animesh would provide more bones for animating hair, but ensuring animations remain in sync with body movements might be difficult.  It could allow hair to be a “pet” (a Medusa-like heads for of snakes).

Attachments for Animesh Objects

[24:45-32:18] Animesh will not support attachment swapping in the initial release – attachments will need to be defined as part of the overall Animesh. Adding / removing attachments is seen as part of the follow-on project.

This section includes discussion of a specific prim-based issue with Animesh encountered by one creator, and a discussion on non-rigged elements of Animesh objects not correctly moving with the rest of an Animesh object (e.g. unrigged eyes failing to properly move with the rest of an Animesh creature’s head).

Bugs Focus

[19:56-23:00] Vir’s current focus for the project is bug fixing. These include:

  • Some Animesh objects seeming to disappear when in their static (non-animated) state.
  • Left-click interactions with Animesh: it’s possible to right-click and Touch an Animesh object via the menu, but left-click interaction currently isn’t possible. Left-clicking on multiple Animesh objects to select them also isn’t possible at present.
  • Animesh LOD selection: currently the selection of the LOD for displaying an Animesh is the same as used for avatars; Vir’s feeling is that Animesh should use the same selection process as for in-world mesh objects.
  • Animesh objects do not always update correctly when camming onto them.

There are also a couple of feature requests that are still being considered around LSL capabilities.

In Brief

  • [34:23-35:22] Avatar skeleton as its own asset type? This has previously been discussed in the Bento project, and while an interesting idea, is seen as being a large amount of work and crosses into the realm of arbitrary skeletons, which could complicate the user experience (e.g. items working with one type of skeleton, but not another).  As such, it remains something the Lab isn’t currently considering, although it may be something they will look at in the future.
  • [39:49-52:06] Discussion on rez-on-entry resource caps, issues of Animesh animations starting / stopping correctly, and how updates are handled – how people see an Animesh that is already in a region being animated can depend on the frequency of the animation updates. The potential need for a shape to effectively place bones / attachments.
  • [54:35-end] Discussion on feature request BUG-139203 tri counts / land impact / LODs and issues / exploits.

 

SL project updates week #50: server, viewer

Groenland Kangamiut; Inara Pey, November 2017, on Flickr Groenland Kangamiutblog post

Server Deployments

As always, please refer to the server deployment thread for the latest news and updates.

  • On Tuesday, December 12th, the Main (SLS) channel was updated with the server maintenance package previously deployed to all three RC channels. 17#17.12.01.511131 comprises “internal improvements”, which should not result in visible changes for users.
  • No deployment is anticipated for the the RC channels on Wednesday, December 13th, leaving them on server package 17#17.12.01.51131. A potential deployment to the BlueSteel RC was cancelled, “I found a nasty little bug nest late last night,” Mazidox Linden reported at the Simulator User Group meeting, “Had to halt the move to RC.”

SL Viewer

Two viewers were updated by Linden Lab on Monday, December 11th, 2017:

  • The Alex Ivy 64-bit RC viewer updated to version 5.1.0.511248.
  • The Animesh project viewer updated to version 5.0.10.330058.

The Alex Ivy RC viewer release notes contain the following information, worth reproducing here:

Windows: there are now separate 32-bit and 64-bit builds for Windows.

  • If you use an HD 2000 or 3000 series video card on Windows 10, choose 32 bit
  • Otherwise, choose the one that matches your copy of Windows

If your computer can run 64bit, and most can, you will get better performance and fewer crashes running a 64 bit Windows and Viewer. If you chose the wrong one, the viewer will upgrade you again the first time you run it to the correct one (if you think it made the wrong choice, please file a bug in jira). This build further refines the determination of what is “the best” platform for your system.

Mac:  the Mac build does not support 32-bit Macs (this is permanent, and not really a change since it’s been some time since LL supported OS X versions that would still run on a 32-bit system).

  • This build shows two icons on the Dock when running. The first one is a new launcher/monitor process (SL_Launcher) that checks for updates; the second is the viewer itself, but both are labelled “Second Life Viewer”. If you are going to pin the icon on the Dock, pin the first one or you’ll get a warning each time you launch. We hope/plan to get this sorted out so that only one shows.
  • Video media (QuickTime) usually does not play (the media handling is now the same as the Windows viewer).
  • The volume of web based media (e.g. YouTube) doesn’t change based on your distance from the source.

Linux: there is no Linux viewer yet. We hope to begin work on addressing this with the community after the release of the Mac and Windows versions.

The release notes for the Animesh project viewer include a summary of the key changes from the previous version of the viewer:

  • Animesh objects should now display correctly as impostors, using the same rules that avatars do currently.
  • Fix for a crash triggered by unchecking the animated mesh check box for an Animesh attachment.
  • Fix for Animesh attachment getting removed after teleport.
  • Fix for some of the cases where animesh graphics state could get corrupted.
  • Various clean-ups and optimisations.

The rest of the SL viewer pipeline remains as per the end of week #49:

  • Current Release version 5.0.9.329906, dated November 17, promoted November 29th – formerly the “Martini” Maintenance RC
  • Release channel cohorts:
    • Wolfpack RC viewer arrived, version 5.0.10.330001, released on November 30.
    • Voice RC viewer, version 5.0.8.328552, October 20 (still dated Sept 1 on the wiki page).
  • Project viewers:
  • Obsolete platform viewer version 3.7.28.300847, dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

 

SL Project Updates 49/2: Web User Group

Grumpity and Alexa Linden host the Web User Group meetings on alternate Fridays at Alexa’s barn

The majority of these notes are taken from the Web User Group meeting held on Friday, December 8th, 2017. These meetings are generally held on alternate Fridays, and chaired by Alexa and Grumpity Linden at Alexa’s barn. The focus is the Lab’s web properties, which include the Second Life website (including the blogs, Destination Guide, Maps, Search, the Knowledge base, etc.), Place Pages, Landing Pages (and join flow for sign-ups), the Marketplace, and so on and the Lab’s own website at lindenlab.com.

Not all of these topics will be discussed at every meeting, however, the intention within the group is to gain feedback on the web properties, pain points, etc., and as such is very much led by comments and input from those attending. Along with this are three points of note:

  • Specific bugs within any web property  – be it Marketplace, forums, Place Pages or anything else), or any specific feature request for a web property should be made via the Second Life JIRA.
  • Alex Linden provides routine updates on the Lab’s SL-facing web properties as and when appropriate, which can be found in the Second Life Web thread.
  • Note that the SL forums are not covered by the Web User Group, as the management of functionality of the forums falls under the remit of the Support Team.

General

  • Work continues on improving Place Pages. One forthcoming update is support for 360 snapshots captured with the 360 viewer (still at project status at the time of writing), including support for 360 images as the hero (top) image on Place Pages, and gallery views support.
    • The 360 snapshot viewer is in the process of being updated to support higher resolution images, fix issues with level of detail loading for objects behind you, etc. It will include support for direct upload to Flickr as well as to Facebook. This update should be appearing “in the next couple of weeks”.
  • Web properties as a whole are also being examined as a part of the overall project to move Second Life to the cloud for delivery. Some services are already managed via the cloud (at least in part), but there is still considerable work to be done and significant infrastructure changes to be made to SL’s web properties, so this is going to be some long-term work.
  • Some are reporting that some Mainland Welcome Area now have Voice chat disabled – some of which might be intentional, due to people abuse Voice within these areas. However, if it is believed Voice has been disabled in error, the advice is to raise a bug report, using the LPDW (Linden Department of Public Works) reporting category, and indicate the affected region and the lack of Voice capabilities.

No Copy Exploits / Illegal Sales of No Copy Items

As I’ve previously reported, one area of concern / upset for content creators has been the use of server exploits to generate copies of No-Copy items, which are then placed for sale, generally through the Marketplace. A long-standing problem, this is now hitting some gacha creators. While the Lab is working to technically address such exploits, some of those experiencing frustration for what they perceive as a lack of action on the Lab’s part procedurally to remove content from the Marketplace / responding to reports of the illicit sale of goods.

These frustrations have most visibly been brought forward at in-world technical meetings – such as recent Simulator User Group meetings and the Web User Group meetings. While the Lindens chairing these meeting are prepared to discuss some options for dealing with such issues  on a technical level (with obvious caveats around discussing the specifics of exploits, fixes, etc.), they cannot speak to issue of Governance, or on matters which may cross into legal areas. This means they cannot respond to questions about specific abuse reports, associated actions / investigations relating to them, or even how governance issues are managed.

While it does not provide an easement for the frustrations that are being felt, it does mean that such forums as the Simulator User Group, Server Beta User Group, Open-Source Dev Group, and the Web Group are not suitable venues in which to seek feedback on governance matters.

DMCA Update

Somewhat related to the above is the informal announcement that the Lab will be changing how people can file infringement notices (DMCA take-down notices) in the near future.

Currently, the Lab’s Infringement Notification Policy requires that such notices are filed with Linden Lab via mail or fax. Once this update has been implemented – possibly around January / February 2018, it will be possible to file notification with the Lab via an on-line form. I’ll hopefully have a full report on this when the forum has been deployed for general use.

Marketplace

  • It is believed that the underlying cause of items being de-listed from the Marketplace has been fixed, and there have been no further reports of new cases where de-listing has occurred. The Lab is continuing to work with those creators who have been affected to ensure all of their affected listing are recovered.
  • Blocking purchasers: some creators would like a means to block people they see as troublesome from purchasing their creations via the Marketplace (just as they can block people from their in-world stores). This is something the Lab is looking at – but again, it is difficult to implement / enforce because of the ease with which alt accounts can be created and used.
  • Marketplace facts: a couple of Marketplace-related facts:
    • There are around 40,000 unique monthly sellers using the Marketplace per month.
    • There are around 150,000 unique buyers using the Marketplace per month.

Seller Verification

: the idea of “verifying” or of at least having some means to control listings on the Marketplace (particularly scam listings / those trying to sell illicit items) was initiated at the inaugural WUG meeting as part of a wider discussion on Marketplace management.

The Lab is looking at various options which might be implemented to help with this, although nothing has been decided as yet. One idea put forward – and again, has not been adopted as something that will happen – is that of applying a listing fee,  potentially tied to a benefit for Premium members (e.g. no fees, or X number of free listings). Given changes to fees for cashing-out will be made in January 2018, and LindeX fees were recently changed, this did not go over well with some at that meeting, although others seemed in favour, although it does potentially represent a higher barrier to entry into selling content.

A resident-voiced proposal is for those using the Marketplace to supply some aspect of their physical world information as a means of verifying who they are (already required for those cashing-out L$ balances to fiat money)  – something which may discourage content copiers and MP spammers, but which might again discourage other who sell on the MP, but who don’t necessarily cash-out (they use the L$ income to support their in-world activities) from continuing to participate in the MP.

This approach might also allow those merchants who have verified their accounts with the Lab to have some form of “verified” / “trusted” icon displayed within their listings, although the legal ramifications for the Lab in doing this would likely have to be investigated (for example, how vulnerable might the Lab be to legal action should a so-called merchant “verified” as “safe” by them start selling illicit goods at another’s expense?).

In terms of stolen / copybotted goods on the Marketplace and scam accounts, Grumpity Linden stated the Lab’s broader aims:

Meeting Contents

It has been noted that Marketplace-related items are dominating the two WUG meetings held thus far, leads to some concerns that other web-related topics may get pushed out of meetings. Of all the Lab’s main user-facing web properties, the Marketplace is probably the most visible, and carries the largest potential impact with people, therefore a focus on it is to be expected (particularly given the Commernce Team abdicated their own in-world meetings around 5-6 years ago and have shown no willingness since to re-engage in them). However, Grumpity and Alexa acknowledged the wider purview of the WUG meetings, and suggested that a portion of future meetings might be set aside to discuss non-Marketplace web topics.

Date of next meeting: Friday, January 5th, 2018.