The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, November 15th, 2018 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
Animesh is now officially released. Blog posts:
This means that the Animesh code will now be merged with all current RC and project viewers in the coming days / weeks. Firestorm support for Animesh will be coming soon, as is the other case for TPVs that have not already started making releases with Animesh support.
Resources
To help people get started with Animesh, there is already a range of available resources, including:
- Animesh User Guide
- Animesh test content
- Animesh LSL methods:
- Animesh – Updated Limits and Cost Formulas
- Animesh feedback thread
Discussion
- Concern has been raised about the 2 Animesh attachment option for Premium members impacting performance at major events given the lack of “public” testing of the ability (which had always stated as being one Animesh attachment per avatar across the board).
- Interestingly, when the one Animesh attachment per avatar was first set, it was seen as too limiting, with some wanting as many as five per avatar.
- The tri count cap remains unchanged at 100K per Animesh.
Environmental Enhancement Project (EEP)
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 which include the ability to use custom Sun, Moon and cloud textures. These can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.
The project also includes a new set of render shaders to support atmospheric effects such as rainbows, crepuscular rays (“God rays”), better horizon haze and fogging (but will not include rain / snow).
Resources
- Project definition document.
- Project summary (this blog).
- Full EEP Documentation.
- Project Viewer – via Alternate viewers wiki page.
- EEP testing region: secondlife://Aditi/secondlife/EEPTesting/247/44/23
- EEP Feedback forum thread.
- EEP sneak peeks forum thread.
- EEP Jira filter.
Current Status
- There are a couple of blockers that have come up on the next viewer update, and which are currently being worked on, and should hopefully be cleared by the end of the week.
- The first scripted functionality for EEP is now available: llGetEnvironment. This:
- Returns a list containing the current environment values for the parcel and region as a list of attributes.
- Takes a list of attributes to retrieve in parameters and returns them in the order requested.
- llGetTimeOfDay has also been revised in line with EEP.
- Graham Linden is continuing to work on the rendering side, including crepuscular rays. He is however, also engaged in other work related to viewer rendering (such as project ARCTan).
- As a part of Graham’s work, there is a further update to the EEP sky settings that will allow the atmospheric settings to be altered
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, 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 Bake Service, nor are they recognised as system wearables. Adding materials support may be considered in the future.
Resources
- Bakes on Mesh forum thread.
- Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).
Current Status
- The required Bake Service update (which in part allows the support of 1024×1024 textures) was deployed in week #46.
- It was a glitch with this deployment that caused the Bake Service to overload, resulting in a lot of grey or cloud avatars mid-week.
- Anchor Linden is now working on updates to the viewer, which is considered to be the only blocker to Bakes on Mesh going live.
- Additional channels have been added to the Bake Service already which include the left arm and left leg. A request following this update was to allow upper and lower body skin textures to these channels – this will not be a part of the initial Bakes on Mesh release.
- It has yet to be tested, but as Animesh objects do not have the necessary shape support for the Bake Service to use, it is thought BoM will not work (or at least not work as anticipated) with Animesh attachments on an avatar.
Normal and Specular Maps Support Experiment
As noted in the project summary above, Bakes on Mesh will not by default support normal and specular maps when released.
However, in week #45, Cathy Foil suggested it might be possible to allow Bakes on Mesh to indirectly support normal and specular maps using a combination of three additional bake channels within the Bake Service and a scripted “applier” option, similar to current skin and clothing applier mechanisms.
Since that time, she’s been carrying out tests using the existing three Aux Bake Service channels, added to the system as a part of Bakes on Mesh. While the approach appears to work with normal maps, there are a number of questions relating to alpha blending, deriving specularity (normal maps use the alpha channels for specular power in the SL materials setup), etc. These would require more in-depth testing through a suitable viewer, and as such, this isn’t seen as a viable approach at this point in time.
New Projects
No decisions have been made as to what user-visible projects will come next.
- There is an infrastructure related project for inventory, but this shouldn’t have user-visible impact.
- Project ARCTan (avatar and object complexity calculation improvements) has been on hold, awaiting resources, which are now becoming available.
- There are a mix of options in the pot for Animesh and BoM follow-ups, but any follow-on work hasn’t been officially defined.
- There are a number of other potential projects the Lab isn’t ready to announce as moving forward just yet.
Next Meeting
The next CCUG meeting will be on Thursday, November 29th, 2018.
Inara Pey: Living in a Modemworld 
I saw somebody ask a question about Firestorm support for Animesh on their in-world support group, and from the reaction, any Firestorm “coming soon”, for anything, is meaningless. They were not even willing to say whether they would try to put it in their next update.
They really are not very good at communicating with users.
LikeLike
Depends on when you saw the comment.
Firestorm prefer not to update until a feature is released by Linden Lab -and even the Lab doesn’t commit to dates / time frames for any release, simply because of the number of potential factors involved. Some of these might include: the overall stability of the viewer compared to other in the current RC pipeline; what is the relative priority among the current RC viewers – does one have a fix or update viewed as more important than the features in another? Are two viewers in the pipe each dependent upon simulator updates, and what is the status / dependencies of those updates? As the RC viewer for a project gains a largely and larger cohort of users, do any previously unseen performance or other issues arise that require further viewer updates or even back-end tweaks? Has something come up last minute outside of a project that needs to be addressed before said project can go live etc.
So, prior to the Lab going live with something, it’s nigh-on impossible for Firestorm to commit (or even indicate) a possible date / time frame when they might release. And even after LL have released, depending on the nature of the update / capability, Firestorm may still need further testing over and above any carried out while the code has been in RC status with the Lab (this is an important influence in itself: under the Lab’s standing request to TPVs, Firestorm do not take code from the Lab’s repositories in advance of that code reaching RC status within one of the Lab’s viewers), which can again impact on when they might be able to release. There’s also the fact that working on Firestorm isn’t a paid job; their developer, QA team, etc., all have to fit working on the viewer around their jobs, families, etc., and so even the availability of a team member who may be vital to getting an update out can throw a spanner in the works.
Therefore, “coming soon” is not an unreasonable reply from a support team member. As it is, and in the case of Animesh, Firestorm has been working hard to merge and test the code (I’ve been one of those testing pre-release versions of the viewer), and there is a hunger to get an Animesh release made – but that doesn’t change the caveats noted above.
LikeLike