SL User Group Meetings – Page 141 – Inara Pey: Living in a Modemworld

A look at Second Life updates in 2017

Posted on December 27, 2017December 24, 2018 by Inara Pey

La Vie, October 2017 – blog post

Each week through the year, I try to get to as many in-world and other meetings held by the Lab to keep an eye on technical developments and updates which are in the works for the viewer and the simulator, relaying the notable items via my SL project updates. As such, I thought it might be interesting to look back at some of the technical changes and updates have come our way in 2017.

Visible Projects

The year started with everyone still getting their heads around 2016’s Project Bento, which reached release status at the end of that year, bringing with it a much extended avatar skeleton with masses of new bones allowing a range of new animations and opportunities for more diverse avatar looks that used bone animations rather than resource-heavy options such as alpha flipping and so on.

Thus, 2017 – or at least the early part of it at least – saw many Bento releases hitting Second Life, from animal avatars through to Bento-enabled avatar mesh heads and hands which offer a greater range of expressions and natural motions, natural jaw and mouth movements to go with Voice or with text chat, and so on. Given the interest in Bento, I offered a behind-the-scenes look at the project from a personal perspective, having been an observer of the work from the initial closed development work all the way through the open beta to release.

I eventually made the move to a Bento head in September 2017, after extensive fiddling with demos from all the major makers, with (r) Lelutka proving to be the best in terms of maintaining much of my “original” (aka “2010 onwards”) look (l), as I played with the demo model & test skin)

The Bento project gave rise to several potential follow-on projects, of which the three most popular among creators at the Bento / Content Creation meetings were: supplemental animations, to allow smooth interaction between animations as a result of conflicts arising between the extended bone groups (currently on hold), animated mesh – eventually renamed “Animesh”, and bakes on mesh – with the latter two becoming a particular focus of the in-world Content Creation User Group meetings, together with the Environment Enhancement Project (EEP).

Animesh is 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. It can be used with 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. During 2017, the focus has been on getting a basic Animesh capability working in Second Life, which by the end of the years saw a project viewer at an advanced stage of development. 2018 should see this move to RC status, and the project as a whole move to release. A potential follow-on project may then see the capability extended to allow more in the way of NPC creation through Animesh.

Animesh allows you to take rigged mesh objects, add animations and controlling scripts to them, associate them with an avatar skeleton, and have them run in-world without the need for any supervising viewer / client

Bakes on Mesh extends 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 (but does not include normal or specular support). Once this initial work has been completed, 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.

Environment Enhancement Project is a set of updates to Windlight settings, etc. These include 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.

While 2017 didn’t see the deployment of many high-profile user-facing projects, it did see a considerable amount of back-end work take place, not all of which was necessarily user-visible, and some of which also affected the viewer. In summary this work included:

A complete overhaul of the simulator code build process, including upgrading the Linux OS for the simulator servers – the first of such rounds of OS update.
Moving most of the remaining SL asset (inventory items) handling from UDP messaging through the simulators to HTTP delivery via the CDN.
Increasing Region capacity (avatar numbers), with a perk for Premium members.
Announcing a major initiative to move all the Second Life services into the cloud, if possible. More info came through a TPVD meeting and Tara Hernandez, Senior Director of Systems and Build Engineering at Linden Lab, touched on the project in a presentation at AWS:Invent.
Changing how multiple, repeat teleport requests made via scripted HUDs were handled to reduce the impact such requests have on region performance.
The start of a project to revise the complexity calculations (in-world objects and Avatar Rendering Complexity) to make them more accurate / stable and reflective of the true cost of rendering items – this work is still ongoing.
Continuing work to eliminate exploits use to crash regions and to make the simulator code generally more robust, trying to curb illicit content copying, etc.

The Viewer

Much of 2017’s focus on the viewer was directed at moving it to 64-bit for Windows (whilst also maintaining a 32-bit version as well) and for Mac OS X. Started in 2016, with a significant overhaul of the viewer build process and its associated libraries, the first project viewer release for the 64-bit viewer – code-named Alex Ivy (aLeX IVy = LXIV = 64) – arrived in early January, with work continuing throughout the year to refine the viewer, work out issues in the build process, and move the project towards release status – which should now happen in early 2018.

The 360-snapshot viewer received an overdue update which, while suffering from pro resolution issues, did streamline the production of 360-images. This was the only update to the viewer in 2017, leaving it as project viewer status. More work will be forthcoming in 2018.

*The revised snapshot floater in the July 2017 360-snapshot project viewer*

The Lab also restated their desire to continue with Linux, by offering a Debian build of the viewer – but only with the help ogf the Linux community.

Other updates for the viewer in 2017 included custom folders for uploads, the launch of a new release candidate branch of the viewer specifically to manage fixes and updates to the viewer’s rendering pipe, the first pass at improving region / estate ban lists for estate owners, the viewer’s avatar rendering options (right-click context menu and Preferences > Graphics) were improved to allow users to better define how avatars around them are defined. New region / parcel access controls were introduced and a WORN tab was (finally) added to the inventory floater. There was also the ongoing series of Maintenance RC releases throughout the year, aimed specifically at fixing bugs and issues, which in 2017 gained their own code-name series, each one being named for an alcoholic beverage.

Other Updates and Changes

A new Second Life Community Platform officially launched on Tuesday, March 14th, 2017. You can read my overview of the platform here.
Places Pages officially launched after a beta run, and continued to be refined.
Mesh upload pre-requisites were revised.
The SL support site was updated, although not without hiccups.
Webs service updates got an end-of-year round-up, and the new Web User Group in-world meetings launched.

You can follow my updates on SL technical developments and updates through the likes of my weekly SL project updates and weekly viewer release summaries (which also cover TPV releases).

SL project updates 51/2: CCUG and viewer

Posted on December 22, 2017September 27, 2024 by Inara Pey

*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:

Current Release version 5.0.9.329906, dated November 17, promoted November 29th – formerly the “Martini” Maintenance RC – No Change
Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
- Alex Ivy 64-bit viewer, version 5.1.0.511248, December 11.
- Voice RC viewer, version 5.0.10.330039, December 12.
Project viewers:
- Project Render Viewer version 5.1.0.511446, December 18.
- Animesh project viewer version 5.0.10.330058, December 11 – project overview.
- 360-degree snapshot viewer version 5.1.0.506743, June 29 – hands-on overview.
Obsolete platform viewer version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

SL project updates week #51: server, viewer

Posted on December 20, 2017September 27, 2024 by Inara Pey

Cherishville – blog 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:
- Alex Ivy 64-bit viewer, version 5.1.0.511248, December 11.
- Voice RC viewer, version 5.0.10.330039, December 12.
- Wolfpack viewer, version 5.1.0.3300001, November 30.
Project viewers:
- Animesh project viewer version 5.0.10.330058, December 11 – project overview.
- 360-degree snapshot viewer version 5.1.0.506743, dated June 29 – hands-on overview.
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

Posted on December 16, 2017September 27, 2024 by Inara Pey

The Outer Garden – blog 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

Posted on December 15, 2017September 27, 2024 by Inara Pey

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

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.