Category: Content Creation User Group

On The Other Side – blog 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

• Bakes on Mesh knowledge base article.
• Bakes on Mesh forum thread.
• Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).

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

• Project definition document.
• Project summary (this blog).
• Full EEP Documentation.

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.

Elvion – 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:
  • Bakes on Mesh project viewer, version 6.0.2.524367, February 15th.
  • 360 snapshot viewer, version 5.1.6.515934, June 6th (see my hands-on update).
• 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.

Two Loons, Calas Galadhon – blog 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.

COBKOBO – blog 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

• Project definition document.
• Project summary (this blog).
• Full EEP Documentation.
• Project Viewer – via Alternate Viewers wiki page.
• EEP Feedback forum thread.
• EEP sneak peeks forum thread.
• EEP Jira filter.

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

• Bakes on Mesh knowledge base article.
• Bakes on Mesh forum thread.
• Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).

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

• 

  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.

 

Updated, February 16th: the suggestion to make suitable mipmaps available to users when uploading textures (see the end of this summary) has been translated into a feature request by Beq Janus, allowing users to select multiple image resolutions when uploading a texture – see BUG-226352.

The majority of following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, February 14th, 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 updated to Wednesday, February 13th, to version 6.1.0.524348.

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

• Bakes on Mesh knowledge base article.
• Bakes on Mesh forum thread.
• Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).

Current Status

• Anchor Linden has pinned down a couple of further bugs.
• The hope is that BoM will progress to viewer release candidate (RC) status in the near future, although this is down to internal testing at the Lab.

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

• Project definition document.
• Project summary (this blog).
• Full EEP Documentation.
• Project Viewer – via Alternate Viewers wiki page.
• EEP Feedback forum thread.
• EEP sneak peeks forum thread.
• EEP Jira filter.

Current Status

• On the simulator side, EEP is now on the BlueSteel and LeTigre channels (representing roughly 20% of the main grid).
• There is “one last” major issue with the current viewer code to be resolved. This is related to experiences, and Rider Linden believes he has a fix for the problem.
  • It is therefore hoped the EEP viewer will move to RC status very soon.
  • The next update to the viewer should include fixes for BUG-226249.
• There have been some changes to the data returns by llGetenvironment, and further changes will be made in the coming week. These changes will be reflected in the wiki documentation.
• There is also a bug that can cause avatar tags to be corrupted in certain EEP environments, as demonstrated by Whirly Fizzle (below).

• This pass of EEP will not, as previously reported, include Godrays at this point in time. It is hoped these will be added in the future – although when in the future is not clear.

Animesh Follow-On

• Vir has some prototype hooks in the code that allow body parts in the inventory of an Animesh to be used to customise the skeleton of the Animesh. This doesn’t (as yet) include any communications from the viewer to the simulator, which s the next thing Vir will be examining.
  • This next part of the work may possibly hampered by the fact there is an “embarrassingly large” number of ways to transmitting object information between the viewer and the simulator.  None of them are particularly comprehensive, making it harder to determine how best to add messaging specific to Animesh.
  • As a result Vir is also looking at a means of rationalising things to make it easier to add object information communications to the system beyond Animesh.
• There have been requests to provide a means to obtain things like the tri count for Animesh. Vir believes it might be easier to add the means to obtain streaming cost, etc., (as this information is already supplied for in-world objects), and / or to give a more straightforward means of indicating whether something can be linked into an Aminesh object or not.
  • Tri counts are being required so creators can check whether or not linking objects together for an Animesh will take them over the tri count limit for Animesh.
  • A problem here is that the simulator doesn’t have the full tri count information for any mesh object, only an estimate to assist in making LI calculations; so using LSL to extract the information could require more in the way of back-end work to expose the required information obtained from the viewer.
  • There is also a risk that as time goes on, the rules regarding what is allowed for Animesh might change – including the tri count. Any such change could therefore invalidate the accuracy of scripts with a hard-coded tri count limit.
• A request as also been made to enable / disable Animesh via LSL. This is currently not on the cards, unless a compelling use-case can be defined.
  • A suggestion has been that using LSL to disable Animesh could help reduce LI when Animesh objects don’t need to be animated. However, due to the fact Animesh is rendered differently to static objects, this would likely not work in the way people imagine.
• Vir still hopes to re-work Reset Skeleton a system command so that anyone triggering a reset of their avatar skeleton when they see it deformed can send that update to all other viewers in the scene perform a reset for that skeleton, rather than users having to manually select and reset the affected avatar.
  • If this is done, it is unlikely to include any LSL support, due to the risk of it being over-used in scripts, with the potential for performance hits.
• Another request is to have a viewer-side option to reset Animesh skeletons. This is viewed as a good idea, as there is already a debug setting (DebugAnimatedObject – set to True) for this, which could be better exposed, although it doesn’t work with Animesh objects attached to avatars.

Texture Resampling

Thanks to a somewhat confused blog post at New World Notes, there has been a lot of talk over the last couple of days about a “debug setting that miraculously improves texture quality”. In actual fact, there is no such thing – as Beq Janus explains in her own blog (see: Compression depression – Tales of the Unexpected) and in the forums (see bi-curious? You should be – or why your assumed wisdom may not be correct).

As Beq correctly points out, there is no “magic” debug setting to improve the resolution or quality of all textures, and Second Life cannot displayed textures with a resolution greater than 1024×1024.

What Beq did confirm is (as per their descriptions) the referenced debugs can be used to upload textures much larger than 1024×1024 Second Life. However, such textures will be resampled to 1024×1024. The particularly interesting thing here is that in resizing such images, the viewer uses bilinear resampling which – contrary to perceived wisdom pointing to bicubic resampling – can actually result in far better quality in the finished 1024×1024 texture.

Beq’s forum post and (particularly) her blog post explains what appears to be happening – and how direct resizing very high-resolution images using bilinear resampling to 1024×1204 prior to upload will also result in better quality textures with viewed in-world.

Does this mean that the upload texture size limit should be increased? Well, no. The crucial part of this is that the different is only seen with 1024×1024 textures – which have issues in terms of the amount of memory they eat, and in the fact they are already drastically over-used. As such, increasing the allowed upload resolution prior to resampling might further elevate the use of 1024×1024 textures.

In the meantime, the forum post has triggered some interesting discussion around bilinear and bicubic resampling, and where each might be preferable to use, and how bilinear could benefit the production of seamless normal maps.

A further suggestion resulting from these discussions (or the resurgence of a suggestion) is to make all the mipmaps for an uploaded textures available, rather than the just the level selected at upload (so, for a 1024×1024, the 512×512, 256×26 and 128×128 mipmaps are also made available to the user, allowing them to experiment and see how the different resolutions work on surfaces.  A feature request Jira has been requested for this idea.

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, January 31st, 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 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, (hopefully) 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 Feedback forum thread.
• EEP sneak peeks forum thread.
• EEP Jira filter.

Current Status

• There should be a further EEP simulator RC deployment in week #6 (commencing Monday, February  4th).
• It has been decided that due to a number of performance issues that have yet to be resolved, EEP will not initially have crepuscular rays when the viewer is promoted to RC status, although hopefully these will come in time.
• There is an issue with the Linden terrain appearing blurred in the viewer, this should be fixed in the next viewer update.
• When importing windlight settings into EEP, it should be remembered that there will not be a precise 1:1 match when converting; some elements of an environment’s lighting might be darker or lighter than their windlight equivalents (as can be seen with the sample EEP assets now available in the EEP viewer’s system library). This is because the underpinning rendering in EEP is very different to the current windlight rendering.

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 knowledge base article.
• Bakes on Mesh forum thread.
• Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).

Current Status

• There are still a number of issues to be resolved within the viewer (e.g. bakes not being seen by other viewers,plus the “black skirt” issue that can result in an avatar appearing to wear a long, jet black “skirt”, at least one UI issue with a button not working correctly) so no updates at the moment.

Animesh Updates

• Vir is looking at the way object updates are handled in order to find the best way to send and receive shape information to Animesh objects, should the system be extended to allow shapes to be applied to Animesh.
• Right now, the Reset Skeleton option only applies to the local view; there have been requests to make this a system command (so if I use Reset Skeleton, a message is sent to all viewers around me to perform the reset against my skeleton as well, rather than other users having to do it manually if they see something wrong with my avatar after I’ve changed shapes).  This could also potentially benefit Animesh, and Vir is also looking at the idea as well.
  • The focus here will probably be on triggering the reset through the UI, as described above, rather than allowing a LSL function to trigger it. The problem with the latter is the risk of people using it indiscriminately in avatar models, triggering unnecessary (and impactful) updates on systems.
• Adding attachments to Animesh is also a request, but this isn’t being looked at right now.
• Currently, an Animesh can keep an animation as a prim property, regardless of whether or not the animation is there (e.g. add a bouncing animation to an Animesh, remove it, and the animation will persist, even if the Animesh is copied and distributed). This is not expected behaviour and will likely be fixed.

Other Items

• Visual size overlay when editing appearance: this feature request from Penny Patton (see BUG-225513) has been accepted by Linden Lab, but is currently on the back-burner of things they may consider in a future project, but is not currently being actively worked on.
• Next meeting: it is likely the next CCUG meeting will be on Thursday, February 14th. However, check the wiki page for confirmation ahead of February 7th.