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
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”).
The EEP RC viewer updated to version 18.104.22.1686104 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
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.
- Bakes on Mesh knowledge base article.
- Bakes on Mesh forum thread.
- Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).
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.
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.