2018 SL project updates 16/2: Content Creator User Group

A rally of (Animesh) raptors on Aditi

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, April 19th, 2018 at 13:00 SLT.  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 summary. My thanks to him for providing it. Time stamps are included in the text below to allow easy referencing to the video for details.

Initially, the meeting opened on Aditi at the Animesh test regions.however, Voice issues across the beta grid regions resulted in the meeting decamping to the TPVD amphitheatre on Agni, and these notes reflect the meeting from that point onwards, starting at the 7 minutes 19 seconds point in the video.

Animesh Project

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.

Project Viewer

The project viewer with the updated Animesh land impact / tri count formula was released on Monday, April 16th. Version 5.1.4.514468 also brings the viewer to parity with the current release viewer.

Vir’s provides a detailed explanation in the Animesh updated limits and cost formulas forum thread, However, in summary:

  • Animesh attachment limit = 1: only one Animesh object can be attached to an avatar at a time. This is unchanged from the original estimates.
  • Triangle Count Limit = 100,000: an animesh object (linkset) can have at most 100k triangles, where the count is based on the estimated size of the largest LOD (normally this is the high LOD). This includes all mesh triangles, static or rigged.
  • Land Impact: streaming cost = 15.0 + 1.5 * ktris + cost of non rigged prims: for a rigged mesh prim in an animesh linkset, the streaming cost will be 0.0015 * effective_tri_count – that is, 1.5 per thousand triangles. The value for effective_tri_count is derived from the estimated triangle count of the various LODs in the prim as follows:
    • High LOD: all of the estimated triangle count included in the effective_tri_count.
    • Medium LOD, Low LOD and Lowest LOD: the allowed number of triangles can be up to ½ of the LOD above, or 64, whichever is larger (i.e. Medium can be up to ½ of High, or 64, whichever is larger). If there are more triangles than this limit, that excess will be added to the effective_tri_count.
  • These values are also reflected in ARC (avatar rendering cost) calculations for Animesh items.

[7:23-8:43] The viewer also incorporates a change where it will automatically switch to skeleton based rendering for Animesh as soon as it detects the use of an avatar skeleton in an object, rather than waiting until an animation starts playing on an Animesh object in order to make the switch. It is hoped this will avoid issues between an Animesh object’s static and animated states, which can cause visual glitches when the animation based switch is made. It should also avoid potential exploits with people using multiple Animesh objects without necessarily animating them.

[9:13-9:32] It is believed the majority of bugs for Animesh are now in hand, however if any finds specific issues with the new impact calculations or with the latest project viewer in general, they are asked to file a JIRA bug report.

Rigged Mesh Level of Detail / Bounding Box Issues

Beq Janus has reported on issues with rigged mesh LOD issues related to the avatar bounding box. Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar Bounding Box. Some creators, deliberately or otherwise, force the bounding box to be far larger than is required, which then creates problems

For example, if an avatar bounding box is forced to 15 metres on a side, any rigged object worn by that avatar will swap LODs as if it were 15 metres in size, no matter how small, forcing viewers around it to use its highest LOD model unnecessarily (see BUG-214736 for more).

[8:44-9:12]  Graham Linden has been investigating these, as has some proposed changes which he and Vir hope to implement in the near future, the implication being these will be folded into the Animesh viewer.

Environment Enhancement Project (EEP)

Project Summary

A set of environmental enhancements, including:

  • The ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level.
  • New environment asset types (Sky, Water, Days – the latter comprising multiple Sky and Water) that can be stored in inventory and traded through the Marketplace / exchanged with others.
  • Experience-based environment functions
  • An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.

This work involves simulator and viewer changes, and includes some infrastructure updates.

Current Status

[10:35-11:05] Rider Linden has been involved in dealing with other issues, which have delayed progress on EEP. He hopes that with this worked cleared, he’ll be able to focus on getting the viewer updates out in a project viewer.

Continue reading “2018 SL project updates 16/2: Content Creator User Group”

Advertisements

2018 SL project updates 14/2: CCUG summary

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 (CCUG) meeting, held on  Thursday, April 5th, 2018 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 summary. My thanks to him for providing it. Time stamps are included in the text below to allow easy referencing to the video for details. Please note that Vir’s microphone was not behaving during the meeting, causing his voice to drop-out at times, breaking up the context of his conversation (I had the same issue with my audio recording).

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.

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

Resources

Current Progress

The project viewer is now available – version 5.1.3.513936, which as noted in previous updates, was released on March 30th. This is the first pass of the viewer, and there is much more work to come.

General Notes from the Meeting

[2:55-04:00] Some mesh body creators are already involved in looking at Bakes on Mesh, and the Lab has been gathering names and details of creators, but there has – as of the time of the meeting – been no direct outreach to any of them. Siddean Munro (Slink) is reported to be “thrilled” with the capability, and sees it as a means to dramatically reduce her workflow.

[4:45-5:55] Status of 1024×1024 support: While the first part of the Bakes on Mesh project was to update the Bake Service to support 1024×1024, currently, these back-end changes have not been deployed, so all Bakes on Mesh testing currently use the existing 512×512 textures supplied by the Bake Service. The deployment has been delayed due to other work being carried out on the Baking Service, but it is hoped it will be deployed in the next few weeks.

[13:26-14:22] It terms of 10242 texture support with the baking services is eye textures. Currently 128×128, these will be increased to 256×256, the pixel density on so small a target compensating for the lower resolution.

When  the increased texture resolution support is deployed, the Lab will also be implementing additional servers to support the additional load on the Baking Service.

[6:01-8:49] Wearable/ Texture Map issues: It’s been noted that the eyelashes are tied to the avatar eyeball texture, not the avatar head, which might cause some issues.

The right / left arm being mirrored in the texture map has also been re-noted. This is prompting some creators to consider re-purposing the system skirt or hair wearable (which are now almost never used) to be assigned to one or other of the arms. This would  allow, for example, a tattoo to appear on one arm only, rather than being mirrored on both arms, as is currently the case on system avatars.

[9:52-11:05] In order for this to work, the textures would need to be uploaded as a skirt or system hair. Basically, the system wearables act as containers of the textures, so if you want to apply a texture to a specific body region (as supported by the viewer / Bakes on Mesh), you can assign it to that wearable (e.g. the texture can be applied to the undershirt, shirt or jacket wearable to be applied to the upper body, or to the skin wearable to be applied to the entire body).

Cathy foil also gave feedback on using Bakes on Mesh to apply system eye textures to mesh eyes.

[8:53-9:49] Will the baked texture slots be expanded in to future? (there are currently 6 slots: BAKE_HEAD, BAKE_UPPER, BAKE_LOWER, BAKE_EYES, BAKE_SKIRT, BAKE_HAIR.) Possibly, but not being considered with Bakes on Mesh at present. Currently, the bake texture slots are tied to the supported wearable textures. Adding more slots  would require defining the underpinning data to be stored in the additional slots (i.e. define additional wearables).

[12:10-12:36] One thing to remember is that if an alpha layer in used to hide your system avatar (or a major part of it), it will be baked as well, and if that bake is applied to a mesh, it can end up masking more of the mesh than intended, due to the extent of the alpha.

[14:42-17:02] Hiding the base avatar: a means to hide the system avatar without having to use an alpha mask has long been a request, raised again during the Bakes on Mesh project. No decision has been made on if this will be done or how. One approach might be to make a further change to the Bake Service so it ignores the base avatar; another might be it use an unassigned texture slot to “hide” the avatar from the Bake Service – this has the advantage of not requiring a change to the Bake Service.

[17:29-25:00] A general discussion on how a more flexible use of Bakes on Mesh might be achieved – such as re-purposing rarely used texture slots, or extending the Bake Service itself.

  • Re-purposing texture can be done with care – such as using the skirt or system hair as described above to give individual texture for the arms.
  • Further extensions to the Bake Service itself – e.g. additional bake slots beyond the current 6  are unlikely to form a part of this project, but might be considered for any follow-on that comes after it.

The Lab also have some concerns about opening-up the Bake Service further include the potential for performance hits, possible abuse.

Cathy Foil demonstrates Bakes on Mesh. Left: she is wearing a mesh body with system layer clothing applied to it, as seen through the Bakes on Mesh viewer. Currently, only those using the Bakes on Mesh project viewer will still mesh bakes in this way. Right: until the Bakes on Mesh code is incorporated in all viewers, those running viewers without the code will see avatars using Bakes on Mesh with place holder textures on place of the baked texture.

[25:09-27:35] Extending the Bake Service to support materials: this is a complex step to take, which may not even be properly defined. Maps (diffuse (texture), normal and specular) all have to be defined by layer and brought together properly in a composite bake in such a way to ensure normal and specular maps from one layer are correctly associated with the diffuse map from that layer, so they aren’t displayed over another layer. As such, materials support will only be considered as a potential element for a follow-on project to the current Bakes on Mesh work. See also BUG-214631 for a proposal on how materials support might work.

[33:37-34:11 and 36:40-37:20] Bakes on Mesh for HUDs / Bakes and Textures: conversation on bakes on mesh and HUDs, expansion on Bakes on Mesh vs. appliers, and texture and Bake UUIDs. In short: Bakes on Mesh can also be applied to HUDs, which could help reduce the number of textures commonly found in them (a single composite rather than multiple textures). Complexity of HUDs might also be reduced, simply because the texture applying elements may no longer be required as textures will come via the Bake Service – although applier HUDs for materials will still be required.

Some are concerned allowing bakes on HUDs increases the risk of texture theft (by allowing the textures to be screen capped, for example). However given this can be done anyway, simply by displaying a texture on a cube and then attaching the cube to the screen as a “HUD”, it’s hard to see what the fear really is (it’s also not the most efficient way of wrongly getting a texture out of SL).

[42:40-44:13] Fewer textures: the general hope with Bakes on Mesh is that over time, it will allow mesh bodies  / heads to be less onion layer complex, and also reduce the number of different textures being applied, by allowing layers (e.g. skin, make-up, tattoo, etc.), to be composited down to a single baked texture.

[44:26-45:52] Wearables cap: a reminder that up to 60 wearables can be applied to a single avatar in any combination of layers, and the order in which they are displayed corresponds to the individual layers (e.g. undershirt, shirt, jacket), and the order in which multiple items in those layers are worn. See this 2015 project update for more on the global wearable allowance.

[47:17-47:32] Can local textures be used with Bakes on Mesh? No. local textures are just that, local to a user’s system; they are not transmitted to LL’s servers, and therefore, they cannot be baked.

[48:10-49:00] Bakes on Mesh and Edit Appearance:  it’s been noted that mesh bakes don’t update with changes made in the Edit Appearance mode (see BUG-216014). This is because Edit Appearance is local changes within the viewer, usually applied to the system avatar. Bakes on Mesh require the data to be sent to the baking service, composited, and applied – which only happens on exiting Edit Appearance. Vir has indicated it might be possible to add the logic required to have the appearance editor update in real-time when using mesh bakes.

Continue reading “2018 SL project updates 14/2: CCUG summary”

2018 SL project updates 13/3: CCUG summary w/audio

A rally of (Animesh) raptors on Aditi

The following notes are primarily taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, March 29th, 2018 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.

There is no video to accompany this update, notes are taken from my own audio recording of the meeting.

Animesh Project

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.

Current Progress

Vir now has a proposed revised land impact / tri count formula and test plan for Animesh. This will be going to QA, and if all goes well, the new formulas will be deployed on the Aditi Animesh test regions ready for public testing. No end-date for public testing on Aditi has been defined – the Lab want to ensure as many as are interested have to opportunity to test the new formula. Animesh attachment will remain limited to one per avatar, at least for the time being.

It is likely that server-side support for Animesh will reach the Main grid ahead of the project viewer reaching release candidate status – although this still won’t be for a while.

LODs and Streaming Costs

How Animesh Level of Detail (LOD) is handled is still being tweaked. Currently, Animesh objects sit between in-world objects and avatars in terms of the way their LODs are handled / swapped. The Lab is looking to adjust this, so that Animesh LODs are more consistently handled as they would be for in-world objects.

The broad plan is – for Animesh only – that the lower LODs will not affect streaming costs so long as they are not disproportionately large. Providing they get smaller by at least a factor of approximately 2 as they go down to the courser LODS, they will not impact streaming costs.

Note this work is not part of Project Arctan, which may lead to further changes in costs associated with objects at some point in the future – see below for more.

Project ARCTan

This is the code-name for the project to re-evaluate object and avatar rendering costs (e.g. Land Impact and avatar ARC), led by Graham Linden as a part of the overall rendering system work. The aim of is to have the costs assigned to objects and avatar more accurately reflect the impact they have on people’s viewer performance.

The hope is that overall, by making a careful set of adjustments, not only can client-side performance be improved, but creators can be given positive incentives to build more performant content (a problem currently being that providing good LOD models – high, medium, low and very low – for mesh content can actually penalise a creator in terms of upload costs / Land Impact, encouraging them to skip doing so).

This project is still in the early stages, and the Lab is fully aware of the risks and concerns involved in potentially making changes to things like Land Impact (e.g. undesired object returns), and so are approaching the work cautiously. Right now, data is being gathered and internal comparative testing is being tried. There are no plans to make any kind of changes in the immediate future. When changes do start to be made, they will be done so carefully to avoid disruption, and users will be appraised of what is happening and when.

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.

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

It is important to note that this project is still in its preliminary stages. Any release of a project viewer doesn’t mark the end of the project, but rather the start of initial testing and an opportunity for creators to have input into the project.

Current Progress

The project viewer is still with QA with a couple of outstanding JIRAs awaiting resolution. The hope is that it will be making a public appearance soon.

When issued, this viewer should work anywhere, as it doesn’t require simulator changes. However, only those using the project viewer will see things as intended. Anyone on a viewer without the Bakes on Mesh updates will see placeholder textures, rather than the intended baked textures, on avatars trying the Bakes on Mesh capability.

Bakes on Mesh will essentially use the three avatar elements used by the baking service – head, upper body, lower body, eyes, hair, skirt), and applies clothing bakes for those elements to specific mesh faces, effectively “hiding” the corresponding base mesh region. This means for example, a head bake can be applied to a mesh head, an upper body to the mesh upper body faces, etc.  It does not at this point allow for more finely tuned applications – such as an individual jacket layer, or just to the hands.

Environment Enhancement Project (EEP)

Project Summary

A set of environmental enhancements involving simulator and viewer changes, and includes some infrastructure updates.

Current Progress

Rider is still engaged on infrastructure work, which he hopes to complete Soon TM. Once that is done, he’ll complete the work on assets in inventory.

Custom Pivot Points

Work is being carried out to provide custom pivot points for mesh objects (see BUG-37617). This will most likely appear in a Maintenance RC viewer, once ready. The exactly implementation details weren’t clear at the meeting; it’s believed the data for the pivot point is coming from the corresponding data for the highest LOD in the uploaded .DAE file. However, the pivot point must be inside the bounding box of the object, and remains the centre of the object. Steps will also be taken to prevent pivot points placed outside of the bounding box simply causing the bounding box to increase in size (as did happen in a mesh uploader error), as this tends to both increase the objects LI by a factor of at least 2, and break the associated LODs.

Other Items

Texture Caching

Work continues on trying to improve texture caching in the viewer – which has already been an educational process for the Lab. There is nothing on the horizon yet in terms of updates for the viewer, as the work is not seen as a high priority when compared to other projects. However, there is a belief that there is room for “dramatic improvement” in the way textures are managed.

Permissions System

The question was asked if there are any plans to re-work the Second Life permissions system to be more supply chain driven, as is planned for Sansar. Short answer: there are no current plans to overhaul the permissions system simply because it is so complex. Currently the only thing being considered with permissions is extending them to allow scripted permission changes (formerly known as mod keys), which are seen as important for enhancing Animesh capabilities. However, here are current no time frame in when / if these will be implemented.

Firestorm RenderVolumeLODFactor Setting / Object LOD Confusion

Some appear confused by the recent RenderVolumeLODFactor behaviour change (see here) and what it is doing, believing it is part of a change to object LODs in Second Life.

Essentially, the Firestorm update is purely a viewer-side change only, intended to encourage users not to use over-the-top settings in their viewer which can affect performance, because changes to this value are globally applied, affecting all objects within the viewer’s field of view, not just a specific wearable or object.

However, this change does not mark any kind of change to the object’s LOD data held on the servers (the content isn’t being “changed” in any way on the back-end); it purely alters the way content is rendered by the viewer in terms of which LOD model of the object it uses.

Date of Next Meeting

There will be a CCUG meeting on Thursday, April 5th, as the normal LL internal meeting has been postponed a week.

2018 SL project updates 12/2: CCUG summary

A rally of (Animesh) raptors on Aditi

The following notes are primarily taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, March 22nd, 2018 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.

There is no video to accompany this update, notes are taken from my own audio recording of the meeting.

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 on avatar meshes.
  • An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). 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.

It is important to note that this project is still in its preliminary stages. Any release of a project viewer (see below) doesn’t mark the end of the project, but rather the start of initial testing and an opportunity for creators to have input into the project.

Project Viewer

  • QA testing revealed a number of bugs which need to be addressed before the project viewer reaches public consumption.

EEP and Atmospheric Shaders Work

Environment Enhancement Project (EEP) Summary

A set of environmental enhancements, including:

  • The ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level.
  • New environment asset types (Sky, Water, Days – the latter comprising multiple Sky and Water) that can be stored in inventory and traded through the Marketplace / exchanged with others.
  • Experience-based environment functions
  • An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.

This work involves simulator and viewer changes, and includes some infrastructure updates.

Current status: Rider Linden is working on some internal fixes for EEP which should hopefully move it closer to public visibility, and there is some more infrastructure work to be done.

Atmospheric Shaders Work

A project to revamp the viewer’s atmospheric shaders and rendering.

Current status: Graham Linden indicated “good stuff” is in the works, but nothing he can publicly report on as yet.

Animesh Project

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.
  • Will not support its own attachments in the initial release.
  • Will not initially include the notion of a body shape (see below).

Resources

Current Progress

Vir continues to work on performance profiles, and is “pretty close” to having something for Land Impact, with a formula under evacuation. Among the changes, this formula calculates scaling differently, and Vir notes there are a number of corner cases which need to be dealt with. The tri count cap will also be finalised alongside the updated LI formula.

Rigged Mesh Level of Detail / Bounding Box Issues

Beq Janus has reported on issues with rigged mesh LOD issues related to the avatar bounding box. Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar Bounding Box. Some creators, deliberately or otherwise, force the bounding box to be far larger than is required, which then creates problems

For example, if an avatar bounding box is forced to 15 metres on a side, any rigged object worn by that avatar will swap LODs as if it were 15 metres in size, no matter how small, forcing viewers around it to use its highest LOD model unnecessarily (see BUG-214736 for more).

Vir Linden agreed that this is a problem, and that forcing abnormally large avatar bounding boxes is undesirable. In some places, the Lab tries to use the rigged mesh wireframe as the basis for the bounding box, which is seen as a little more robust as it is looking directly at the triangle data, rather than working off of the avatar itself – and this is the approach being considered with Animesh to avoid similar issues with Animesh rigged mesh failing to correctly LOD in the viewer – however, so believe the use of such static data is “meaningless”.

JIRA “Accepted” Status

The “Accepted” status on the JIRA still causes some confusion. In brief:

  • For BUG reports, Accepted tends to mean the Lab have imported the report for evaluation / agree to there being a bug and will look to fix the issue. When it is addressed is dependent on a number of factors (e.g. severity of the issue).
  • For feature requests, Accepted means the Lab is sufficiently interested in the idea to want to track it. It does not mean the idea will be implemented, either in whole or in part. Whether it is implemented in whole or in part again depends on a number of factors (how it sits within the current workflow, whether or not it is related to work being carried out and can be added to it; whether it is something which might be implemented alongside of upcoming work; whether it is better to hold off until it and other ideas like it can be implemented together as a project, etc.).

Return of Last Names

The last portion of the meeting focused on the recent blog post from Linden Lab indicating Last Names would be returning to Second Life. Given the level of interest in this project, I’ve written a separate update on this section of the discussion. See:  The return of Second Life Last Names – update with audio.

In Brief

  • Rigged / static meshes using transparencies (blended or masked) tend to cast an incorrect shadow

    Transparency shadow casting from rigged items: there is an issue with rigged / static meshes using transparencies (blended or masked), which causes shadows cast by them to render incorrectly (shadow rendering conforms only to the geometry silhouette). Graham Linden indicated that this is something the Lab plans to fix, but the work has yet to be scheduled.

  • Switching mesh asset on the same prim root: this used to be supported via script, but was removed due to people using it to create flipbook style animations which could adversely affect performance. It’s been suggested that it could offer an alternative to performance-impacting alpha swapping on meshes; however, the Lab’s view is that while alpha swapping is performance impacting, switching entire mesh assets would still be more of a performance hit, as the latter requires all of the geometry data associated with the mesh to be rebuilt every time.

2018 SL project updates 10/2: CCUG summary

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 (CCUG) meeting, held on  Thursday, March 8th, 2018 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.

There is no video to accompany this update, notes are taken from my own audio recording of the meeting.

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.
  • Will not support its own attachments in the initial release.
  • Will not initially include the notion of a body shape (see below).

Resources

Viewer Update

An updated to the Animesh project viewer occurred on Wednesday, March 7th with the release of version 5.1.3.513013. The focus of this update has been bug and crash fixes (e.g. correcting some of the issues of LODs getting stuck).

Current Progress

  • The major piece of work to be completed (other than further bug fixing) is performance profiling: looking at possible limits on tri count, LI, to ensure Animesh can scale across regions without becoming a major performance impact. This work takes object scaling into consideration.
  • Remaining bugs to be resolved include the animation timing issue, whereby an avatar entering a region were an Animesh object is already running may not receive the animations updates for the object. This is liable to require both viewer and server updates to fix.

Body Shapes

Providing a notion for Animesh objects to have a body shape is being considered as an initial follow-on for the project. If implemented, this would mean that Animesh creations could:

  • Make use of the shape sliders.
  • Utilise the Appearance / Baking Service.
  • Have a fully avatar-like inventory.
  • Make use of the server-side locomotion graph for walking, etc.

The assumption is that if the Lab look to add this functionality, it will be handled in much the same was as is the case for avatars. However, this aspect of the work will be opened up for discussion and ideas once it has been officially adopted as a follow-on project, rather than having speculative (and premature) discussions about how body shapes might be applied / managed.

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 on avatar meshes.
  • An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). 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.

It is important to note that this project is still in its preliminary stages. Any release of a project viewer (see below) doesn’t mark the end of the project, but rather the start of initial testing and an opportunity for creators to have input into the project.

Project Viewer

  • Currently with the Lab’s QA team.
  • Will support a basic means of applying system bakes to mesh faces, although their will be caveats as to how well this initially works (e.g. matching to mesh UV maps).
  • The majority of this work is viewer-side, allowing mesh faces to be flagged with a special texture ID which allows a specific part of an avatar bake to be applied to them.

Feature Request JIRA

It is recognised that there are numerous questions / concerns relating to Bakes on Mesh (see my week #8 update). Because of this, and the lack of a specifications document, user Elizabeth Jarvinen (polysail) has started putting together a Feature Request JIRA outlining some of the specifics which need to be considered with regards to the project. Some of the ideas offered might be considered as a part of the initial Bakes on Mesh project, so might be left for a follow-up project. For more information on this follow the links below:

Project Arctan

This is the code-name for the project to re-evaluate avatar and object rendering costs (avatar complexity and Land Impact). Again, just to be clear on this project:

  • It is only just starting.
  • The aim is to make avatar complexity and Land Impact values more reflective of the actual “cost” to render avatars and objects. This might lead to ARC / LI values changing.
    • However, there are currently no details of how LI / avatar complexity values may change or when, as the Lab is still gathering data at this point in time.
    • The Lab is aware of the potential for increases in LI values to cause disruption, and if this is the case, they will seek to minimise the impact as far as possible.
  • The work is not related to Animesh – which will see a “basic” cost (in terms of geometric complexity) applied to Animesh objects (see performance profiling, above). Animesh objects may be subject to further revision as a result of Project Arctan’s findings.
  • It is hoped that Graham Linden, who is leading the project, will attend future CCUG meetings to discuss Arctan as the project progresses.

Other Items

  • PBR Shaders: there have been requests for the Lab to implement physically based rendering (PBR) – using realistic shading/lighting models along with measured surface values to accurately represent real-world materials. Such requests have been noted by the Lab. While adding support for PBR shaders has not been ruled out, it is seen as a significant undertaking, and is thus seen more as a “someday, maybe” piece of work, rather than being a part of the current SL enhancement roadmap.
  • Terrain texture improvements: terrain textures in SL suffer from a low texture density, causing blurring, etc. Again, the Lab is aware of this, and considering making improvements to terrain texture as a possible future project.

Next Meeting

The next CCUG will be on Thursday, March 22nd, 2018, and 13:00 SLT.

2018 SL project updates 8/2: Content Creator User Group

A rally of (Animesh) raptors on Aditi

The following notes are primarily taken from the Content Creation User Group meeting, held on  Thursday, February 22nd, 2018 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.

SL Viewer

  • The project render viewer was updated to RC status on Wednesday February 21st become the Love Me Render viewer, version 5.1.2.512751. The two primary improvements to this viewer are:
    • An improvement to mesh LOD calculation (account for CTRL+0)
    • Agents that render as jelly dolls should have their attachments render at 0 LoD to prevent loading higher LoD complexity in memory thus deterring crashes. The debug setting RenderAutoMuteByteLimit has to be greater than the default of 0 for this feature to work.
  • The Nalewka Maintenance RC viewer also updated on Wednesday, February 21st, to version 5.1.2.512752.
  • The 360-degree snapshot viewer updated on Thursday, February 22nd to version 5.1.2.512774 – see my hands-on overview for more.

Bakes On Mesh

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 on avatar meshes.
  • An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). 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 Status

Anchor Linden is currently working on viewer-side support, and hopes to have a project viewer, together with test regions on Aditi, available for testing “soon”.

There is a growing number of questions / concerns around this work which have yet to be fully answered:

  • How will the system avatar be masked? Via a dedicated alpha channel?
  • What creators need to do in order to leverage the capability. Essentially, the process requires specifying which mesh face gets what bake channel – but is this actually defined?
  • Will there be scripted support (seen as vital to allow continued use of normal or spec maps, for example)?
    • How might HUD systems that apply materials work in conjunction with bakes on mesh (e.g. to continue to simulate cloth textures, as seen in current clothing appliers)?
  • Has there been any attempt to reach out to and encourage the makers of popular mesh bodies / heads to engage in the project, body to understand what is being attempted and how best to ensure it is something they would be willing to leverage?
    • Alexa and Vir have both indicated that this is on the Lab’s plans for the project, once a basic project viewer is available so that people can actually start investigating what might be required to leverage the capability properly.
  • Is there a project specification people can refer to / contribute to?
    • Elizabeth Jarvinen (polysail) has offered to write a Feature Request Specification. Those wishing to contribute to it should contact her in-world.

Animesh

  • Vir is focused on bug fixes at the moment.
  • There is a potential new project viewer waiting in the wings, but this is dependent upon some of the bug fixes, such as LOD stability issues and camming problems.
  • There is still no definitive time-frame for the release of Animesh – it’s now largely dependent on the bug fixing work.

Project Arctan

This is the code-name for the project to re-evaluate object and avatar rendering costs. It is still in its very preliminary stages, and might, in time, lead to a change in how Land Impact is calculated and assigned. No decisions have been taken (as the data has yet to be collected and analysed and decisions made), so this not something that will be happening soon – and even when it does, it may not cause any appreciable changes for the majority of users, simply because the Lab is looking to minimise any impact which may come out of the work as much as they can.

Just what is being planned and how any negative impact on LI might be mitigated were discussed at both the week #7 CCUG meeting and that week’s TPVD meeting, and the following audio featuring extracts from both meetings will hopefully further contextualise how the work is being approached, and hopefully ally fears.

Environment Enhancement Project (EEP)

Project Summary

A set of environmental enhancements, including:

  • The ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level.
  • New environment asset types (Sky, Water, Days – the latter comprising multiple Sky and Water) that can be stored in inventory and traded through the Marketplace / exchanged with others.
  • Experience-based environment functions
  • An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.

This work involves simulator and viewer changes, and includes some infrastructure updates.

Current Status

  • Rider Linden is now “well on the way” to having working inventory Windlight assets.
  • Once he has finished this element of work, he hopes to put out a project viewer for use of test regions on Aditi which have the necessary support for managing the new Windlight assets – this could happen in March.
  • The will be no direct LSL support for the new assets in the first EEP release.
  • llGetSunDirection() will initially be broken as a result of the alterations to the day / night cycle:
    • The sun’s position will no longer be based on the default Linden Sun (which has a four-hour “day”), but defined by the environment itself, allowing for more physical world daylight times
    • The function will be updated to work with the new EEP capabilities before the project gets to release status.
  • Once llGetSunDirection() has been updated, sundials using it should accurately reflect the position of the Sun over a region, rather than being indicative of its general position in the sky. However, sundials using the scripted function to count the number of seconds since “midnight” in a 4-hour day cycle in order to simulate the Sun’s position in the sky will be broken.
  • Essentially, EEP should allow Windlight settings to work as we see them now, but a) as objects which can be applied from inventory; b) on the basis of agent application through an experience. It should also work closely with the planned atmospherics updates.

Atmospherics Updates

A separate piece of work in progress – albeit it related to EEP – is a set of updates to SL’s atmospheric shaders. This work is being carried out by Graham Linden, and among other things, will allow for things like Godrays, improved visual fogging, etc. There’s currently no time frame on when this work might publicly surface.

Next Meeting

The next CCUG meeting will be held on Thursday, March 8th, 2018.