2019 SL User Groups 16/2: Content Creation summary

Puddlechurch; Inara Pey, March 2019, on FlickrPuddlechurchblog post

The majority of the following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, April 16th 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

SL Viewer

  • The Estate Access Management (EAM) RC viewer, version 6.2.0.526190, dated April 12th, 2019 was promoted to the de facto release viewer on Wednesday, April 17th. See my EAM overview for more information.
  • The Teranino Maintenance RC viewer updated to version 6.2.1.526357 on April 18th.

All other SL viewers in the pipelines remain unchanged:

  • Release channel cohorts:
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
  • Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Environment Enhancement Project

Project Summary

A set of environmental enhancements allowing the environment (sky, sun, moon, clouds, water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day),  and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.

Due to performance issues, the initial implementation of EEP will not include certain atmospherics such as crepuscular rays (“God rays”).

Resources

Current Status

The bug stomping continues.

Animesh Follow-On

Vir is now looking at adding shape support (or similar) to Animesh, which Vir sees as possibly being approached in a couple of ways:

  • To make Animesh objects behave as much as possible like avatars. This might be done by issuing a command to load a given shape into an Animesh, or just have a similar appearance resolution to avatars, which would allow associations with body parts for any attachments contained within the Animesh’s contents.
    • Advantage: either route offers the closest compatibility to the way in which avatars work, making it easy to port stuff over from using with avatars to using with Animesh (e.g. Animesh NPCs).
    • Disadvantages:
      • This is a much more complex project to implement as it requires substantial changes to the Bake Service, which can be a performance bottleneck. So a concern is that adding Animesh support to the Bake Service could have a further adverse impact on its general performance.
      • While applying a body shape could be done via the simulator (avoiding the Bake Service), but this again involves added complexity in the amount of asset information fetching the Simulator already has to do.
  • An alternative approach would be to offer a more granular control, using LSL to set the values usually set by shape sliders.
    • Advantages: It can reduce the complexity by allowing s subset of slider changes to be replicated via LSL (e.g. face, hands, etc), rather than trying to have the entire slider system replicated.
    • Disadvantages: This doesn’t give the same level of compatibility to the way avatars work, and if all the sliders were required, it would add considerable additional work with LSL calls for the 130+ sliders.

Which approach should be taken is down to whatever the most common use-case for customising Animesh might be (a likely topic for discussion). Currently, either approach will require additional server / viewer messaging, so Vir is looking at that.

There are also questions on what else might be preferable to add to Animesh (e.g. extending Bakes on Mesh to support Animesh, adding attachments support, etc), and the relative priorities people place against the various options as to any order as to how things might be tackled (would applying shapes be sufficient? Should it be shapes then another requirement, or is there another requirement that should take priority over shape support?).

Attachments are an issue in themselves; as Animesh doesn’t have an associated agent, there are no attachment tables for it to use, making basic attachment to s specified point difficult. Also, avatar attachments are effectively individual linksets applied to a common root – the avatar.

However, as an Animesh object is a single linkset, adding attachment to one object is more akin “merging” the attachment’s linkset into that of the Animesh, making them one continuous linkset. This clearly add complications; for example, how do you identify all the parts of the attachment to remove them when detaching, and how do you ensure they detach as a single object, rather than a coalesced group of unlinked items?.

One potential solution might be to have a means by which individual prims within the Animesh linkset can be flagged with an associated joint within the skeleton, thus allowing attachments to be made to that joint, and somehow “faking” the fact that the attachment linkset is not part of the Animesh linkset.

Exactly how this would work in practice still has to be properly determined, together with an mechanism for handling local position and the attachment’s position and rotation offsets. It is further unclear at present whether this approach might required support from and additional viewer UI element or could be controlled entirely through LSL.

Bakes On Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves viewer and server-side changes, including updating the baking service to support 1024×1024 textures, but does not include normal or specular map support, as these are not part of the existing Bake Service, nor are they recognised as system wearables. Adding materials support may be considered in the future.

Resources

Current Status

Anchor Linden is dealing with issues related to handling alpha layers in the new baking channels – with dome of them not getting correctly baked, and which may need some fixes in the baking process. BUG-226599 is also being looked at; although a feature request, it might actually be the result of an underpinning bug.

Following the April 11th CCUG, Cathy Foil carried out further tests to apply materials to a Bakes of Mesh surface. This involves using a script to take the UUID for one of the new universal bake channels (e.g.BAKED_ AUX1), and pointing it to a normal map (shown in the place holder normal map image “BAKED AUX1 IMG”, right), then wearing a universal wearable that uses the same bake channel. This results in the normal map then being applied to the desired face, as show in the image of the normal map in the Edit floater (arrowed on the right, above). This approach also appeared to allow a layering of normals on a face. However, the method is not currently seen as a recommended approach to materials with BoM, and probably won’t be treated as a supported technique.

 

 

Advertisements

2019 SL User Groups 15/2: Content Creation summary

Maderia Springs; Inara Pey, February 2019, on FlickrMaderia Springsblog post

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, April 11th 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

Environment Enhancement Project

Project Summary

A set of environmental enhancements allowing the environment (sky, sun, moon, clouds, water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day),  and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.

Due to performance issues, the initial implementation of EEP will not include certain atmospherics such as crepuscular rays (“God rays”).

Resources

Current Status

The EEP RC viewer updated to version 6.2.0.526104 on Thursday, April 11th. A significant addition to the viewer with this release is the Personal Lighting floater.

When opened, this floater takes a “snap” of the current shared environment (parcel or region / estate) you are in, and present you with a number of controls that allow you to make quick modifications to the environment that only you can see in your viewer, including Sun and Moon positions, ambient lighting cloud and sky colours, etc. These changes will persist until you log out or select World > Environment > Use Shared Environment, so you can close the floater once adjustments have been made.

The new EEP Personal Lighting floater, designed with SL photographers and machinima makers in mind.

This floater has been added in response to concerns raised that where No Modify EEP asset settings are applied to a location, photographers cannot alter the environment lighting, etc., in a manner to suit their needs, and as they’ve been accustomed to being able to do with windlight tools such as Phototools.

Rider notes that this is a first pass at providing photographers / machinima makers with a suite of options that do not claim an unreasonable amount of screen real estate and fulfil the above requirement. However, if there are specific options photographers feel are needed, and which cannot be otherwise tweaked for EEP settings that are No Modify, please submit them as feature requests.

Specularity Issues: the most recent versions of the viewer (nightly builds and the new RC update) contain an unwanted level of specularity, across objects and on Linden Water. Reports have / are being filed on this.

The latest EEP RC has some issues with specularity rendering on objects (l) and circled right (compared with the same terrain mesh seen on the default viewer, centre).

Bugs: Graham Linden continues to try to deal with the remaining shader bugs and clear them.

Bakes On Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves viewer and server-side changes, including updating the baking service to support 1024×1024 textures, but does not include normal or specular map support, as these are not part of the existing Bake Service, nor are they recognised as system wearables. Adding materials support may be considered in the future.

Resources

Current Status

Anchor Linden is attempting to characterise a couple of viewer bugs that might also require back-end updates as well. The viewer is also awaiting a merge with the latest release viewer (formerly the Love Me Render RC viewer).

Materials and BOM: Bakes on Mesh does not naturally support materials, as the basking service does not support materials, per the project outline above). However it is possible:

  • To manually apply materials directly to the mesh face in additional to BOM applying a worn composite.
  • To apply materials to a mesh via a scripted means. This involves using a script to take the UUID for one of the new universal bake channels (e.g. AUX_1), and pointing it to a normal map, then wearing a universal wearable that uses the same bake channel (e.g. AUX-1). This results in the normal map then being applied to the universal. It’s also not an approach the Lab recommend, and probably won’t be treated as a supported technique.

Animesh Follow-On

Vir has been working on impostor extents see BUG-226359). When impostors are enabled, they can get oddly cropped due to their bounding box size.

The obvious fix is to increase the bounding box size for impostors; however, doing so comes at a performance cost when the viewer renders them – thus potentially negating their purpose (to reduce the render cost / performance hit in rendering complex avatars / Animesh). This likely means that any fix is going to be something of a balance between “padding” (enlarging) impostor bounding box sizes and allowing some truncation to avoid too big a viewer performance impact (fps) when rendering them.

2019 SL User Groups 13/2: Content Creation summary

On The Other Side; Inara Pey, February 2019, on FlickrOn The Other Sideblog post

The majority of the following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, March 28th 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

Bakes On Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves viewer and server-side changes, including updating the baking service to support 1024×1024 textures, but does not include normal or specular map support, as these are not part of the existing Bake Service, nor are they recognised as system wearables. Adding materials support may be considered in the future.

Resources

Current Status

  • As noted in my Simulator User Group update, the Bakes on Mesh viewer has reached release candidate status with version 6.1.1.525409.
  • Depending on feedback from QA, this could mean Bakes on Mesh is fairly close to promotion to release status.
  • However, alongside of this work, the Bakes on Mesh reference textures have had to be re-uploaded, and thus have new UUIDs.
    • This means any test content (such as the test Omega system) using these textures will have to be updated in order to work with the RC viewer.
    • The new UUIDs have – at the time of writing – yet to be updated on the Bakes on Mesh wiki pages.
    • There are also LSL constants for the new UUIDs, but LL don’t currently have a simulator update for these yet, so if you try to set LSL to try to set textures to the appropriate channels they won’t currently work as expected.

Environment Enhancement Project

Project Summary

A set of environmental enhancements allowing the environment (sky, sun, moon, clouds, water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day),  and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.

Due to performance issues, the initial implementation of EEP will not include certain atmospherics such as crepuscular rays (“God rays”).

Resources

Current Status

  • Work is continuing to resolve some shader issues that see “certain things shading differently”.
  • It has been noticed that EEP can also impact frame rates, and the Lab is trying to quantify these better.
  • A further RC build of the viewer is in the wings, but has some issues with it (e.g. issues with handling projected lights) which need to be addressed. However, it is hoped this will surface in week #14 (commencing Monday, April 1st, 2019).

Reminder: the EEP simulator code is now grid-wide. This means certain render feature – such as the stars – appear to be “broken” on non-EEP viewers (e.g. black “stars” can appear in daytime skies as square blotches, and at night white stars appear decidedly square. This is because the sky (including the stars) is rendered differently with EEP, but an attempt is made to convert things like stars back to a windlight setting for rendering by non-EEP viewers, which doesn’t entirely work.

This issue will obviously be fixed when the EEP viewer code is available in all viewers.

Animesh Follow-On

Vir has commenced work on LSL support for Animesh objects. Right now this involves providing a means to get the number of animated attachment slots, the number of open slots.

Other Items

Animation Optimisations

It’s been noted that .bvh animations go through an optimisation process, but .anim animations do not (a past subject of discussion in CCUG meetings). It would make sense for the optimisations to be applied to both, if they are of benefit, or ignored by both if they are not proving beneficial. It’s been suggested that the optimisations result in .bvh animations being a little less fluid than .anims.

Thus far the Lab hasn’t acted on this, as the general feeling has been that most animators favour one of the formats over the other. Those noticing specific differences in performance between the two are asked to file a Jira and attach test versions of both formats so the Lab can do side-by-side comparisons.

Custom Pivot Points

This was another point of past discussion. Initial work has been done to allow custom pivot points within the viewer, but the current blocker is that it requires simulator support, specifically with the physics shapes that have to be generated. With everything else going on at the moment, there is no time frame as to if / when this work might be carried out.

Date of Next Meeting

Thursday, April 11th, 2019.

2019 SL User Groups 12/2: Content Creation summary

Elvion; Inara Pey, February 2019, on FlickrElvion – blog post

The majority of the following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, March 21st, 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

SL Viewer

  • The long-expected Maintenance RC viewer, code-named Teranino, was released on Wednesday, March 20th. Version 6.1.1.525401, comprising 50+ fixes.
  • The EEP RC viewer updates to version 6.2.0.525395 on Thursday, March 21st. It is felt EEP may have “one or two” further RC updates before it is ready to go to release status.

The rest of the official viewer pipelines remain as:

  • Current Release version 6.1.0.524670, formerly the BugSplat RC viewer February 13th, promoted February 28th 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):
    • Love Me Render RC viewer, version 6.1.1.524929, March 6th.
    • Estate Access Management (EAM) RC viewer, version 6.2.0.524909, March 5th.
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17th, 2017 and promoted to release status 29th November – offered pending a Linux version of the Alex Ivy viewer code.
  • Obsolete platform viewer, version 3.7.28.300847, May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Environment Enhancement Project – on the Grid

On Tuesday, March 19th and Wednesday March 20th, EEP back-end support was deployed to the SLS (Main channel) and to the Magnum and Cake RC channels, meaning it is now gird-wide.

As EEP handles environment rendering differently to windlight, that can be that at time, viewers without the may rendered skies oddly (e.g. black dots (stars) appearing in daytime skies, the sun may look bigger than it actually should be, and similar). Should this be the case, toggle the Use Region windlight option in your viewer off / on.

Note that if you are using a personally applied windlight or a custom parcel windlight through a viewer like Firestorm, generally speaking, you should see no issues.

Bakes on Mesh

Again, no update, other than a back-end Bake Service update is due (presumably to fix the “black skirt issue”. Once this is deployed, it should allow a resumption in progress with the viewer, which could likely be promoted to RC status.

ARCTan

The ARCTan project to re-evaluate object and avatar rendering costs in the viewer is still stalled. One concern is that more needs to be done to encourage a greater number of creators to create low impact worn mesh; high impact worn mesh can do much to impact viewer performance, but is currently seen as having little around it to discourage better design. While there are options like the “jelly doll” capability, these are seen as limited in encouraging better content design as the onus is pushed onto other users to determine what they can or cannot see.

ARCTan itself is a difficult set of measures to calculate, as user hardware plays a role in performance (obviously), such as the split between CPU-based and GPU-based computations. As a result, frame times can vary widely. Ergo, more objective measures are required (e.g. triangle counts + surface area for textures, etc.).

Other Items

  • Mesh attachment loading: this is taking appreciable longer, and is particularly noticeable in busy regions, where avatars with a lot of mesh can take what feels like an age to “pull themselves together” (so to speak), although no cause has yet been identified. Vir Linden has been leading work to look into this.
  • Animesh follow-on: the focus is still on allowing body parts in the inventory of an Animesh to be used to customise the skeleton of the Animesh.
  • Creator requests: Vir asked a general question on things creators may be seeing a blockers to developing new content and what they would like to see to overcome these blockers. The feedback included:
    • More script functions.
    • Replacing appliers with an inventory based solution and a Bakes on Mesh follow-on.
    • Extending the existing constraints in the animation format to be a full Inverse Kinematics system.

2019 SL User Groups 9/2: Content Creation summary

Two Loons, Calas Galadhon; Inara Pey, February 2019, on FlickrTwo Loons, Calas Galadhonblog post

The majority of the following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, February 21st, 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

SL Viewer Updates

  • The BugSplat RC viewer, version 6.1.0.524670, was promoted to de facto release status on Thursday, February 28th.
  • The EEP viewer was promoted to RC status with the release of version 6.0.2.524683 on Wednesday, February 27th.

Projects

Animesh Follow-on

No update; Vir is still working on the clean-up following the inventory issues users experienced over the weekend of February 9th /10th.

Bakes on Mesh

Again, no update, other than a back-end Bake Service update is due (presumably to fix the “black skirt issue”. Once this is deployed, it should allow a resumption in progress with the viewer.

ARCTan

This is the project to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. It has been stalled for some time and may remain so for a while.

The overall aim for this work to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints.

In Brief

  • BUG-226427 “Root bone is not centred on avatar”: some content rigged to mRoot may appear broken in Animesh-enabled viewers. This appears to be a variation of an issue initially seen in Bento, and had been thought to have been fixed.  Vir has pulled this issue into his current viewer workload.
  • Animesh on the Marketplace: it is becoming difficult to locate genuine Animesh within the Marketplace Animated Objects category (which is being used for assorted items). A request has been informally made for a new, more Animesh-focused category / sub-category to be added, although this is more a request for the Web User Group.
    • It has also been noted that Animesh is becoming subject to keyword spamming.
  • Custom Pivot Points (BUG-37617): this had been awaiting further information, Vir to review.
  • Date of Next Meeting: The next CCUG meeting will most likely be in three weeks, on Thursday, March 21st, 2019.

2019 SL User Groups 8/2: Content Creation summary

COBKOBO; Inara Pey, January 2019, on FlickrCOBKOBOblog post

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, February 21st, 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

Animesh Follow-On

  • Vir has been assisting with the clean-up following the inventory issues users experienced over the weekend of February 9th /10th. These apparently impacted a number of SL’s back-end services and are still being worked on.
  • A planned change for Animesh designed to throttle the number of complexity updates for avatars and Animesh objects actually never made it into a release viewer. This will now likely get pulled into the (non-public) viewer repository where Vir is experimenting with Animesh follow-on work.
    • The lack of this throttle has meant that some TPVs have implemented their own throttles on these complexity updates to reduce their potential impact.
  • Will there be attachment points for Animesh? Currently unknown. Vir will be investigating options; attachments to Animesh won’t function in quite the same way as avatar attachments, so the optimal mechanism needs to be determined, if possible.
    • One option might be to have attachments behave as part of the Animesh linkset, but have a flag set for them that forces them to be displayed in the required location when used.
    • This doesn’t allow the full range of capabilities seen with avatar attachments, but it would allow the attachment to be made, and the Animesh complexity calculations to be properly updated.

Environment Enhancement Project

Project Summary

A set of environmental enhancements allowing the environment (sky, sun, moon, clouds, water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day),  and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.

Due to performance issues, the initial implementation of EEP will not include certain atmospherics such as crepuscular rays (“God rays”).

Resources

Current Status

  • It is hoped that the current project viewer version of the EEP viewer (version 6.0.2.524476, dated Tuesday, February 19th) will be the last before EEP moves to viewer release candidate status.
    • There are still a couple of bugs to be hunted down which may impact the promotion.
  • Rider hopes to see the viewer go to RC status before the sider code for EEP moves beyond the LeTigre and BlueSteel simulator RC channels, to allow more widespread testing of the viewer once it is in RC without the risk of bugs impacting other simulator updates.
  • People using the EEP viewer (project or RC, once it has been promoted) should see no difference in behaviour when using it on non-EEP regions.

Bakes On Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves viewer and server-side changes, including updating the baking service to support 1024×1024 textures, but does not include normal or specular map support, as these are not part of the existing Bake Service, nor are they recognised as system wearables. Adding materials support may be considered in the future.

Resources

Current Status

  • A further appearance server update is required to fix the “black skirt” issue that can result in an avatar appearing to wear a long, jet black “skirt” when seen in the BoM viewer.

Multiple Texture Uploads

  • BUG-226352 requests multiple suitable image resolutions are made available when uploading textures. Image courtesy of Beq Janus

    As noted in my previous Content Creation UG meeting notes, there was some discussion on textures and uploads, during which, Beq Janus suggested making it possible for users to select more than one image resolution when uploading textures to the viewer.

  • The idea here is to encourage people to experiment and see how the different resolutions work on surfaces, rather than always automatically opting for the highest resolution (e.g. 1024×1024), which might not always be required.
  • A feature request was subsequently submitted for this – see BUG-226352 which has been accepted.
    • It’s not clear if / when this might be implemented, although it is acknowledged as being “a nice thing to have” (particularly given the different resolution mipmaps are generated at upload anyway, but only the selected resolution is made available).
    • It is not clear how much would be involved in the necessary back-end updates required to support the idea.
    • Also, the usual caveat: “accepted” means the idea is something the Lab is interested in tracking / possibly investigating. It doesn’t automatically mean a feature request will be implemented.