Category: Content Creation User Group

Grauland – blog post

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

New Viewer Release Notes Pages

The Lab’s RC viewer releases / updates all have shiny new viewer release notes pages on the web. These move the notes away from the old wiki pages, and into a new format that provides:

• The release notes can be accessed via a new home page, with links to recent SL viewer releases – that is, the current RC viewers.
• The release notes for a specific viewer, with new icon links to its respective download versions (Windows 64 / 32-bit and Mac OS).
• There are also links to support information: a new Repositories overview page; an explanation of the viewer version numbering system; a link to the Viewer Support Policy.
• A significant change is that many of the Jira links in a release page reference the public Jira bug reports, rather than the Lab’s internal MAINT clones. This should make specific bugs addressed in an update more visible to interested users.
• These pages can also (for the time being at least) be accessed from the existing Alternate Viewers wiki page, when clicking on the release notes link for a specific RC viewer.

 

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

• The EEP viewer updated to version 6.2.3.527250 on Thursday, May 16th. This update should include a number of bug fixes and shader updates that will hopefully improve things “considerably”.
• Graham Linden continues to work on the remaining shader / graphics issues.

Animesh Follow-On

• Vir continues to work on adding visual parameter support to allow shape adjustments to be made to Animesh.
• This work has new reached a point of being able to store visual parameter information relating to Animesh objects, and to be able to send it to viewers.
• The next stage of the work is to get to get the viewer to understand what it is supposed to do with these messages.
• Vir hopes to have an internal prototype for this running in the next few days. If successful, this should pave the way towards a project viewer being made available down the road.
  • It will initially focus on using list-based LSL input to set individual shape parameters.
    • These will probably be throttled to prevent over-use (e.g. to prevent the capability being used as a high performance cost alternative to animation).
  • Once this is working that shapes can potentially be added for manipulation.
  • Obviously, this will require simulator updates to be able to support the LSL commands, as well as the updates required for the new message types, etc.

Animesh as NPCs

• There has been a lot of forum discussion on using Animesh as non-player characters (NPCs).
• A limitation here is that a decent-looking NPC, suitably clothed and ready for use can too often have a huge LI (into the 100s).
  • Part of the problem is that until Animesh,  is there was no real incentive to optimise rigged mesh, as being worn by an avatar, it never really had a “Land Impact” per se, and a lot of clothing has an “insane” triangle count (e.g. 21,000 for a tank top).
  • As Animesh calculations do try to allow  for the cost of rigged mesh, such high triangle counts are (simply put) converted in LI, driving up the LI for any Animesh character on which it is used.
• It is hoped that as the ARCTan project comes to pass, it will offer some form of incentive that will encourage those clothing makers who may not consider optimisations to do so, which will help improve things for both Animesh using wearables and also help reduce some of the performance overhead overly complex avatars can cause.
• Another alternative would be to (at some point) extend Bakes on Mesh to include Animesh objects, allowing them to be clothed using system layers.
• In the meantime, the suggestions is that those wishing to create NPCs perhaps consider doing so entirely in Blender (or similar), and not rely on using clothing and attachments that might be available in-world as a means of clothing / equipping 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

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

Current Status

• There is a simulator change pending. This includes a means of accessing BOM UUIDs.
  • These were changed in the last back-end update as a result of underlying asset property issues. If there is BOM content using the old UUIDs, this will have to be updated.
  • The simulator update is intended to allow access to the texture UUIDs without having to do so numerically, as is currently the case. This should re-enable the ability to access them via their name abbreviations.
• There is also a further Appearance Service change pending, designed to correctly handle tattoo layer with partial transparency (currently, if a tattoo with partial transparency is sent for baking via the new BOM channels without any underlying opaque layer, then the alphas are not correctly resolved).

Ukivok – blog post

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

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

Current Status

• The next viewer RC update is “close”. This should:
  • Include a batch of shader updates that will hopefully improve things “considerably”.
  • Be merged to the current LL release viewer (version 6.2.1.526845 at the time of writing, promoted May 7th).
• An issue of late has been that of new bugs popping up as existing ones are dealt with.
• A recently noticed issue has been with day cycles – cloud scrolling across the sky will suddenly “hiccup” slightly in their motion, rather than scrolling smoothly throughout.

Animesh Follow-On

• Vir continues to work on adding shape support (or similar) to Animesh, specifically on the infrastructure requirements for being able to send slider parameters for Animesh objects to and from the viewer.
• No decision has as yet been made to whether to offer full body shape support or to use individual parameters, but the underpinning infrastructure requirements for both are more-or-less the same.
• The focus is therefore on developing the infrastructure (messaging, etc), to a point where both can be tested as a decision made on the basis of that testing.

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

• There is a simulator change pending. This includes a means of accessing BOM UUIDs.
  • These were changed in the last back-end update as a result of underlying asset property issues. If there is BOM content using the old UUIDs, this will have to be updated.
  • The simulator update is intended to allow access to the texture UUIDs without having to do so numerically, as is currently the case. This should re-enable the ability to access them via their name abbreviations.
• There is also a further Appearance Service change pending, deigned to correctly handle tattoo layer with partial transparency (currently, if a tattoo with partial transparency is sent for baking via the new BOM channels without any underlying opaque layer, then the alphas are not correctly resolved). This is with the Lab’s QA team.
• There are no BOM-specific updates pending to the RC viewer, but this will, as per the Lab’s viewer release policy, be updated to maintain parity with the latest release version of the viewer (6.2.1.526845) at the time of writing.
• Given the overall status of BOM and EEP, it would appear likely that BOM could be promoted ahead of EEP as a released project and viewer.

Candlewood – blog post

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

There was little to report, project-wise, this meeting, with most of the time taken up with a general discussion on avatar complexity, LI, ARCTan, LODs and efficient content. This summary focuses on the project updates that were offered.

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

• The regressions in environment appearance that have been seen since the Thursday, April 18th roll-backs will hopefully be corrected with the next simulator deployment that has EEP included.
• Shader issues are continuing to be investigated and resolved as they come in / can be fixed.
  • The next release candidate version of the viewer may address the problems of environments looking unnaturally dark in the EEP viewer.
  • Graham Linden is looking at some updates provided by user Geenz Spad, who initially formulated how materials could be added to Second Life.
• BUG-226752 “[EEP] Interest Lists Culling – Draw Distance has little effect on scene rendering” – still has yet to be addressed.

Animesh Follow-On

• Vir continues to work on adding shape support (or similar) to Animesh, specifically on the infrastructure requirements for being able to send slider parameters for Animesh objects to and from the viewer.
• Some of this involves using the infrastructure developed for EEP.
• This work is still in its early days.

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 continues to work with some appearance service issues that need to be fixed before the project can progress.

Starter Avatars

As I noted at the time, several of the last batch of Starter Avatars for Second Life, released in January 2019, came sans any form of animation override (see: More Classic starter avatars for Second Life). This has now been addressed, and those avatars that needed them have now been updated with AOs.

Avatar Complexity / Impact – Summary

The subject of avatar complexity and lack of any Land Impact control for avatars formed a major point of general discussion in the meeting. Obviously, there is ARC – and the upcoming ARCTan project that is re-evaluation a range of rendering costs, including in-world objects and avatars. However, unlike LI, avatar rendering costs itself isn’t really an incentive to build efficient worn content for avatars.

However, trying to be more proactive with avatar complexity is difficult. Take the idea of some form of “Avatar Impact” akin to Land Impact:

• How should it be defined?
• How should individual attachments be weighted? purely on their in-world LI? Number of vertices? Tri / poly count? A combination?
• What sort of policy needs to be put in place?
• What happens if an avatar tries to enter a region / parcel where its “AI” exceeds the land capacity? Should a simplified version of the avatar be allowed?
• How will a home owner feel if they find they cannot rez a new item of furniture because it would exceed their land capacity because their “AI” is too high?

As such, any such “avatar impact” would require a substantial changes to Second Life – as well as a lot of lead-time and explanation to users. So while not impossible, implementation would have to be weighed carefully. Currently, there are no plans to introduce any such system – and the target remains on being able to move forward with ARCTan.

This led to a broader discussion on complexity, the potential of ARCTan and a slight segue into LOD and auto LOD (again, something that might had some advantages – and disadvantages – but really not now suited to SL).

Puddlechurch – blog post

The majority of the following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, April 18th 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:
  • EP RC viewer version 6.2.0.526104, April 11.
  • Bakes on Mesh RC viewer, version 6.1.1.525409, March 26.
• Project viewers:
  • 360 snapshot viewer, version 5.1.6.515934, June 6, 2018 (see my hands-on update).
• 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

• 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

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

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

Current Status

Anchor Linden is dealing with issues related to handling alpha layers in the new baking channels – with some 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.

 

 

Maderia Springs– blog 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

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

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.

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.

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

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

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.

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.